Forum posts to 'Archive'

Re: Too many subpages slowing down interface

banal — 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 Show Thread | Post Reply

Re: Too many subpages slowing down interface

zyko — 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 Show Thread | Post Reply

Re: Too many subpages slowing down interface

dio5 — 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 Show Thread | Post Reply

Re: Too many subpages slowing down interface

zyko — 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 Show Thread | Post Reply

Re: Too many subpages slowing down interface

dio5 — 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 Show Thread | Post Reply

Re: Too many subpages slowing down interface

zyko — 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 Show Thread | Post Reply

Re: Too many subpages slowing down interface

dio5 — 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 Show Thread | Post Reply

Re: Too many subpages slowing down interface

zyko — 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 Show Thread | Post Reply

Re: Too many subpages slowing down interface

dio5 — 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 Show Thread | Post Reply

Re: Too many subpages slowing down interface

zyko — 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

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

fe:

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

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 Show Thread | Post Reply

Re: Too many subpages slowing down interface

dio5 — Wed, 07 May 2008 22:40:04 +1200

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.

Posted to: Too many subpages slowing down interface Show Thread | Post Reply

Re: Too many subpages slowing down interface

zyko — Fri, 25 Apr 2008 10:08:04 +1200

Hi Sam,
cool to hear
and for sure, i'll stay tuned ;-)

greetings
Helmut

Posted to: Too many subpages slowing down interface Show Thread | Post Reply

Re: Too many subpages slowing down interface

Sam — Fri, 25 Apr 2008 10:00:54 +1200

As you suggest, we are developing scaffolding for all kinds of relations - has_one, has_many, and many_many. Stay tuned for version 2.3 - it will be quite an exciting release!

I also hear what you're saying about having the configuration information for the database defined in one place. I don't know if converting the static variable to a method is the best solution, but we'll be considering ways of grouping together configuration options more logically.

Posted to: Too many subpages slowing down interface Show Thread | Post Reply

Re: Too many subpages slowing down interface

zyko — Fri, 25 Apr 2008 06:51:27 +1200

Hi Sam, Hi Sean,

Nice to hear that you guys are working of some kind of scaffolding for silverstripe.
I think that would'nt be too complicated just for Dataobjects to show the native values.
of course relations will stay complicated forever ;-)
You guys have done a goooooooood job on designing silverstripe.
i like the way you do things with site-rendering and controls. a very powerful concept.
sapphire is the best thing i've ever seen till know doing db-creation.
at our company we do a lot of things using hibernate, which of course is perfect
in mapping legacy things, but not a environment for doing things rapid.
i don't like the 'ruby way' how to deal with db things. first create tables then have propertys.
silverstripe is also a cms instead of developing ruby and doing a cms totally personally.

this would only leave a few recommendations i'ld have for the product:
* use guids for id's instead of integer
(knocks out your problems with sitetree and dericed class instances
and can be created on the client side (no save necessary to get id after insert)
* use static function db() instead of static db()
would leave place for users to internally have only one array with
name, db-type, my-html-control, neede roup right, etccc
and give back these things you need for db-creation by filtering out this
'meta array'
i've seen a sample where one of you guys did something similar,
but this is not dry, because the 'name' apperas in two lists
which leads to have to maintain two lists.
(i'm not a php guru, maybe static db could be also be replaced now
with a static function getdb?)
* members and groups, i never understould, why editing a member
doesn't allow to select out of 'many groups'
* best thing to have would be a additional control to play with 'relations'
fe. for a Foo has_one Bar (means BarID column in dbtable Foo)
if showing Foo in a (popup) FORM this should show
the current 'Name' if something is 'related'.
nearby a Button [...]
if someone cklick the button, a 'search Form' opens above the current Form
there i could search for this 'class' using a few parameters.
i'ld mark the relevant element out of the search result,
the 'seach window' closes, and gives back the BarId to the original Form.
Same things could be for a has_Many
there would be a list, search form opens selection means add this to the original list
another '-' button would allow to knock out an entry from a list
(not delete the entry)
and if the search form would also allow to create new entrys
then there would be a megacool system available ;-)

yeah a know something sound's like 'a lot of work'
don't misunderstand me, i'm for sure one of the biggest silverstripe fans!!!!
but maybe you can take a few ideas for a further relase of your product...

g
Helmut

Posted to: Too many subpages slowing down interface Show Thread | Post Reply

Re: Too many subpages slowing down interface

Sean — Thu, 24 Apr 2008 09:59:48 +1200

Well said, Sam.

The "scaffolding" of fields instead of manually defining them on getCMSFields() will be a huge time saver!

Posted to: Too many subpages slowing down interface Show Thread | Post Reply

Re: Too many subpages slowing down interface

Sam — Thu, 24 Apr 2008 09:11:33 +1200

Hi Helmut,

Most of this stuff can be done by site developers - the tutorials cover how to do this:
http://doc.silverstripe.com/doku.php#level_1building_your_first_silverstripe_website

