17452 Posts in 4473 Topics by 1971 members
|Go to End||Next >|
16 December 2007 at 10:36am Last edited: 16 December 2007 10:38am
Forgive me if this has already been addressed in another post, but I couldn't find an answer to my question anywhere. I'm migrating an older site to Silverstripe (which I love by the way). This older site already has over 600 news items in its database. Once I figured out how to transfer these entries to the Silverstripe database as subpages of NewsHolder (I used the tutorial to set this up), I had the following problems:
- It took the Silverstripe interface forever to load because it was loading all the of the news entries. The page actually returned memory errors initially.
- It was extremely hard to manage the news entries, as they were just in one long list.
I'm having this same problem with other sites as well, which I would all love to put on Silverstripe, but can't because I don't know how to address this. By the way, I'm saying this without having upgraded my development site to the 2.2 version of Silverstripe, so if its been fixed in the new version, I don't know.
Any ideas would greatly be appreciated.
16 December 2007 at 3:12pm
(Wanted to subscribe to this topic because I'm wondering too how SS will react when there are 500+ subpages, a scenario that probably is gonna happen for me too. )
17 December 2007 at 12:15pm
There are two issues here, a general performance issue, and secondly an interface issue as the current tree interface looses much of its usefulness when dealing with such a large number of pages.
A potential solution to the performance issue is here;
I've got a number of ideas around the interface issues as well, I'll put them up here for discussion over the next week.
17 December 2007 at 4:08pm
Regarding how we deal with a large numbers of pages which have all been placed in the same folder, the root of the problem is the CMS interface isn't well suited for this, as it has been designed to show the sites hierarchy in full. On our websites we get around this problem by having a number of filters on the data (as apposed to giving the user a massive list) - and it seems a logical solution would be to enable some sort of filtering of pages within the CMS interface as well.
Here are two use cases (and interfaces solutions) to this;
Problem: You're managing your blog, and like us on SilverStripe.com - you've got several hundred entries going back over a year which clutter your screen every time you open the blog folder to add a new blog entry or modify one you've just created (and just realized you made a spelling mistake on).
Solution 1 - filter the folder
In both cases you don't care about the last few years worth of entries, all you care about is the last few entires you made (so you can fix those spelling mistakes), and when you're adding a new entry, you don't want to have to scroll though the whole list to the bottom of the tree - you just want to see a mini list. The solution - give your users the ability to add their own filters (or toggle on and off pre defined ones). In the screen shot shown (2 - Folder with Filter) the filter on the Blog page, means it only shows the last 6 blog entries published.
Solution 2 - dynamic grouping
With each field of any given page type, there are a number of common attributes, such as price on a e-commerce site, or author for a blogs. When you don't know exactly which page you want you need to browse. To help you browse, its useful if you can slip pages into some ("dynamic") groups, which enable you to drill down to find the page you want to edit. In the case of the e-commerce sites, you may wish to group all products into groups based on price, or manufacturer, or for a blog site, you may find it useful to browse by authors (as shown in screen shot.
In the screen shot the blue folders are "dynamic" folders and are not part of the site hierarchy.
I'd be keen on some feedback on this - does it solve the problem of having "lots" of pages within a single category?
17 December 2007 at 4:09pm Last edited: 17 December 2007 4:09pm
Screen shot for the above post
18 December 2007 at 6:26am
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.
19 December 2007 at 4:03pm Last edited: 19 December 2007 9:27pm
@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:
This seems like it would be a fine solution. If not I could just implement the filtering option.
19 December 2007 at 8:59pm
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.
|Go to Top||Next >|