Can you hide certain inherited pages in a child publication?

Question

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.)

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.