Container pages
A pretty common pattern when developing EPiServer sites is to have pages that should not be addressed directly by a URL. They should be treated as pure content objects which can be used to:
- Contain other pages (like article comments that today would be under a root called "[Comments]" (as a “folder” really).
- Contain global settings used on other pages on the site.
- Contain snippets - small reusable pieces of content that is used throughout the site (like banners, etc.).
Today, these pages need to be hidden away from the site and the developer needs to make sure that these pages cannot be loaded directly.
Introducing container pages
To remedy this EPiServer CMS 6 R2 comes with built in support for pages that should not be visible on the web site: “Container pages”. Container pages are pages that has a page type that does not have a template file defined. This means that these pages are not accessible through a direct URL. These pages can be used to store and edit data on the web page and it’s possible to use the data through developer API: s, the fetch data functionality as well as dynamic content page properties.
In short: these pages can be considered as internal pages that should act pretty much as other pages internally but externally they are never visible unless a partner developer or editor fetches the data for these pages.
How container pages differ from regular pages
- They are shown differently in the page tree (lighter grey color and a custom icon).
- These pages have no preview.
- It’s not possible to create links to these pages (this is also the case for ”no link, only text”-pages). These pages are visible in the page tree when using these functions but not selectable when:
- Creating hyperlinks to these pages from an editor(TinyMCE and the EPiServer CMS 5 editor)
- Property Link Collection.
- The “Page after post” functionality for EPiServer XForms.
- Visited page visitor group criteria.
- Page link settings: shortcut to page in EPiServer.
- Property: “Url to page/external address”.
- These pages are filtered from menus on the site.
- These pages are filtered on page searches (using PageDataSource).
- There is a filter class, FilterTemplate, which can be used to filter these pages from a PageDataCollection. This filter is included by the FilterForVisitor filter.
- It’s not possible to do visual compare or side by side comparison of container pages.
- Container pages does not show the following properties by default when editing a page in the EPiServer CMS edit mode(possible to override):
- Target frame.
- Simple address.
- Visible in menu.
- Container pages can only set link type to normal link and fetch data from.
Container pages have much in common with pages set to “no link, only text”. They also:
- Cannot be requested through an URL.
- They have no preview.
- It’s not possible to create links to these pages.
- They are filtered from page searches.
- It’s not possible to do visual or side by side comparison of these pages.
Container pages and “no link, only text” have these difference.
- · They have different color and icons in the page tree.
- · “No link, only text”-pages appear in page menus though only as text, thus the name.
- · “No link, only text” are defined per page, container pages by page type.
Working programmatically with container pages
For a partner developer there is not very much that differs between a container page and a regular page (except that these pages have no public URL). The PageData class has two new properties that you should be aware of:
- HasTemplate
- IsVisibleOnSite
HasTemplate returns true if the page type has a template file defined.
IsVisibleOnSite returns true if the page can be directly addressable through an URL, which means that it exist in the public site structure. This is true except for container pages and pages set to “no link, only text”.
Setting a page to appear as a container page programmatically
It’s possible to set the HasTemplate property on PageData, for instance when loading a page from DataFactory. This will make them appear as a container page even though the page type has a template file defined. The following code sample shows how to set pages with the page type id “4” to appear as container pages:
1: protected void Application_Start(Object sender, EventArgs e)
2: {
3: DataFactory.Instance.LoadedPage += new PageEventHandler(Instance_LoadedPage);
4: EditPanel.LoadedPage += new LoadedPageEventHandler(EditPanel_LoadedPage);
5: }
6:
7: public void EditPanel_LoadedPage(EditPanel sender, LoadedPageEventArgs e)
8: {
9: e.Page.Property["PageVisibleInMenu"].OwnerTab = -1;
10: e.Page.Property["PageExternalURL"].OwnerTab = -1;
11: e.Page.Property["PageTargetFrame"].OwnerTab = -1;
12:
13: if (e.Page.PageTypeID == 4)
14: {
15: e.Page.HasTemplate = false;
16: }
17: }
18:
19: public void Instance_LoadedPage(object sender, PageEventArgs e)
20: {
21: if (e.Page != null && e.Page.PageTypeID == 4)
22: {
23: e.Page.HasTemplate = false;
24: }
25: }
This functionality is new in EPiServer CMS 6 R2 and not included in the beta release.
Wow! A very nice and useful feature. One request though: Please show the edit tab as default instead of an "error" message that the preview is not available.
This new feature sounds like sent from above ;) no really it is a great new feature.
Nice, how about a List Page, quite similar to Container Page. It should hide all it's children BUT has list tab with a sortable and searchable grid with all childrens instead.
Nice addition, this is the kind of thing most devs have had to do at some point or another using custom code so its good to see this getting baked into the core product.
+1 @Johan's request...
The short "info" message in the preview tab is actually an aspx so it's simple to add your own preview page for your container page with the asp.NET feature url mappings:
Information about page, version and language will be passed to the custom preview page making possible to do a custom "preview" of the content.
Thanks for the info Linus. Guess you have thought about everything :-)
I suppose container pages still /have/ an URL in the sense that their name-in-url must be part of the URL of subpages? But if you browse to it you get 404? 403?
Yeah, the container pages still have a unique URL-segment. A direct request to the "URL" of the page results in a 404.
Great addition!
Is there any way to make the Container Pages selectable from PropertyLinkCollection? This could be useful if you would like the editor to have the ability to select several container pages. E.g. selecting a number of news items that should be shown on the start page.
Unfortunately not. Since these pages have no links to store and PropertyLinkCollection works with links it's not possible. We know that it's used this way today by some but will address this by adding better support for multiple items properties in the future.
Or how about a Container Page Picker property that can be used to select Container Pages? We need the ability to add x number of Container Pages to a property. E.g. people to a contact page or POI for a Google Map.
Thank you EPiServer! We have to do this sort of thing custom all the time; great to see it brought into the product.
Great! Really gonna use it!
Though, will the container add a URL segment?
Sometimes the container is used to group the pages/content/data into a way that fits the clients daily work but we don't want the grouping to make the url longer.
for example: domain.com/products/productgroup1/tshirts/mybluetshirt
would be nice if it was domain.com/products/tshirts/mybluetshirt
using simple url is too cumbersome when maintaining a larger product base and modifying a url rewrite provider to "skip" the group when accessing the page creates trouble.
@Alf: Yes, container pages will create an URL segment exactly as normal pages. If you want to cut this short I guess you need to create your own URL rewrite provider (though I myself have not tested this and can not guarantee that it will work). You need to take into consideration that you might have several nodes that have the same shortened URL though if you try this so you need to take that into consideration since EPiServer ensures that the URL segment structure is unique.
Hi Linus, you mention in your article that the functionality is new and that its not included in the beta release, will we be able to test this before the R2 release?
Thanks for a great post
@Diego: Unfortunately there will not be a public release of CMS 6 R2 to test test/give feedback on this. But the final release is really getting near now...
This feature is useless in the current form IMHO. At the very least the container page URL segment should be completely hidden. It would also have been been great if a container's child page ParentLink property returned the first "none container" parent and that container pages was invisible in the eyes of the GetChildren method.
The only thing the feature really is now is a ugly error page with a page tree icon for container pages...
Thank you for your feed back Johan. The container page feature, as implemented at the moment, surely has it's advantages. But it will not solve all problems that are related to non-visible-pages and in some cases, none of the functions you want to implement. See it rather as a base to make some non-publicly-visible-page-functions simpler.
Regarding the GetChildren and ParentLink I don't agree with you. In my opinion, it's not up to the repositories and data classes to do this filtering. There are filters that will filter out container pages if needed but you might as well need to do this logic yourself. In a bread crumbs control for instance, you might want to show container pages but without links or just skip them entirely but that is up to the presentation layer.
Regarding the URL segment it is still used to calculate the URL. Of course it would be nice be able to clear this for a container page to be able to skip this in the URL-generation but this might result in conflicts with sub pages under two sibling container pages to get into URL conflicts. This might perhaps be something to consider for the future but was not included in the scope for the first version.
Thanks for the Post.
This does not hides or removes the container page name from URL. Is there a way out using which the container page name can be expluded from the URL?
A container does not have an URL, that's the entire point with these. Also, container pages have been obsoleted in EPiServer 7.5. A page get's an URL if there is at least one public template assosiated with it. The other functionality, like the custom icon, can be accomplished in other ways as described here: http://world.episerver.com/blogs/Linus-Ekstrom/Dates/2013/12/Customizing-the-look-and-behavior-in-the-UI-for-your-content-types/
The site is built using EPi 6R2. There are couple of page types which are used as container while arranging hierarchy in edit mode.
Now when i browse the child page it also shows up the pagename of it's parent.
Is there a way through which i can restrict certain parent page names in URL which are used just to hold hierarchy?
Example:
From(http://samplesite.com/News/2014/News1/newsitem)-->to(http://samplesite.com/News/News1/newsitem)
From(http://samplesite.com/News/2014/News2/newsarticle)-->to(http://samplesite.com/News/News2/newsarticle)
2014 being a parent page holding bunch of descendants.
Hi!
I don't think that this is possible in EPiServer CMS 6 R2. EPiServer CMS 7 was released over two years ago so I would say it's really time to upgrade your site. The main reason why this would make it simpler for you is that EPiServer CMS 7 uses the build in routing in asp.NET to route to pages. EMVP Joel Abrahamsson has written a nice blog post about how to customize routing to pages in EPiServer CMS 7: http://joelabrahamsson.com/custom-routing-for-episerver-content/
Linus you said container pages were made obsolete in EPiServer 7.5. What was it replaced by?