World is now on Opti ID! Learn more
AI OnAI Off
What's the best solution for managing 1,000+ child pages under a single parent?
These publications, are they imorted from an external system, or are the client supposed to manually create and work with the pages through EPiServer?
Jun 16, 2011 9:04
I would have made myself a PageAdaptor
<adaptercontrolType="EPiServer.UI.WebControls.PageTreeView"adapterType=
, and added some logic here, if the children count was larger that 50, and grouped them in 50 blocks. This way the url's are the same
Jun 16, 2011 9:07
Guess you could override
protected virtual HierarchicalDataSourceView GetData(string viewPath)
It seems that all calls to get the tree goes throu here :)
Jun 16, 2011 9:39
@Alf: Initially imported from an external system, but they add new ones weekly from the interface.
Jun 16, 2011 14:45
This is a time consuming option, but is there a reason not to make a "PublicationsContainer" template that in admin mode displays a nice layout of them with some javascript filtering options?
Never display the child item directly, but find it from the container and give an edit link there?
Jun 16, 2011 18:45
Jonas Boman
- Jun 25, 2025 7:41
Could you tell us more what kind of content is it? Editor-created or auto-generated?
- Jun 25, 2025 7:48
It is auto generated content (pages with files in page's media folder), as of today there are +3600 pages under a node for a customer of ours. Right now the editors use Ctrl + F and find function above the page tree to find content but I feel like having thousands of pages under a node is common for some type of customers and a better built-in support may be needed to manage such nodes directly in the CMS. I know that this can be managed by container pages but that requires managing the partial routing.
Jonas Boman
- Jun 25, 2025 8:05
Not able to using search in CMS?
Does the content need to be pages in CMS? How about storing it in Find index?
Does the content need to be pages in CMS? How about storing it in Find index?
- Jun 25, 2025 8:09
Search in CMS works fine and it's fast. So that's the way to find content in our scenario. The content has to be pages in this case. Technically Find index could be used but creating such a hard dependency is questionable, these pages are visited a lot and any disturbance in Find would affect visitors.
Is there a best practice for handling large amounts of pages under a single parent page?
For example, my client has a series of publications which are all published under the same parent -- 1,238 of them. This causes lots of problems with the admin interface. When the parent is expanded, you have to wait a couple seconds while all 1,238 are listed in the tree. Then, this "takes over" the tree. Since child pages in the tree do not paginate, you can scroll for many dozens of screens in either direction. Jst trying to get back to the parent to collapse it is difficult, and since you can't really see the parent anymore (or the parent's sibling -- the page below the long list), it gets hard to figure out what level of the tree you're on. It's unweildy, to say the least.
I know what you're going to say -- you need to subdivide them, into year and month folders or something. I understand this a common scenario, but my client doesn't want to do it. Year and month folders just don't make any sense in this context, and they're concerned about URLs -- they're trying to preserve some existing URLs, and moving pages around the tree changes the URL.
My client has come away from this situation thinking EPiServer's a little goofy in this regard. Their reaction is to wonder how a CMS that does everything else so well is so bad at something as simple as this. Granted, this isn't a deal-breaker issue, by any stretch, but they would still like it to work how they want it to, and not live with this odd limitation.
I experimented with something drastic --
Bind an OnLoadedChildren event. If the inbound request is to "EditTree.aspx," clear e.Children collection and add back a single page ("No Link, Just Text") with the title "Too many pages to list." So, when they try to open a node with 1,238 children in the tree, they just see this notice underneath it. Then, have a tab in the Edit Panel that lets them search through the children of that page in a GridView.
Amazingly, this worked. But while it solves the main problem, you still have problems in other situations when you use the tree (selecting a page for a Page Reference property, selecting a page to populate a Link Collection, etc.).
Any best practices here? Has anyone run into the same problem, and how did you solve it?