silverstripe-cms
silverstripe-cms copied to clipboard
[2012-07-02] Make it easy to select all/none/changed pages, when managing site tree.
created by: @smagnusson (smagnusson) created at: 2012-07-02 original ticket: http://open.silverstripe.org/ticket/7609
In the tree view where you can click multiple items, there is no quick way to select pages.
Allow a) Select all pages b) Select none c) Select all pages with changes made on draft that have not been published
This would enable, for example, someone to be able to publish all pages that are not currently.
Needs UX thought.
Option (c) is technically not needed because someone can perform a site-wide Filter and show "Pages: Changed", and then click "Select all pages.". BUT, I wouldn't guess many people to think to do this.
Further considerations: if you are in multi-selection mode and you click sligthly on the left of the fake checkboxes, the CMS jumps in edit page mode and you lose all your selection.
I had a chat with our UX guy. If a site has enough pages where "select all for publish" is going to be useful, then they probably won't want to publish so many changes without reviewing them individually. Small sites can probably do single-select without much trouble.
I'll leave this open for the time being, and consider it when we come to build the new change set management feature for 4.0.
@tractorcow In my case the pages have been put in draft mode programmatically.
If you unpublish an holder page, all of its children are put in draft mode as well. If you have 100 children, this issue becomes quite relevant. Of course I just told to my client to not unpublish a container page anymore, but only after a good 40 minutes of pain ;)
Oh no, that does sound like a pain. :)
In 4.0 we are possibly going to have an "undo last publish action" so that hopefully will reduce the impact of this kind of mistake. :P
Removed milestone because it was tagged with change/major
, which we interpret as an API change that needs to happen prior to beta1. But reading through the ticket, I don't think it requires API changes, so hopefully re-added milestone :D
I think this is going to be more helpful when regarded as built-in batch abilities on a GridField - I don't want to invest more time into complicating the tree view components, they're a bit of a maintenance liability. GridField batch will also enable you to select based on search results etc. Either way, removing the 4.0 milestone.