DEV Community

Cover image for Kentico Xperience Design Patterns: Page Type Restrictions
Sean G. Wright
Sean G. Wright

Posted on • Updated on

Kentico Xperience Design Patterns: Page Type Restrictions

In previous posts we looked at how we can model content with Page Types and Content Hierarchies.

In this post we'll continue our content tree architecture exploration πŸ—ΊοΈ by learning about Page Type restrictions.

This is Part 3 of 4 in a series on Content Tree Architecture in Kentico Xperience 13. You can read Part 1, Part 2, or Part 4.

πŸ“š What Will We Learn?

Limitations are Liberating

Since we'll be discussing "restrictions" in this post, we should first touch on a mantra of of mine that explains why I find Page Type Restrictions so valuable πŸ’° in a Content Tree Architecture.

Variety might be the spice 🌢️ of life, but too much can lead to the tyranny of choice.

Image description

Image Credit

We want to have choices πŸ˜€, but to make the best decisions, in a reasonable amount of time, we need to have the right options to choose from - not every option 🧠.

This idea is directly applicable to the work that marketers and content managers do with a DXP like Kentico Xperience. It gives them many tools and features to accomplish their goals, which is why they love the platform 🀩.

However, if a product has many features and all of them are always available, it can be hard to identify which features are available intentionally and which are incidental to a flexible and powerful product πŸ€”. We (developers) want the teams we are supporting (marketers, content managers, administrators) to fall into the pit of success πŸ€— - curating experiences by limiting choices really helps with this πŸ‘πŸΎ.

Allowed Page Types

What's the point of setting up a consistent, scalable content architecture if we can't help marketers and content managers keep it well organized over the long term 🀷🏻?

One of the best tools to enforcing good organizational practices and guiding those responsible for the site into "the pit of success" is Allowed Page Types.

We can limit where pages of a specific type can be created in the Content Tree, from the perspective of the parent and the child 🧐.

Video Library Example

In the screenshot below, we can see the "Allowed parent page types" for the Video Library Page Type - it can only be created under the Root page βœ….

Video Library allowed page types settings

We can also see that Video Library pages can only have 2 types of child pages - the Call To Action Container and Videos Container.

The Video Container Page Type also has restrictions - it can only be created under a Video Library and can only have Video Year children:

Video Container allowed page types settings

The Video Year and Month follow the same pattern - the Year can only be created under the Video Container with only Months as children and the Month can only be created under the Year with Videos as children πŸ˜‰:

Video Year allowed page types settings

Video Month allowed page types settings

Finally, we get to the Video Page Type and see it is the end of the content hierarchy. It can only be created under Video Months and cannot have any children:

Video allowed page types settings

What this means in practice is the following:

  1. Videos are only found as children of a Year/Month hierarchy in a "Video content" container inside a Video Library.
  2. Administrators of the site don't need to think 😩 about which type of page they can create under Video Containers, Video Years, Video Months, or Videos. Xperience automatically selects the only valid option πŸ™πŸ½, if there is one.
  3. Anyone responsible for managing content in the site can quickly learn πŸ€“ exactly where to go to find that content, even if there are multiple Video Libraries.
  4. As the number of Videos grows, we don't have to fight against the organization of other types of content (like CTAs) because they have their own organization with container Page Types πŸ˜….

Recommendations

Always Limit Allowed Page Types

We should always limit the Allowed Parent/Child Page Types as much as possible. If we find that a Page Type needs to have many different parent and child pages, it might mean that page is serving too many roles πŸ‘ˆ in the content strategy and we should try to create separate (but maybe similar) Page Types to serve those roles.

There are exceptions to this, like a "Basic Page" that has no structured content and acts as a landing page in multiple areas of a site. But even these types of pages should have their Allowed Page Types limited βœ”οΈ.

