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.
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 β .
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:
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 π:
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:
What this means in practice is the following:
- Videos are only found as children of a Year/Month hierarchy in a "Video content" container inside a Video Library.
- 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.
- 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.
- 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:
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:
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:
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:
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
- Webster: Variety is the spice of life
- Scientific American: The Tyranny of Choice
- Gartner: Digital Experience Platform (DXP)
- Coding Horror: The Pit of Success
- Xperience Docs: Allowed Page Types
- Xperience Docs: Linked Pages
- Xperience Docs: Content Modeling - Linked Pages limitations
- Xperience Docs: Page Type Scopes
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.
Or my Kentico Xperience blog series, like:
Top comments (0)