There are a few points that you mentioned that we are doing some work on:

* We are looking at developing more fine-grained permission control on the DataObjects and have that drive the forms generated.
* We are also looking at automatically adding fields to getCMSFields() when you create $db, $has_one, $has_many, or $many_many entries.

However, a complex data-querying interface is unlikely to ever make its way into the core CMS.

SilverStripe CMS is Designed For Content Authors. Not developers. We really dislike the fact that other CMSes bolt developer-only functionality into the CMS and it gets in the content authors' way. It is much more important to us to have an interface that doesn't stand in the way of authors updating content.

SilverStripe is built on the philosophy that there are a number of different people who come together to make a website: designers, developers, authors. Each of these people already have tools that enjoy using to do their job.

In particular, designers and developers have PHP and HTML/CSS development tools. So, we let them use those to build a SilverStripe site. Not the CMS interface. That is for the authors.

What this means is that a lot of development work on your site needs to be done in template and code files. This is by design.

Posted to: Too many subpages slowing down interface Show Thread | Post Reply

Re: Too many subpages slowing down interface

zyko — Wed, 23 Apr 2008 21:05:22 +1200

Hi guys,

I've a lot of typo3 websites running.
the backend in typo3 3 is the best i can imagine.

maybe you can take a few things out of there.

http://typo3.org/documentation/document-library/tutorials/doc_tut_quickstart/0.1.0/view/1/11/#id2856754

this is done using the following things, which would be fine for a silverstripe redesign.
i'll try to translate things into silverstripe words:

* Any DataObject should include a 'has_one' to a SiteTree Entry (Page)
* Someone can specify a PageId, where new DataObjects will 'take place'
if not a CMS-user creates such a record on a SiteTree.
(fe: for guestbook)
* Rights on db-Fields for cms-users should be defined within User-Groups
there's a need for a 'std-getcms-fields' implementation which
will knock out fields a user can't see.
* viewable ways for fields should be seperated from 'form building'
(anyone can do this, of course for himself, also now)
* then there should be a 'view all DataObject' Form attached to any SiteTree Element
where user can filter for 'type' of DataObject and specify db-field filter values
he has the right to see.
and he should be capable to define the fields, he wants to see in the list.
pagination, etc...
If then 'clipboard' and 'editing only subset of column values' within the list
from typo3 would also be available, it would be christmas-day ;-)
* then editing one DataObject meens Popup 'std-getcms-fields' implementation
which will show these fields he is alowed to change.
* When 'querying' DataObjects on the frontend, one could define a 'starting' point
where to look for records AND a 'nesting level' how deep 'childs of the SiteTree'
would be searched too for these records.
This is the simplest way to seperate instances for multiple cms-users.

Don't misunderstand me.
SILVERSTRIPE IS A TOP product.
but backend till now is a little weak...
Of course a few of these things cany anyone do for himself.
but a general 'backend-DataObject' admin tool would be
cool for anyone to have...

g
Helmut

Posted to: Too many subpages slowing down interface Show Thread | Post Reply

Re: Too many subpages slowing down interface

Sam — Fri, 01 Feb 2008 10:56:50 +1300

For anyone who is interested in trying to implement dynamic grouping, I have posted an implementation guideline here: http://doc.silverstripe.com/doku.php?id=recipes:customising-the-hierarchy#dynamic_grouping

It's a pretty challenging piece of work, but it's doable.

Posted to: Too many subpages slowing down interface Show Thread | Post Reply

Re: Too many subpages slowing down interface

Rich — Thu, 31 Jan 2008 11:03:40 +1300

This is relevant to my interest.

I recently found SilverStripe and am testing it out for as a possible framework to create a new website for the 82nd Airborne. I know that within a few months, it will have a few hundred if not thousand articles.

I love this platform so much more than Joomla, and would like to see one of the afore mentioned solutions developed. As mentioned before, a combination of both would be great. I could make it a site default to only return the entries for the past month or two weeks, and dynamic grouping takes care of the rest. Of course, any of these options/filters can be changed on a by user basis.

Cheers.

Posted to: Too many subpages slowing down interface Show Thread | Post Reply

Re: Too many subpages slowing down interface

dio5 — Wed, 30 Jan 2008 11:01:41 +1300

Putting this interesting thread back up a bit

If anyone has any hints on a temporary solution for this?

I was thinking of using can('view') in combination with a date comparison but that only works on the frontend, so is not an option.

Posted to: Too many subpages slowing down interface Show Thread | Post Reply

Re: Too many subpages slowing down interface

Ingo — Sat, 12 Jan 2008 11:37:58 +1300

@dio5: i think this is outside of the scope for a GHOP-task - we need to discuss/architect this feature properly, which in turn means a lot of preparation/mentoring-effort and a way longer timespan than the average GHOP-task.

Posted to: Too many subpages slowing down interface Show Thread | Post Reply

Re: Too many subpages slowing down interface