A strictly organized content hierarchy can always be relaxed over time if the requirements of the site change, but it is very difficult to "put the genie πŸ§žβ€β™‚οΈ back in the bottle" and create a sensible organization out of a content tree that's been poorly maintained 🏚️ for years.

It's worth also noting that just because a Page Type only allows a single type of child Page Type we can't also assume that child Page Type can only be placed under that parent 😦.

The Page Type restrictions need to be setup on both ends to be really affective. The parent should have a limited number of child types and the child should have a limited number (often 1) of parent types.

This can be easy to forget, so we should double check πŸ“ before we deploy our Page Types to a production environment.

Clean Up Allowed Page Types

Additionally, if the requirements of the site allow for a single Video Library (ex: we don't need a Video Library per product line) we can create the Video Library page at the root of the site and then remove the Root page type from its Allowed Parent page types πŸ€”.

This has the benefit of ensuring only 1 Video Library will ever exist and reduces the options anyone has when creating a new page at the root of the site. "Landing Page" might appear in that list, but "Video Library" never will 😎.

We should give administrators the tools they need to not only do their job, but do it well πŸ‘πŸ», by helping them focus on the work that is impactful - not making decisions about things they don't want to do anyway πŸ‘πŸΎ.

In the screenshot below we can see that I've removed the Allowed parent and child Page Types for the Video Library page:

Video Library Page Type - Allowed Page Types configuration

Now, if we try to create a new page under the Video Library in the Content Tree, we can see the application limits us and provides a helpful message explaining why we cannot create any pages here:

'Cannot create new page' message in the Pages application

As we'll see later, this is helpful in creating and organizing "Content Libraries" in Kentico Xperience 13 🧐.

Disable Linked Pages

Kentico Xperience 13 has a Linked Pages feature that enables creating a copy of a page to another location in the Content Tree without copying any of its content 🀨.

I have used this feature in some very specific situations, but in general I avoid it. Duplicating pages can cause confusion related to where content of this Page Type should be created and there are many other ways to share and reuse content on a site. Linked pages also have some limitations 🫀 that we should be aware of if we decide to use them.

Disabling Linked Pages globally in the Content Tree is pretty simple. We first need to navigate to the Page Type Scopes application and then create a new Scope:

Page Type Scopes application

Our new Scope should cover the root of the site / and Apply to the whole section, which means all children for the entire Content Tree. We don't want to use this scope to limit which Page Types we want to use (we can do that with other Scopes), so we select Allow all page types. We will leave Allow creation a linked page unchecked, which will disable Linked Pages for the Content Tree:

Creating a new Page Type Scope to limit Linked Pages

If we want to opt-in to Linked Pages somewhere else in the Content Tree, we can create a new Scope for that section of the tree and enable Allow creating a linked page.

The net effect of all this setup is that page creation rules follow the guidance of our Allowed Page Type configuration and our content can be found in predictable locations πŸ™πŸΌ.

Conclusion

While the Allowed Page Types feature in Xperience might be simple, it's an important and powerful πŸ’ͺ🏽 tool that helps us keep content organized. Well organized content ensures we'll know where to create new content and we'll be able to govern the content we've already created.

Allowed Page Type configuration is usually dependent on our sitemap, content models, and content architecture. We want to use it to limit choices for marketers and content managers so they only have to choose between options that make sense 😊.

Setting up our initial Allowed Page Types should be followed by removing some allowed types after our page structure has been created in the Content Tree - further reducing options and confusion.

Finally, we might want to consider disabling Linked Pages everywhere except in the specific locations where it is needed.

Remember 🧐, a highly organized Content Tree can be made more flexible if needed, but it's very difficult to enforce structure on one that has been disorganized πŸ€• for a long time.

References


Photo by Jordan Madrid on Unsplash

We've put together a list over on Kentico's GitHub account of developer resources. Go check it out!

If you are looking for additional Kentico content, checkout the Kentico or Xperience tags here on DEV.

#kentico

#xperience

Or my Kentico Xperience blog series, like:

Top comments (0)