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.

We're retiring the forums!

The SilverStripe forums have passed their heyday. They'll stick around, but will be read only. We'd encourage you to get involved in the community via the following channels instead:

Archive /

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

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

Too many subpages slowing down interface

Go to End

35 Posts   40884 Views


Community Member, 501 Posts

7 May 2008 at 10:40pm

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.


Community Member, 66 Posts

17 May 2008 at 11:08pm

Edited: 17/05/2008 11:17pm

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...



Community Member, 501 Posts

17 May 2008 at 11:46pm

Edited: 17/05/2008 11:56pm

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.


Community Member, 66 Posts

18 May 2008 at 2:43am

Edited: 18/05/2008 2:58am

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...


Community Member, 501 Posts

18 May 2008 at 3:03am

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.


Community Member, 66 Posts

18 May 2008 at 3:47am

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...


Community Member, 501 Posts

21 May 2008 at 4:08am

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. :)


Community Member, 66 Posts

21 May 2008 at 8:06pm

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...