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:

Customising the CMS /

Moderators: martimiz, Sean, Ed, biapar, Willr, Ingo, swaiba

Constraining page types

Go to End

10 Posts   2408 Views


Community Member, 67 Posts

3 September 2009 at 10:52pm

Useful suggestions. What would be best, of course, would be if the pop-up menu only contained the acceptable page type(s) for the page in question. In the CMS, if I have the News page selected, the page type pop-up is automatically set to ArticlePage, which is what I have as $default_child in ArticleHolder.php. But a user could still select a different type, but there is no good reason why those other types should be present in the pop-up at all. Is there some way of determining what appears in the pop-up?

This kind of control would be really useful if a SilverStripe system needed to be administered by non-techie users (which is half of the point of a CMS, after all). As it is, I fear a lot of damage could easily be done.


Community Member, 904 Posts

4 September 2009 at 1:15am

Edited: 04/09/2009 1:16am

You're absolutely right. Maybe you could create a ticket (enhancement request) here:
It would probably involve some JavaScript trickery to dynamically update the DropDown menu. Since everything that is needed is already defined with $allowed_children, I guess it's not that easy to implement, otherwise it would have been done a long time ago.

To add to your statement: If you add something like this to your ArticleHolder.php

public static $allowed_children = array('ArticlePage');

The user will no longer be able to create other pages than ArticlePage inside an ArticleHolder. If he chooses something else from the dropdown, the Page will be created on level 0, not as child of the ArticleHolder. Sadly, this constraint isn't checked when one tries to change the site-type after it has been created (Behavior Tab). Still, your suggestion is a much better solution and may eventually find it's way into 2.4, since the core devs are apparently already changing a lot (if not all) of the existing JavaScript code.

Go to Top