Hi devteam,

I came across some interesting feedback on Silverstripe's backend/admin performance via the review comments on the Silverstripe book at Amazon:
http://www.amazon.com/SilverStripe-Complete-Guide-Development-Wiley/product-reviews/0470681837/ref=cm_cr_dp_all_helpful?ie=UTF8&coliid=&showViewpoints=1&colid=&sortBy=bySubmissionDateDescending

I was most surprised to see the comment "The admin interface seems to slow down exponentially with site tree growth -the core of the CMS - and the book offers no text to address this issue.".

I wonder if you'd seen these? If you have, please accept my apologies. Anyhow, you may have already begun working on that issue, or even resolve it - after all, that comment was written late last year.

Many thanks,
Ken.

Hi there, I know it's a really old thread I am raising from the burried. But, I have exacly that same Problem.

I'm a really passionated silverstripe developer who tends to use silverstripe for nearly every page or app or even mobile app. Because this System is for sure the best I have ever worked with (maybe zend, synfony or rails are sometimes that little more flexible but also need that extra little code).

But now I have a client who has a Website with really a lot of Pages (about 4.000) which are spread over only a few roots (about 4). The Frontend is extremly fast but the Backend is so goddamn slow, you can't imagine.

Is there anyone working on a solution, to speed up Silverstripe Backend for Sites with that lots of Pages? If I imagine, building a Multiuser Blog, this number of Pages shouldn't be the limit. So please make sure, the Backend will also be able to handle realy high numbers of Pages.

Greetings Andre

Are you storing it all in the site tree?

if so this might help...

http://www.ssbits.com/tutorials/2010/dataobjects-as-pages-part-1-keeping-it-simple/
http://www.ssbits.com/tutorials/2010/dataobjects-as-pages-part-2-using-model-admin-and-url-segments-to-create-a-product-catalogue/

Hi, fist of all, thanks for your Advice.

The Problem is the following. I was trying to copy Typo3's Concept of the preconfigured Content Blocks (you know, select simple text, picture left, picture right, ... and beeing able to combine them one after another for one Page). To achieve this I add a Folder (which extends SiteTree and only removes lots of its tabs) to every new Page and add lots of content blocks (which also inherit from SiteTree) to this Folder. First I was thinking about building a Solution with DataObjects but the Problem with Dataobjects is, you only can have a collection of equal Dataobjects, But for my requirement I needed a collection of about 10 different Dataobjects. My client wanted to fill his Page on his own with content but was unable to work with TinyMCE. Also there are Contentblocks, which themselves have a collection of Dataobjects which are displayed in randomnly.

When starting with this Project I still had lots of Silverstripe Projects running, but never was confronted with the Problem of a slow Backend on many SiteTree Objects.

My Client is driving lots of Domains which have parts of the Sitetree in comon, but not all. I build a System, which is driving all Domains from one Silverstripe Backend. When my client is adding a new Domain, he first makes a copy of the parts of the Sitetree, which are equal to some other domains and then add his additional contents.

So Maybe a first Solution will be, to have one Installation for every Domain. Therefore I need a Possibility to dump parts of a Sitetree with all their underlaying hirarchy, images and aquired dataobjects from one Silverstripe Instance and include them to another instance. Maybe someone here has an Idea how to achieve this goal?

I wouldn't suggest that - keep in mind what ever you do with a sitetree object can be done with a data object, after all a sitetree object *is* a dataobject.

I've no idea what the content blocks thing is... I deal with templates and data. You have great control of storing many different "types" of dataobject in one... keep all of the core fields in "MyDataObject" and then deal with all the relating data in related dataobjects and shown in new tabs (again just the way sitetree deals with custom data for a custom page)

Hi Swaiba, let me explain to you, what I mean by Content Blocks.

If you add Content to a Silverstripe Page, the regular way is to use tinymce for the whole Page Content.

In Typo3 (I really hate Typo but this one concept is quite good) when you want to add content to your page, you first choose from a list of the contents type (is it a simple paragraph, or a list, or a table, or a picture on the left (or middle, or right) with text floating around it, or ...). After finishing the first block, you can add another one beneath it by selecting again one content type. This way the client hasn't to worry about all the special possibilities of the wysiwyg editor (ofcourse we all know, most clients neither understand html, nor css). He just pics his contenttype (picture left, floated by text) uploads his picture, enters his text and the content will be displayed as the Programmer has styled the template for this type of content before.

Now, if i add a collection of a special Dataobject to the Page, I can only ad one Type of Dataobjects to it. But what I need is a collection of many different dataobjects to choose from, to emulate the content blocks of type3.

The only way, to add lots of different dataobjects to a page and be able to sort them all ways you like, ist to have a page and add more pages as children to it, which can be of several pagetypes.

Maybe someone of the Devs Team can give a Note about the Progress to the Problem with the slow Admin Backend on many Pages in the Tree. Is there Work in Progress?

I would say it is possible to have a DataObject that has_many ContentBlockDataObject, then either have the ContentBlockDataObject with a "type" so that in getCMSFileds you could display different fields depending on the type (i.e. if a list, an image or paragraph of text). I've done something similar in structure.

Alternatively you could then subsclass the ContentBlockDataObject to ListContentBlockDataObject, ImageContentBlockDataObject, etc - I think this will still display as a list, if not then ContentBlockDataObject could contain a class name and an ID, then you would be able to use this to create edit the item.

To sort the rows I've seen this http://www.silverstripe.org/sortweight-module/ haven't tried it though.

If you still choose to go with the site tree (as I said I advise against it, it does hundreds of db operations per page save!) best of luck to you! And I think you might wait a while for any speedups to the sitetree or take you voice to the goggle dev list.

Hello

I did a search and found this thread. My problem is nothing to do with the size of the sitetree.

When I have

Director::set_environment_type('dev');

in _config.php

My backend is extremely slow each time I click an action button to create a new Dataobject in ModelAdmin or if I want to click a page to load up the form.

I guess
Director::set_environment_type('dev');

will break some javascript but i am not sure. I used firebug to watch the page but couldn't find anything.

If I comment out that line, things are nice and smooth.

Probably this is a tip for someone who got the same problem; or it may be a bug for someone with more javascript calibre to look at??

regards,
Ben