Why Page Types Are a Very Good Thing (TM)

Update: It seems Experience Manager only allows System Administrators the ability to create Page Types (confirmed at least with XPM on SDL Tridion SP1-HR1). My sentiments are the same--we shouldn't hesitate at using Page Types in implementations--luckily you've already defined at least the IA version of these in your functional designs, right?
An SDL Tridion Page Type creates a predetermined set of:
  • optional "dummy" content (place holders) you're meant to change
  • content that should be left "as-is" from the Page Type (i.e. "template") -- if this ever gets updated, your version should probably get updated as well
Experience Manager (XM), the in-context UI that replaces SiteEdit 2009, allows authors the ability to set pages as Page Types by simply setting a check box.

A user A System Administrator sets "Use this Page as a Page Type" for a given page, then sets:
  • Page Type Description
  • Page Type URL
  • Component Presentation settings for either:
    • Include this Component Presentation OR
    • Include a Component Presentation that contains a copy of this Component, which then offers two more settings for:
      • Folder (where to save such copies)
      • Format string (on how to name these copies)
Authorized users now have the ability to create page in XM based on this Page Type. See SDL Live Content for the full details.
I was impressed when we first saw this feature in February, 2012. One concern was how customers might feel about giving regular page editors this ability. Shouldn't giving authors the ability to create pages and such "prototypes," be up to IT or the Content Management Office?
So far, I have heard one client ask about controlling the option. And the "good" news is only Admins have the ability. I take back any reservations--at least some authors should be able to create page types--for the following reasons.
  1. An author that can set such a setting already has the ability to create and edit such a page manually.
  2. An author that can set such a setting already has the ability to create and edit such a page simply by copying and pasting the page (and then components.)
  3. An author that can set such a setting already has enough to do, making their life easier is a Good Thing.
Restricting this ability is equivalent to wanting the following.
  1. Although a content editor has the ability to create pages similar to an existing page, we don't want it to be easy for them in XM (which defeats the purpose of XM, yeah?).
  2. Although the easiest way to make a page and update content in the CME mimics XM Page Types, we want to remove such "Copy & Paste" functionality from XM.
  3. Although this prototyping pattern is familiar to anyone that's seen "templates" (real ".dotx" templates or even just copies of .docx) in Microsoft Word, we want to make this a Power User or IT-only function.
You've been doing "Page Types" in a non-CMS context for years now. Anytime you've heard, "oh yeah, get the template from the shared file/SharePoint/Wiki and make a copy," someone has saved time and effort in creating something based on a predetermined set of:
  • dummy content that's meant to be changed
  • content that should be left "as-is" from the "template" -- if it ever gets updated, all versions should probably get updated as well
Since only admins can create page types, I'm withdrawing my rant below. Can't argue for giving authors the page type ability if you can't currently give authors the ability. ;-)

The biggest challenges with Page Types will likely be explaining some terms and making sure your authorization model allows your editors to actually make the pages and content they define in Page Types. If they can create pages, it's likely you already let them create content.

Understand what Page Types really do, trust your editors, and be pragmatic in your implementation. Realize this type of approach isn't new, nor unique to SDL Tridion, and that Page Types are more administration than administrator type functionality.

Any other features you wish more authors had more (or less) access to? Leave a comment below.


  1. Thanks Alvin; this will improve the editor experience in a very positive way!

  2. Thanks Alvin. It does make sense. I would have loved to have a specific right "UI2012 Page Management" or something like this though. Maintenance and support can become a difficult for frequent changes. This way.we can implement the security model in such a way to accommodate the customer requests as well.


Feel free to share your thoughts below.

Some HTML allowed including links such as: <a href="link">link text</a>.