How To Deal With Large Amounts Of PageTypes

When you’re working on projects that have a lot of pages, it is critical for your sites performance to give a lot of thought about how to structure the websites page tree so your site works as efficiently as possible.

Episerver is an enterprise level solution that has been tested to work with huge amounts of content, however, you may find issues if you try and load several thousand page-types under a single node.

Hierarchy Is Key

On one project, I was asked to do an upgrade for the site in question had a news section. The client released 5-10 news articles a week, they also had about 200+ legacy stories. After a few years, the ‘News’ section was a nightmare for content editors to use, they couldn’t find content and it took a while for Episerver tree to load.

In this case, it was easy to sort news articles by Year and then have an alphabetical folder structure underneath it to allow content editors to easily find the articles they wanted.

To re-iterate, containers can be used for storing content like banners, news, configurations, comments, reviews, ratings, menu items etc..

Container Page

A container page is an extremely common CMS pattern. Instead of just having content pages, you create a ‘container’ type that should never be rendered directly by the website. A container’s job is to solely split the hierarchy into more manageable chucks, to make content editors live easier.

When working with CMS 7 to create a container, you just define the page as normal, via a page type definition. It will still need to inherit from PageData but you don’t have to have a view for it. The code for a container might look like this:

[ContentType(
DisplayName = "Container Page",
Description = "A placeholder to help organise the EPiServer page tree",
GUID = "9997138c-4469-4dbe-8adc-87b615f30f56",
GroupName = GlobalResourceDefinitions.GroupNames.Standard)]
[SiteImageUrl("/resources/preview/containerpage.png")]
public class ContainerPage : PageData, IContainerPage
{
}

Using this interface:

public interface IContainerPage
{
}

What happens if I create a container in my page tree?

So, now you know about container pages, when you use them outside of your main page tree it will never be publicly visible.. however… what happens if you want to use one within your ‘live’ page tree… for example, if a website visitor loads a page under a container they will see the container in the Url:

container_page

If they then went ahead and erased the last part of the URL when looking, they would see a pretty dull ugly boring page.

If you find yourself with this problem then you have several options. The quickest and safest is to create a controller for your container that simply re-directs the user to its parent. As a container page is never going to be your start page, this means a user will always see something. You can then use your container page anywhere without having to worry about it

public class ContentPageController :BasePageController<ContainerPage >
{
public ActionResult Index(ContainerPage currentPage)
{
return Redirect(currentPage.ParentLink);
}
}

Another option is to define a custom MVC route to hide the container page. Setting up custom routing is a nicer way to solve the problem but is a bit more tricky to set up. First, you would need to create a PartialRouter. What we can do is intercept all page requests for a certain page type and then modify the out going Url to then hide the container from the Url.

Conclusion

Today we’ve discussed the importance of managing your page hierarchy in order to design a system that has great performance and usability. As long as your container pages sit outside of your page tree, you have no issue. If, however, you need to add a container page within your site tree, you will need to decide how you will deal with the blank container page that will show in the Url.

The quick and dirty way is to create a redirect that redirects a user to the container pages parent, this solves the issue as no one will ever be able to view the page.

The nicer but more complex way is to create a partial router to intercept all incoming results and change the outgoing Url to hide the container part from the Url.

Jon D Jones

Software Architect, Programmer and Technologist Jon Jones is founder and CEO of London-based tech firm Digital Prompt. He has been working in the field for nearly a decade, specializing in new technologies and technical solution research in the web business. A passionate blogger by heart , speaker & consultant from England.. always on the hunt for the next challenge

More Posts

4 replies

Trackbacks & Pingbacks

  1. […] The best tip I can give you is to create a custom container page type in your project and force content editors to use them, via restricting the child page types. More information about how to do this can be found here. […]

  2. […] talked previously about the benefit of container pages in How To Deal With Large Amounts Of PageTypes . In today’s code snippet, I’m going to use the same principle, that any page type that […]

  3. […] example is setting custom icons for certain page types in the navigation tree. If you have read How To Deal With Large Amounts Of PageTypes , you could for example display a folder icon against each […]

  4. […] talked previously about How To Deal With Large Amounts Of PageTypes. So say you have a parent node with 1000 children. You don’t want to have all these pages […]

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published. Required fields are marked *