Tridion's BluePrinting is quite powerful. The child publication will default inherit all the pages from parent publication, which is good most of the time.

However, sometimes you don't want to show certain pages. For example, you are selling products, and there is certain product models which you are not selling so you don't want to show those product pages.

What is the best way to achieve this? (I don't want to do it at the folder level, since I still want to show certain products in the same folder.)


4 Answers 4


It's not possible to filter items as part of the blueprint process, if your child inherits from a publication, it will receive everything from that publication.

You've a couple of ways to solve this:

  1. Create the page/content you need in your child publication(s)
  2. Create the page in your parent but do not publish the page
  3. Write your own logic to ensure that the page is not visible (a gui extension) or that the page cannot be published in your child publication (event system, or template logic).

I'd be interested to know your final solution chosen, perhaps you could share with the community.

  • Thanks for the reply. 1) is not a solution for us. We need to create the page in master level, each country can decide what to do. 2) is error prone, where somebody can accidentally publish the page. 3) seems like a good solution for our problem.
    – charles
    Commented Dec 17, 2013 at 22:35

I was recently asked by a client how you could do something similar. My response to this made the following assumptions:

  1. I would have a group or several groups of users that I need to disable their ability to (un)publish a defined set of pages
  2. The only place I needed to limit the users ability to (un)publish was in the UI

My response contunued with the following thoughts

I would set up a Category/Keyword combination that Represented a structure similar to the following:

  • CAT: LimitPagePublishing
    • KW: SelfServe Users
      • KW: HomePage
      • KW: ProductX

The CAT is my configuration entry point. The KW for SelfServe Users is a known group in my content manager. The children of "SelfServe Users" are the page names or tcmuri of the pages that I do not want this user to be able to publish.

I would create a GUI extension that uses a WebService (using the core-service) that would apply the logic of finding out if the user is a member of a group that does not have rights to the selected item(s) and hiding the publish/unpublish context menu items if they did.

The GUI extension would find out what groups the user is a member of, then check the LimitPagePublishing (CAT) to see if the users is a member of a listed group. If they are then check to see if the selected item(s) exist(s) in the matching KW for the group(s). If the item is, then hide the menu items.

Something to be aware of is if I select an item (component) that resolves to (un)publishing of a page listed in teh Category/Keywords I need to include a resolve items method in my WebService.

There are more things to think about in this scenario but, it is feasible to accomplish this with a GUI extension and a Core Service WebService.

  • +1 and nice setup. I noticed your bullets didn't come out right so I made a slight edit. Commented Dec 18, 2013 at 23:14
  • Our requirement is different, where we don't want anybody to publish the page. We don't even want the page to show up if possible (since the product is not sold in that country).
    – charles
    Commented Dec 19, 2013 at 22:16

There is a simple solution without GUI extensions, if you would drop the requirement that all products have to be in the same folder. Please realize that you need to weigh this against the pain of having to write a GUI extension!

  • Create a special folder for the pages you want to hide in the child

  • Localize this folder in the child and remove all the permissions (including read) for every group

Now no one except a system administrator can see the components, let alone publish them or use them on a page.

  • The localizing of the folder is an easy solution. Only down side is you can still see the main folder you localized in the UI. So it cleans it up for access but not visually.
    – ToddB
    Commented Apr 22, 2015 at 19:44
  • Would be a nice solution if all the pages are in the same location, but it is not true in our case. Thanks for sharing your solution.
    – charles
    Commented Sep 26, 2016 at 20:45

Consider starting with what your authors' perspective on products to create the content model or relationship between products and channels (publications).

The business decision or logic at the right context will then give you the best approach.

  • Central control might imply metadata and CD queries. If maybe the same set of authors manage all products in a single location and choose where the items should show, then consider component metadata to control where items display.
  • Pages might be optional. Use Tridion pages if authors need control over product placement, otherwise a dynamic component approach might be a good fit. Consider virtual folders (also with metadata) to limit which items each publication sees.
  • Local control can use independent pages or publishing for control. If each publication has control over which products it needs to use, then have "local" authors make their own pages and/or publish specific sets of products.
  • Add additional logic as needed. If you find it's too easy for authors to accidentally publish the wrong products, then add either CM-side (GUI extension) or CD-side logic to prevent certain items on certain sites.

One way to look at John's first point is that you can "flip" a BluePrint requirement where parent publications just have a subset of pages.

Don't completely discount the folder (structure group) approach especially since your final urls and navigation don't have to match your CM-side organization.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.