Forum posts to 'Site Builders'

Re: Too many subpages slowing down interface

Roman Schmid — Fri, 19 Sep 2008 21:45:21 +1200

I'm in need for a good solution to the "many subpages" problem as well. Hopefully this will be addressed in 2.3.
Subscribe and bump.

Posted to: Too many subpages slowing down interface

Re: Too many subpages slowing down interface

Helmut Zörrer — Wed, 21 May 2008 20:19:39 +1200

jepp,
only wanted to ensure, that you don't overlook this thing...
g
Helmut

Posted to: Too many subpages slowing down interface

Re: Too many subpages slowing down interface

Dieter Orens — Wed, 21 May 2008 20:11:27 +1200

True, the sort order may go wrong, but for something like a blog/news this isn't important as you'll always want them in a date-order.

Also, it's not that difficult now to build in an extra field in SiteTree in which you can set an 'order' filter.

Note that what I'm doing here, doesn't influence the frontend site (at least not for me :) ), and when you leave it at '0' it won't do anything and keep the normal order.

Posted to: Too many subpages slowing down interface

Re: Too many subpages slowing down interface

Helmut Zörrer — Wed, 21 May 2008 20:06:19 +1200

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

Posted to: Too many subpages slowing down interface

Re: Too many subpages slowing down interface

Dieter Orens — Wed, 21 May 2008 04:08:57 +1200

I made a (possibly dirty) hack for this, see http://pastie.caboo.se/200250

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

Posted to: Too many subpages slowing down interface

Re: Too many subpages slowing down interface

Helmut Zörrer — Sun, 18 May 2008 03:47:23 +1200

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

Posted to: Too many subpages slowing down interface

Re: Too many subpages slowing down interface

Dieter Orens — Sun, 18 May 2008 03:03:02 +1200

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.

Posted to: Too many subpages slowing down interface

Re: Too many subpages slowing down interface

Helmut Zörrer — Sun, 18 May 2008 02:43:21 +1200

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

Posted to: Too many subpages slowing down interface

Re: Too many subpages slowing down interface

Dieter Orens — Sat, 17 May 2008 23:46:08 +1200

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.

Posted to: Too many subpages slowing down interface

Re: Too many subpages slowing down interface

Helmut Zörrer — Sat, 17 May 2008 23:08:43 +1200

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

[code]
daddy
- child 1
- child 2
- ...
- child 500
[/code]

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

fe:
[code]
daddy
- 2007 (xxx_holder)
- 01_2007 (xxx_holder)
- child 1
- child 2
- 02_2007 (xxx_holder)
- child 3
- 2008 (xxx_holder)
- child 4
- child 5
[/code]

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

g
Helmut

Posted to: Too many subpages slowing down interface