These publications, are they imorted from an external system, or are the client supposed to manually create and work with the pages through EPiServer?
I would have made myself a PageAdaptor
, 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
Guess you could override
protected virtual HierarchicalDataSourceView GetData(string viewPath)
It seems that all calls to get the tree goes throu here :)
@Alf: Initially imported from an external system, but they add new ones weekly from the interface.
Never display the child item directly, but find it from the container and give an edit link there?
Wrote a blog about this
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?