For Experience Manager, it looks like I can control:

  • Which pages an editor can make (with permissions on the containing Experience Manager Page Type)
  • Where they can make pages (with permissions as well)
  • Which new Content Types are allowed for each Page Template for a given Publication

However, I can still see the full list of Page Types. (see edit, persmissions work)


  1. Would extending the Page Type list be the right approach to hide page types for certain users (groups)?
  2. How might we limit the visible Page Types when on a certain page?

The scenario might be: "as a user viewing a page in the About Us section (Structure Group), only let me select certain (XPM) Page Types."

Edit: Confirming hiding Page Types with permissions can "trim" the list. I probably didn't refresh.

Another edit: If I had to revisit this requirement, I'd change "limit" to encourage, similar to how XPM will suggest certain bundles for items. This might include lists like:

  • Popular pages for this section (Structure Group)
  • Recently used Page Types
  • Suggested Page Types

The other Page Types should still be available to XPM users.

enter image description here

  • I think this is only possible with security - i.e., only the Page Templates that you can read will be shown.
    – Nuno Linhares
    Commented Feb 12, 2015 at 18:27
  • Ok, using permissions to hide the prototype page types worked. Restricting Page Templates did prevent new pages based on them ((80040356) Unable to retrieve item with id), but didn't affect the visible list. Looks like Browser search can also help even if we can't change the list. Commented Feb 12, 2015 at 19:12
  • Hmm - it should change the list of visible items too. Try clearing browser cache?
    – Nuno Linhares
    Commented Feb 12, 2015 at 21:25
  • 1
    After clearing browser cache I was about to hide Page Templates from the Ribbon Toolbar Layout tab, but I still get all Page Types this user can access to (via read on containing Structure Groups). Hiding by Page Template might be too much, though--I often have projects with only a few PTs ("Home" and "Content"). Commented Feb 14, 2015 at 16:56
  • I agree with @Bjørn that we probably don't want to restrict page creation in this way. I'll probably suggest to Product Management that some strong restrictions are good (editors can't make Navigation pages), but in the context of making a page, I'd like to see recent types I've used, one's that others have used, and "choose for me" type options. ;-) Commented Feb 14, 2015 at 17:01

1 Answer 1


Tridion does not impose any constraints on page types within structure groups; it is the responsibility of your editors to define the site structure and populate the pages with content (and to chose the correct page type).

If you want to enforce that a certain section of the website will only accept pages that match a certain page type you will have to hook the Save event of pages and verify the composition of the page from code and throw an exception (with a useful message) if the page doesn't validate.

Having said that: this to me is solving the problem in the wrong domain. A CMS is a tool to empower content editors not to restrict them so I'd go with educating the editors over enforcing restrictions any day...

  • Power to the People! +1
    – Nuno Linhares
    Commented Feb 13, 2015 at 11:32
  • Sure, though under the guise of "ultimate flexibility" I've seen huge lists that confuse editors. My ideal preference would be to give a few good defaults, with the freedom to choose from "anything" for those that need the flexibility. Commented Feb 14, 2015 at 16:30
  • Oh and from how I understand page types work, there's also a Copy involved behind the scenes--so that might be another way to restrict the creation. But this isn't my requirement--if you've read a few of my 200+ posts on Tridion, you might recognize this as a request from a colleague who's asking by proxy. Commented Feb 14, 2015 at 16:32
  • Consider that Tridion already has similar features for creating Components (default Schemas on folders), Pages (default PTs in SGs), and Pages in XPM (default prototyped content types). A default page type for a given section could be a reasonable expectation--it was asked by one of my biggest customers. Commented Jul 4, 2015 at 13:07
  • I agree it would be a very nice feature if in XPM you could control what items show up in new page creation based on the parent SG (Sitecore allows this for example) but that's a product level change and not some extension i'd want to have custom built. So: have the customer fire up an idea on the ideas site and use social channels to get an upvote (that is still the official way to get new ideas in the product right?). Building this sounds way to involved for us mere consultants ;-0 Commented Jul 21, 2015 at 13:21

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.