simon_w — Fri, 11 Jan 2008 10:29:39 +1300

someone really should add in a subscribe button.

Posted to: Too many subpages slowing down interface Show Thread | Post Reply

Re: Too many subpages slowing down interface

dio5 — Fri, 11 Jan 2008 10:09:55 +1300

Maybe I can add this to the GHOP list? Or is this too complicated for that?

I know simon_w seems to have time enough for coding? :-P

Posted to: Too many subpages slowing down interface Show Thread | Post Reply

Re: Too many subpages slowing down interface

Tim — Fri, 11 Jan 2008 10:05:56 +1300

I'll be pushing to see this done as part of the 2008 Summer of Code, so I think it would be a safe bet that (or something which give the same end result) will be done this year, though its hard to give a date - probably between May and December 08.

Posted to: Too many subpages slowing down interface Show Thread | Post Reply

Re: Too many subpages slowing down interface

dio5 — Fri, 11 Jan 2008 08:11:11 +1300

Just replying again to subscribe... (forgot it earlier).

I think this is a pretty important something, and I personally can't wait till this is released.

Posted to: Too many subpages slowing down interface Show Thread | Post Reply

Re: Too many subpages slowing down interface

Fuzz10 — Thu, 20 Dec 2007 03:28:55 +1300

Just a subscribe reply ...

Nothing to add, please continue.. ;-)

Posted to: Too many subpages slowing down interface Show Thread | Post Reply

Re: Too many subpages slowing down interface

Matt ASh — Wed, 19 Dec 2007 21:41:21 +1300

@Tim: Sorry about the confusion. I should've realized you were talking about something which still needs to be developed. I got a little excited

Again, I would say both of these options would adequately address the issue. Whats more, I think they are both worth developing, as opposed to one versus the other. There are certain circumstances where one option would be more appropriate to use than the other. Going back to what I was saying, I believe having the ability for them to be nestable would be a great feature, and would expand its usefulness. As Silverstripe's user base begins to grow, and more content is created on Silverstripe run sites, I'm sure this will be an important issue. I wish I could give more feedback, these are the only ideas that I have. I'll be sure to post anymore that I might have.

In the meantime, as far as my situation is concerned, you suggest that I implement that solution from the trouble ticket above, and perhaps move my older articles in a Archived news section?

Because the options you've suggested are important to me, and I would like to see them implemented soon, I'd love to contribute to the development somehow, but unfortunately I feel as though I'd have a lot of catch up to do, not having looked at Silverstripe's Code much.

Posted to: Too many subpages slowing down interface Show Thread | Post Reply

Re: Too many subpages slowing down interface

Tim — Wed, 19 Dec 2007 20:59:46 +1300

Thanks for your feedback guys. Just to clarify, this functionally doesn't exisit yet - this is the first time it's been ever talked about - if enough people think it's an good solution we'll look at implementing it. That said, we can discuss how it would best work.

Re: "grouping" the best way to make this work IMO would be to allow the user to choose a field on which the grouping would be done, it could be date (as suggested by Matt) or Author (as I had used as the initial example), or price in an e-commerce store, or basically any field which is common to a group of pages which your trying to filter.

I think making these filters nestable would be a good idea.

Posted to: Too many subpages slowing down interface Show Thread | Post Reply

Re: Too many subpages slowing down interface

Matt ASh — Wed, 19 Dec 2007 16:03:49 +1300

@Tim: fantastic response, you've offered some viable solutions. I've never look into either filtering or dynamic grouping (Would they be covered in the wiki somewhere, a quick search didn't return anything?).

The dynamic folders seems like they would be the most intuitive for my users, but I have a follow up question. Can dynamic groupings be nested? I ask this because I would like to know if instead of having the pages grouped by Authors, they could first be grouped in years, and then months. For example:

- News
- 2007
- Janurary
- February
- March
- 2006
- ....

This seems like it would be a fine solution. If not I could just implement the filtering option.

Thanks again.

Posted to: Too many subpages slowing down interface Show Thread | Post Reply

Re: Too many subpages slowing down interface

dio5 — Tue, 18 Dec 2007 06:26:04 +1300

Author grouping would be nice, but very dependent on the blog module I guess.

The thing I'm building now is pretty much the same as the blog module, but not working as a module. It also allows multiple authors that are members in the security section , with different permissions etc..., different countries per entry, etc.. so if the grouping is only in the standard blog module, that would not bring a general benefit for anyone else. (although very nice.)

Filtered folders based on the entry-date ('created') is more interesting. I assume this can be built in pretty easily as an option? (Even if that is a 'simple' one.) Some kind of dropdown list where a user can choose between let's say the last 5/10/20/50 etc 'subpages'? ( in batch actions or so? ) I think this is something that can be built in standard in SS as it would work for every kind of 'sub' page. I'd love to see this implemented because I know that by the end of next year the site will have more than 200 - 300 subpages and that would be hell to manage.

Posted to: Too many subpages slowing down interface Show Thread | Post Reply