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've moved the forum!

Please use forum.silverstripe.org for any new questions (announcement).
The forum archive will stick around, but will be read only.

You can also use our Slack channel or StackOverflow to ask for help.
Check out our community overview for more options to contribute.

General Questions /

General questions about getting started with SilverStripe that don't fit in any of the categories above.

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

$allowed_children and $can_be_root - again


Go to End


8 Posts   9252 Views

Avatar
schellmax

Community Member, 126 Posts

23 April 2009 at 8:01pm

as i've been struggling with this issue in each and every silverstripe-project by now, und just stumbled upon it again in my recent one, i'd like to open another thread on this topic, hoping for some enlighting response - or just for some feedback of others having the same problem.

i've read every thread on this, and the point is: $allowed_children as well as $can_be_root are buggy to non-existent in cms.

- setting $allowed_children leads to the following behaviour in cms: when i select a pagetype type in the 'create' dropdown which is not allowed, the focus inside the sitetree moves to the root ('Site Content'), so when i click 'go', a page is created under the site root.
try to explain this to a client!
in my opinion, all pagetypes no included in $allowed_children should simply not be available in the create dropdown?

- for the root in the sitetree ('Site Content'), it is not even possible to set 'allowed_children'.

- $can_be_root does simply... nothing.

i think of this as an important usability issue, as a cluttered 'create' dropdown leaves the client alone in which pagetype to choose.
there are some hacks to make the best of this (for example, using the can_create function to allow only one instance of a page type), but shouldn't this be an important feature on the roadmap? to me, it's one of the last missing features to the otherwise very thought-out cms.
or am i completely wrong and there already is a simple solution to this?

any feedback is much appreciated!
max

[sorry for the cross-post, originally i posted this in the 'all other modules' forum where it definitely does not belong]

Avatar
Carbon Crayon

Community Member, 598 Posts

23 April 2009 at 10:46pm

I totally argee and have had exactly the same behavior.

I created a couple of tickets but as of yet they have had no response:

Can be root
http://open.silverstripe.org/ticket/3762

Allowed children
http://open.silverstripe.org/ticket/3757

Tree reset 'bug'
http://open.silverstripe.org/ticket/3756

You can get allowed children to work if you use a function to return the array like this:

 function allowed_children() {	 
		 return array("Page"); 
   }

Anyway yes it's very frustrating and I am actually considering hard coding the top level of the intranet I am currently building as it is essential that no pages are create at the root and with potentially 200 people editing the site it seems likely that someone will do that, especially with the tree reset bug mentioned above.

Avatar
schellmax

Community Member, 126 Posts

24 April 2009 at 4:38am

hi aram,
thanks for posting, good to see i'm not the only one struggling with this.

unfortunately, i can't exactly follow the description in your bug reports:

concerning $allowed_children (http://open.silverstripe.org/ticket/3757):
the solution you mention here (using a function to return array of allowed children) doesn't make anything better, at least for me (using 2.3.1).
the problem i'm having with allowed_children is that even pagetypes not included in the allowed array are nevertheless shown in the 'create' dropdown. If you select one of them, the behaviour you described as 'tree reset bug' (http://open.silverstripe.org/ticket/3756) is triggered, but in your ticket you don't mention it applies only to 'denied' pagetypes.

as for $can_be_root (http://open.silverstripe.org/ticket/3762) i agree - it simply doesn't work. confirmed also in another thread (http://www.silverstripe.org/archive/show/6643), solution missing.

could you please confirm what i'm writing here and in case, change the corresponding tickets?

thanks a lot

Avatar
Carbon Crayon

Community Member, 598 Posts

24 April 2009 at 4:49am

Edited: 24/04/2009 5:05am

Hi shellmax

The tree reset happens to me whether I have allowed_children set (function or array) or not. Whenever I click "create" the highlight is reset to the "Site Content" node, even on a fresh install with no changes made (2.3.1)

As for the allowed_children function, that was the only way I could get SS to stop the pages being added underneath. As a rather lame result they go to the root instead. Using the array has no effect at all as far as I can see, I can still add the pages under a page that has the array set to disallow that child.

I agree that SS should remove pages that cannot be added from the dropdown but I don't believe that is the intended functionality and so cannot be put down as a bug.

Feel free to add your experiences to the tickets as I think the more info on there the better :)

Avatar
gp

Community Member, 5 Posts

23 June 2009 at 10:00am

Edited: 23/06/2009 10:10am

Hi,
I'm not sure if my problem is related to this issue but... I'm currently working with 2.3.2-rc4 and even though I set

static $allowed_children = 'none'

I can create children to this Page.

There is a line of code in SiteTree.php (function 'canAddChildren'; line 601) that says:

if($member && Permission::checkMember($member, "ADMIN")) return true;

So, this line breaks the allowed_children definition, right? Or am I missing something? But why should have an administrator the right to add a children to any Page?

Avatar
schellmax

Community Member, 126 Posts

8 July 2009 at 9:24pm

Edited: 09/07/2009 8:55pm

i posted a solution for both $allowed_children and $can_be_root on the bug tracker.
it's a javascript hack which removes all pagetypes which aren't allowed for the current page from the 'create' dropdown.

please see http://open.silverstripe.org/ticket/3987#comment:1

Avatar
BP

Community Member, 25 Posts

3 October 2011 at 1:49am

For those who would come here with the same problem in 2.4.5 (yes, yes, you can reproduce the problem in 2.4.5 :) ) .

Please check that you are using


      static $allowed_children = 'none';

    

and NOT :


      static $allowed_children = array('');

Coding at night, i somehow thought that if I would pass an empty array it would work, however this lead to situation when limiting stopped working for ALL PAGES ! . So check your classes.

Avatar
BenWu

Community Member, 97 Posts

1 July 2012 at 1:23am

Edited: 01/07/2012 1:25am

Here is my fix for $can_be_root :

When there is no tree-node on the left is highlighted (chosen), the Create drop down will list all page types, this is not ideal. It's better only to list all those pages with $can_be_root=true.

It's best to do modify

  
public function generateDataTreeHints()
in
cms/code/CMSMain.php but i am not sure how to find out how to detect situation when nothing is highlighted. that probably needs some Javascript work rather than php.

Therefore, i have to modify

 public function addpage($data, $form)
in the same file.

just before


if(!SiteConfig::current_site_config()->canCreateTopLevel())
                                return Security::permissionFailure($this);
I add:

$tmpClass =  new ReflectionClass($className);
                         $value=$tmpClass->getStaticPropertyValue('can_be_root');
                         if(! $value ) return Security::permissionFailure($this);

When admin/editor tries to add a page type with $can_be_root=false to the root, an alert box will come up says "You can't create this page type at this location".

It's not ideal solution but it's one way to make sure only the right page type will be inserted at the root.