Skip to main content

This site requires you to update your browser. Your browsing experience maybe affected by not having the most up to date version.


Our old forums are still available as a read-only archive.

Moderators: martimiz, Sean, biapar, Willr, Ingo, simon_w

Too many subpages slowing down interface


35 Posts   38814 Views


7 May 2008 at 10:40pm Community Member, 501 Posts

Bump, and back on topic: is there any chance the filtering/grouping will be implemented in the very near future?

I still think this is a very important feature, having 500+ subpages is a real pain and memory-eating thing right now.

I managed to hack the core a little so it only displays the last 20 or something of a certain subpage/pagetype in the cms, but building the whole filtering grouping thing into the cms is a brigde too far for me, and I don't have time for it either.


17 May 2008 at 11:08pm (Last edited: 17 May 2008 11:17pm), Community Member, 66 Posts

Hi dio5
i'm not sure if i understand your problem totally.

For me it sounds like you're having a lot of 'subpages' of one page.

- child 1
- child 2
- ...
- child 500

Isn't it a solution to make some 'xxx_holders' beneath the daddy
to get less childs (fe grouped by year, and maybe subgrouped by month, etc..)?


- 2007 (xxx_holder)
- 01_2007 (xxx_holder)
- child 1
- child 2
- 02_2007 (xxx_holder)
- child 3
- 2008 (xxx_holder)
- child 4
- child 5

if think that subpage-trees are loaded as you click on daddy in cms.
so there would'nt be that much childs, and it would be faster.
(but maybe i'm totally wrong in this)

of course these xxx-holders should have 'not visible flag' set to not appear in menues...

if frontend- rendering is done using direct-sql-querys you don't need to show
anyone the backend-structure...



17 May 2008 at 11:46pm (Last edited: 17 May 2008 11:56pm), Community Member, 501 Posts

That is a solution.

However not really the best one as it would require users to make submonths/categories etc each time themselves - or really rewrite a lot of code / and making this year/montholder being created automatically, as I think having to do it manually isn't really the best thing - there's no other blog/cms in which you have to do that!

The current blog module also doesnt do this, so I think there will be a lot of non-code-savvy people facing this problem somewhere in the future.

I think this should be a core feature of the cms, to be able to restrict the amount shown, but still let them show up through the search feature.

The most simple thing I can imagine would be that you have a numericfield in the behaviour tab of every Page (so part of SiteTree), where you can set how many subpages it would display in the backend. If set to 20, it would then always show the 'last created' 20. However if you would use the cms search functionality, the others would still show up in the results.

This shouldn't be too hard to implement, maybe when I find the time I might take a look at it... although I think this would be much easier for someone knows the internals of SS really well.


18 May 2008 at 2:43am (Last edited: 18 May 2008 2:58am), Community Member, 66 Posts

In ss many things are 'Pages', because cms editing DataObjects is 'very hard'.
But if there really are a lot of objects i'ld design things using DataObjects...


18 May 2008 at 3:03am Community Member, 501 Posts

I don't use the ss-blog module either, but this goes for every kind of 'holder' that can grow into a lot of subpages... what you're suggesting is a possible 'workaround', but not a real solution to the problem imho.

Let's say you have a newsholder, with about 10 news pages / day. If you put them under a month-holder, you'd still end up with 300 subpages in the cms. Of course you can publish them under a certain categoryholder, but in the end this is all going to be too complex to maintain.

Just a simple possibility to limit the amount of initially displayed subpages would solve it.


18 May 2008 at 3:47am Community Member, 66 Posts

i've similar problems, but 'god thanks' not that much data.
i can live with hierarchical holders.

the question i think is: does someone really need to maintain all these entrys
on every day?
maybe some kind of 'archived' flag on Pages could solve things, if set entrys wouldnt be shown in std.cms usually, only if someone changes view to 'archived'.
(doing something like ... admin?show_archived=1 or else)

but who would set this flag on 300 rows ....
maybe this could be done using a simple controller-function that would set any entrys
older then fe 10 days to 'archived'...

only some thoughts...


21 May 2008 at 4:08am Community Member, 501 Posts

I made a (possibly dirty) hack for this, see

This allows for a number to be set in the behaviour tab of every page, the total of displayed subpages (eg the last 20).

It defaults to 0, which displays them all.

When the search is used, it will still show all results.
Will only work when the admin section is in /admin/, as the admin detection is a bit dirty, but so far it seems to work for me.
Rewriting LeftAndMain.php, CMSMain.php and Hierarchy completely looks a bit hard. :)


21 May 2008 at 8:06pm Community Member, 66 Posts

thx to point out, where there are the relevant code-points.
that's always the hardest part in hacking ss ;-)
the more i think about it, your solution seems to be more flexible then
'archived flag'.

but i'm not sure if sorting all hierarchy-things by date will be right.

how can someone now specify a 'different order' fe. for sub-pages in cms?
(drag and drop - reorder subpages)
ok, there would be '0' set.. Hmmm...
but to don't get bad behaviour i would add these things, only where it hurt's, and where frontend-order has nothing todo with backend-order of pages.

so here, it could be done only for blog-holder, where the sort-order
in cms doesn't matter for putting out pages on the frontend...