Best way to limit child depth

[alan]

I am allowing some users limited access to the Admin with Users/Roles/Permissions and adjusting Templates to allow them to create, for example, child pages beneath the top level pages on a site, and want to ensure they can only create one depth so they find they can do this:

Bios > ChildLevel1 bio1

Bios > ChildLevel1 bio2

but can't do this

Bios > ChildLevel1 bio1 > ChildLevel2 bioN

One way I can see I can achieve this

Assuming the template for Bios is called normal-page I can see that I can solve this by creating a template for the ChildLevel1 e.g. called normal-page-child, a duplicate of normal-page, and set it to use the same template file and set it so it can't create children.

Problem solved. But if later on I make a change to normal-page (adding a new field for example) then I need to remember to do the same for normal-page-child. Not onerous but if I had 20 different templates it would be easy to forget that sort of thing.

Is there a neater way to limit child depth?

Thanks in advance for any comments!

[Soma]

Enable advanced mode config. Select fieldgroup underneath the fields from the original template instead of adding them again. It then references the fieldgroup.

Or have a hook into the page list action to remove or don't allow 'new' from those pages that have certain level.

[alan]

Thanks Soma!

Going with:

Enable advanced mode config. Select fieldgroup underneath the fields from the original template instead of adding them again. It then references the fieldgroup.

as I love that DRY approach and clarity and also because I still am not at a level where this:

Or have a hook into the page list action to remove or don't allow 'new' from those pages that have certain level.

is self explanatory for my.

I wish it was, but "have a hook" is not something I understand (even though I have used it with instruction to work with Forms for example).

If there's a tutorial that would let me understand your second solution then I would be very grateful to know

And thanks again for the great pair of solutions! Cheers!

[Soma]

Hooks are sooooo easy that I have hard time seeing what people are afraid of. Once I get a minute ...

[alan]

Hooks are sooooo easy that I have hard time seeing what people are afraid of. Once I get a minute ...

I am pretty sure I will find they are (I hope!) once I get started—thanks for the offer, but as you say, only when you get a minute! Cheers!

[Soma]

Well it requires some knowledge and understanding of ProcessWire, so I lied when I saids soo easy. It's the where to hook what and how and when and what is returned and what are the arguments. Some are rather simple to figure out and some are very hard. Some even took me long time to get right, try and error

But nonetheless the basic concept is easy to grasp and some good and simple hooks are in the HelloWorld.module, that's where I started too 2 years ago.

This is example module that does remove the "new" on second level basic-page pages in the page tree. This only modifies the actions and does not prevent adding child pages via API elsewhere.

This hook is tricky as it also is all called via ajax in the page tree, so you can't simply echo something to debug.

ProcessPageList.module is the module where the actions are done, but it contains 3 classes actually, and you need to hook into ProcessPageListRender::getPageActions, catch the $options array this method returns which contains all actions as a nested array. If a method returns something you can catch it with the $event->return. So all you need to do is to remove the "New" action from the array and set it back to the $event->return. Easier said than done.

Here's a basic example module

https://gist.github.com/9493877

[renobird]

Nice one Soma!
 

[alan]

Oo... That looks like a nice exercise to go through, thanks SO much Soma!

[Soma]

Here's another one that does the "same" with a different hook on Page::addable. It's basicly the same, but this time we just set Page::addable to false and since the page list tree actions do check for this permission to add the "new" button, they simply won't get rendered anymore. So two ways, same result.

The difference is that Page::addable is also used by ProcessWire in other places not just page tree. So will not be able to add a page and see an error when you try to add a page manually with a link like /processwire/page/add/?parent_id=1001. So this may the better solution here.

Here the example module on my ever growing gist archive (hmm btw are those limited?)

https://gist.github.com/somatonic/9494427

[alan]

FAB!  Thanks Soma!

[Soma]

Just corrected a few names on the last one, as it was copied. 

[horst]

Here the example module on my ever growing gist archive (hmm btw are those limited?)

Don't know, but if yes, we will buy you additional space!

Soma, you write complete modules in the same time where others write a single line of code. (a little bit frightening)

[renobird]

I'm not fooled, there is more than one of him.

Somachine.

[Soma]

I'm probably not the slowest but by faaar not the fastest. I have my own finger system and writing English and code half blind and writing on computer since 26 years now may helps a little. But by no means do I master coding or using all potential of editor. I'm a creative who loves coding.

[Soma]

But master do i more painting. Avatar is done a self portrait using my bug (you call mouse) in photoshop 17 years ago actually.

So i look little older now.

[Joss]

ooh, better find my own self portrait then.

This one was made from plasticine:

[alan]

I'm glad I started this thread now!

Thanks for the edits Soma; So many times you've helped, VERY grateful!