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   40910 Views


Community Member, 1 Post

31 January 2008 at 11:03am

Edited: 31/01/2008 11:04am

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.



Administrator, 690 Posts

1 February 2008 at 10:56am

For anyone who is interested in trying to implement dynamic grouping, I have posted an implementation guideline here:

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


Community Member, 66 Posts

23 April 2008 at 9:05pm

Edited: 23/04/2008 9:10pm

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.

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



Administrator, 690 Posts

24 April 2008 at 9:11am

Hi Helmut,

Most of this stuff can be done by site developers - the tutorials cover how to do this:

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.


Forum Moderator, 922 Posts

24 April 2008 at 9:59am

Edited: 24/04/2008 10:00am

Well said, Sam.

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


Community Member, 66 Posts

25 April 2008 at 6:51am

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



Administrator, 690 Posts

25 April 2008 at 10:00am

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.


Community Member, 66 Posts

25 April 2008 at 10:08am

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