Our client currently has multiple containers where components can be added.
One of their containers is the footer container and they have a request to block the inclusion of certain components inside of that container.
Is there anyway i can make a change in the configuration to exclude certain components to be added?
Or when rendering a component, is there a way to determine the container the component is placed in to inform the content author that he/she should move the component to another container.
/footer:
jcr:primaryType: hst:component
hst:template: base-footer
/container:
jcr:primaryType: hst:containercomponentreference
hst:referencecomponent: base/footer
@dvdgiessen Hello, your post is a few months old now. Did you find the answer? I have exactly the same question. Thank you in advance!
Hello both,
unfortunately, this is not a supported functionality at the moment.
Kind regards,
Lef
1 Like
Hello Lef,
thank you for your fast response. Is it possible to filter the usable/allowed components on a page- or at least user-role-level?
Thank you and best regards
Gian-Luca
Hello,
if you are referring to filter/restrict drag & drop components from the sidebar for editors in the CMS while editing/previewing I am afraid not.
You could have a look here this page describes how you can filter out components entirely from the page structure. However, this applies during rendering/aggregation phase of the site. Not sure if that’s what you are after.
HTH and regards,
Lef
1 Like
Currently a BR support ticket is set in place to have this implemented, they cannot give any estimates when this is done.
As a quick workaround we just don’t render any illegal component when placed in containers they are not supposed to be added to in the Site perspective.
This CMS perspective will display a warning that the content author should remove the component.
You can determine whether a component is placed in a certain container by using
component.getComponentConfiguration().getCanonicalPath()
This path also contain the name of the container.
It’s probably not a 100% foolproof but it works good enough for our usecase.
1 Like
Hi, that’s a good workaround! Thank you for sharing.