The Subpage builder is the perfect way to create complex & dynamic template-based structures… and it would be even more powerful if the panel could delete pages that contains subpages with a deletable:true property.
My use case is an event page with a statistics subpage… every event – when created – will have a “/event-xyz/stats”. The stats page (ideally) shouldn’t be accessible in the panel (hiding pages would do it) so I could work it in the frontend’s template.
If the child’s page(s) blueprint(s) have the deletable:true property than it’d be ok to delete the parent page along with its child-siblings. This way we’d have control over what can be deleted and what not… and avoid the risk of the user losing information by deleting pages with subpages inadvertently.
so when you delete the parent, children are deleted too, even if they they have deletable: false.
Ok, I know it sounds like a stupid idea and not what you’re looking for, but… Let’s say we have a parent page and its subpages created with the subpages builder, something like /event-xyz and subpages /event-xyz/stats, /event-xyz/schedule and /event-xyz/speakers. They work as a whole, the parent page uses subpages as data providers.
You don’t want users to delete a subpage as it could break the parent, so it seems logical to set deletable: false on children. But what if users want/need to delete an event? The force value would enable them to delete the group of pages + subpages as a whole.
Edit: just after I wrote that, I checked and there is a way to force deletion, at last through code:
@param boolean $force Forces the page to be deleted even if there are subpages
As far as I know, it’s not possible in the panel.
The point isn’t the syntax itself… but the ability to manage pages in the panel in a more flexible fashion. Which together with the automated subpage creation offered by the subpage builder we’d have an awesome duo. Automation and flexibility.
Both Deletable: force or true
Would indeed give us such automation & flexibility.
Your example is perfect… when subpages act as data providers.
Regarding the $force @param I believe that most people wants to keep the page management to the CMS panel itself with the ability to offer this “curated” experience to the end user… instead of fiddling with templates to manage (delete) pages outside of if.
I didn’t think about it earlier, but the new hooks may already make this possible: when panel.page.delete is triggered, you could check if the subpages are deletable, and if they are delete them. I didn’t test it though.
Has anyone figured out how to make something like deletable: force happen with the delete button visible on the panel? That would really help me, because I can’t ask the later users of the forms I am building to do something outside the panel since they don’t know anything about computers…
I hope y’all don’t mind me bumping this after so long.
I think this is still relevant (for me anyways) and I can’t find anything on why this has been abandoned (was a milestone for a while on Github, but then un-milestoned again).
Or maybe there is a way to do this now, but I can’t find it in the docs? If so I would be thankful for a quick heads-up on it here.
Thx!
Are there any news on this one? It’s been a while since this topic got opened but I think it is still very relevant.
Even when deleting is enabled, a page with subpages cannot be deleted. You have to delete its subpages first.
This is a really annoying constraint to have and you have no option to get around. Right now I am working heavily with the modules plugin where every module is a subpage. So basically my client has sometimes to delete up to 7+ modules before he can delete the subpage itself . I guess he has to use Filezilla for this.
I too think that has to be fixed. Especially since the structure fields still rely on modals and can’t replace subpages for the most part because of the “no modal inside modal” issue.
I couldn’t find an issue on GitHub regarding this, was it deleted?
I feel really bad pushing this old thread again after @itWilllBeOK and @Andi-Lo already tried before me, but it really is a major issue in my opinion.
Let me clarify why I think this is so important:
Kirby is a wonderful tool to not only create smaller websites with simple structures. It’s also an enormously flexible tool to create complex websites. The team excels at providing more and more clever solutions while keeping it clean and simple (Looking at you, permissions). I feel like this approach translates to my own work when building a website for a client with Kirby. I never thought and cared that much about an easy editing workflow with Typo3, Wordpress or any other CMS. And I see amazing ideas and innovative solutions in the Kirby forum, themes and fields that show me I’m not alone with this mindset. Some of these solutions are the modules plugin, modules field and the revisions plugin.
The modules plugin and field offer a welcome alternative to the pages and the structure/builder field. I cried tears of joy when I read the plugin threads in the forum since this approach cleared a huge obstacle and made room for all kinds of complex scenarios, but even more important: keeping it simple. The quintessence of Kirby for me. It differentiates parts of a page from actual subpages while providing a way to nest objects and not having a modal hiding and disabling page functionality like uploading images or viewing other fields. Especially since the structure field still relies on modals and the subpages can’t be called anything else than pages the modules plugin is essential when aiming for an intuitive editing experience in the panel on a complex page. Want to insert an image gallery anywhere you want? An accordion? A user defined form? News articles? Editorial blog posts? No problem.
The issue with the modules plugin and field is not only about having to delete all the subpages of a page before being able to delete the page itself. That’s also inconvenient, no matter what plugin or if you even use plugins. The real problem is you should hide the modules page from the panel user if you don’t want to confuse him/her.
Same problem with the revisions plugin. It creates an invisible “revisions” subpage and therefore makes it impossible to delete any pages.
Even simply using the amazing and built-in subpage builder makes it hard to delete a page.
I hope this explanation of my motive and reason help more than a simple +1 on the GitHub issue. It really is an important topic for me and many of my current and upcoming projects.
If the issue is harder to fix than it looks to my (not even understanding half of the things going on in the Kirby core) eyes, if I’m simply overlooking something, or if it’s not as important for as many people as I believe, I’d be really happy to hear your comments.
I really feel the same there. We got such nice plugins to build complex sites that really enhance usability and user experience in the panel. Yet we can not let the user manage page deletion like we want? If my client wants to bulk delete a page with lots of modules and sub-pages he would have to mess with SFTP through a gimpy explorer UI, while having the fear of deleting something important and break the site… that makes the user sad.
I agree. Adding to that, I’ve never given a client FTP access and do not want to do it anytime soon. I like to sleep well at night.
You mention the plugins and I’ve focused on them in my explanation too. But even using the built-in hide: true option for pages is often problematic and therefore totally useless as long as the issue persists.
I’d just like to push this subject. I don’t understand how this is not possible yet. With the development of the Modules Plugin it should have been implement as well.
I just started getting acquainted with modules and I’m amazed by the possibilities. Having to figure out that I can’t really use it in client sites because of this issue is a big bummer.
I hope it won’t be forgotten and implemented soon.
@ola I tried to hack the panel multiple times and thought it would be simple but sadly there seem to be multiple layers of protection. I think it’s not just about somewhere adding the $force to true as documented here. For example the delete action in the sidebar doesn’t even get displayed, and the action /delete gets disabled additionally.
If anyone successfully achieved this I’d be really happy to use this, too.
. I guess he has to use Filezilla for this.
