Restrict component usage in certain container

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.

    jcr:primaryType: hst:component
    hst:template: base-footer
      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,

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


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,

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

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.