How to Stop User Adding Top-Level Pages/Sections to a Site?

Hi all! Newbie here…

I’m trying to create a simple site where the user should not be able to add pages to the top-level of the site. The user should be able to change the content of existing pages, but not add or delete the pages themselves. The site will have pre-defined sections, and the user should not be able to delete or add to those. The site will also have a Blog section, which is the only section where the user should be able to add/delete pages (articles).

By default, in the starterkit, the Panel allows users to add/delete pages at will, at the top level. Is there a way to stop or control that?

Many thanks in advance for any guidance.

You can set that in the site.php blueprint. Just add pages: false.

@texnixe Many thanks! It does work, although it is not an ‘elegant’ solution: the “edit” and “add” buttons still appear in the dashboard, as well as the ‘pages’ link button. Is there a simple way to hide or disable these buttons when the user is on the top-level?

You could add some custom panel css and hide the buttons?

Add in config.php

c::set('panel.stylesheet', 'assets/css/custompanel.css');

This is just due to a bug, which is fixed in 2.1.

Thank you for all the wonderful work in Kirby!

It’s exciting to hear that more granular permissions are being developed.

Even in 2.1, it seems this use-case is not fully covered. In Kirby, pages: false completely hides subpages from the Panel, making it impossible for the user to edit them. On the other extreme, pages: true gives permission not just to edit existing subpages, but also to create and delete them. What is needed here is the ability to “edit only” existing pages, but not create/delete - perhaps a pages: editonly setting?

Also, in the current 2.1 beta, setting pages: false in the site.php blueprint hides the ‘Add’ button from the interface, but still leaves both the ‘Edit’ and the ‘Pages’ buttons. Clicking these presents the user with an error message, saying the page could,not be found. It doesn’t seem like this is the intended behavior.

Once again, many thanks for all the work that is being put into Kirby - it’s an amazing piece of software, and your work is truly appreciated!

Maybe I don’t quite understand, but setting pages: false in site.php still leaves the pages editable? You just can’t add any new ones. And in 2.1 beta, the add link is gone as well.

You are right though as regards the unnecessary link: The “Pages” link is still there and leads to an error message when clicked.

Yes, this works fine for the site.php - but unfortunately we would not be able to get the same result with a ‘normal’ blueprint anywhere else on the site. Setting pages: false anywhere else completely hides the subpages list from the Panel.

And the ‘Edit’ button - the one that normally appears next to the ‘Add’ button - also still remains, issuing the same error…

Oh, I see what you mean. Instead of pages: false, on the subpages you can set a max value, once that value is reached, users cannot add any more pages while the pages are still editable. So if you set that value to the number of pages you have already created, you should achieve what you want?

1 Like

Almost… because the users can still delete existing pages. And once they delete a page, they will be able to add pages again…

This is specially cumbersome when creating sites with pages made up of ‘block sections’ - where each ‘block’ is really a sub-page. You can make-do with the way things are now, just trusting that the users will not (accidentally) delete or add sections at will…

You can use: deletable: false in your blueprints to prevent accidental deletion of pages. In the pages overview, you will still see the delete button, but it won’t work anymore.

3 Likes

Oooh, I’ll have to try this out - many thanks for the guidance, @texnixe!

A quick note after trying both of the following and was still able to delete the page:

The delete: false should be part under options: for it to work, but the docs seem to suggest that it can only be written at the top-level of the YAML blueprint.

The correct setting seems to be either:

options:
  delete: false

or

pages: true
deletable: false

i.e. outside of the options