Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.I made the suggestion over at (http://drupal.org/node/587308#comment-2080710) in the issue #587308: Batch migrate sites between platforms. about converting the sites listing table to be a bulk site operation form similar to the way view_bulk_operations module works or the admin/node/content page.
I decided to take a stab at this feature myself.
The idea is that where ever the sites are listed (all sites, client, platform pages) you can perform bulk operations and number of those sites with only a couple of clicks.
Some simple use cases may include "disabling all sites under a client" or "backing up all sites" only requiring a couple of clicks rather then having to do each site individually.
It only exposes the tasks that don't require any extra options/parameters to run (e.g. backup, verify, disable, enable & delete) - these where just easier to implement, other tasks like clone and restore probably only need to be done one at a time anyway. Migrate task might be useful, although with the platform migrate feature #587308: Batch migrate sites between platforms. that need for bulk operations is probably mostly covered in that issue.
All the tasks appear in the drop down box, but before attempt to queue up any task is uses the hosting_task_menu_access function to validate that a task can be performed on each site by the user requesting it.
There are a few minor CSS issues displaying this form on the client and platform pages and the code probably could be cleaned up a little but otherwise it works.
I've also attached an image of how it all look as well.
| Comment | File | Size | Author |
|---|---|---|---|
| #8 | hosting_bulk_operations-588204-8.patch | 13.82 KB | univate |
| #6 | hosting_bulk_operations-588204.patch | 14.3 KB | drumm |
| #4 | hosting_bulk_operations-588204-3.patch | 12.19 KB | univate |
| #2 | checked.png | 92.45 KB | mig5 |
| #2 | checked2.png | 50.22 KB | mig5 |
Comments
Comment #1
univate CreditAttribution: univate commentedAdded an extra permissions check so that users that don't have permission to execute certain tasks wont see that task in the list of operations.
Comment #2
Anonymous (not verified) CreditAttribution: Anonymous commentedSo functionally this is working very well and such a great idea to jump on the recent Batch work that was done recently with migrations and make it work elsewhere! Nice work univate :)
After testing it, there's a few teething problems to iron out:
1) When I check a checkbox against any site to apply a task to it, the site name is filled with the status icon.. see the 'checked.png' screenshot for sites that are OK and checked2.png for those that are currently disabled/problem with a recent verification. It occurs on a single check of a site or multiple, or all.
2) On the confirmation screen when submitting the batch operation, the name of the task is being concatenated to the end of the description of the task. See 'confirmation.png' attached, where the message says 'Generate a backup of this site that can be restored to at any timebackup' instead of just 'Generate a backup of this site that can be restored to at any time'
3) The drupal_set_message when submitting batch tasks reads 'task in task queue for each of the sites.' Looking at the code, it's meant to be prefixed with the name of the task itself:
I also think it sound read more easily, something like 'The task @task will be applied to the selected sites and have been added to the task queue' or something perhaps less wordy, but more friendly.
4) There are some logic problems that will take some more thought:
The list of available tasks in the combobox include things like 'Enable' as well as 'Disable'. On a single site view, the menu tabs are a bit more careful i.e they will only show Enable if the site is Disabled, or vice versa.
As well as this, we have some extra checking by way of 'safe tasks' around line 37 of task/hosting_task.module, designed so that the 'main' aegir site cannot actually see such tasks as Migrate, Disable or Delete
First of all, we shouldn't be offering the ability to Delete a task if it isn't Disabled first, but both options will be available to the site in this UI. (*Can* we handle that when we have this bulk task against multiple sites? Maybe we just give up on the logic of showing some tasks but not others?)
So immediately since the option is available to me, I tried to Delete my 'main' aegir site and see what happens:
I get told the site failed verification, on the submit form which still renders. I click Submit and I get a foreach exception as well as the drupal_set_message 'task in task queue for each of the sites'. (see foreach.png)
I think I implemented a fix in my last reroll of the batch migrate task patch in that ticket #587308: Batch migrate sites between platforms. that stops the foreach exception, but I don't think I came up with a good alternative to showing the Submit form
Comment #3
anarcat CreditAttribution: anarcat commentedHow does this compare to views batch operations? We're looking at #588728: Meta: Views integration redux for 0.4...
Comment #4
univate CreditAttribution: univate commented1) CSS is not one of my strength, but I attempted to fix this, there are still some issues on the client and platform pages which i think need to be fixed in eldir
2) Fixed
3) Updated
4) Agree there are some usability issues here that probably need to be discussed further, not sure how you can remove any of the tasks though as its possible you may want to enable a group of site and disable another group of sites and delete some others? I've made a couple of small fixes to the batch process and cleaned some of the workflow/messages a little, including the foreach error your got.
There are checks happening before trying to run a task on a site by calling the function hosting_task_menu_access (which is the same function used to determine what tasks are enabled on the site page). So you shouldn't be able to delete your main aegir site or perform a delete on a site not enabled, even though the task is available in the list.
As for the issue about whether this should be done with views bulk operation module instead, that needs:
* views support (all for this feature)
* a way to check sites before queuing any tasks, as mig5 pointed out you don't want someone to attempt to disable/delete their main aegir site, even if it fails on processing the task, its a better user experience to be told that a task can't be done rather then just seeing it fail in the task queue.
* another module dependency in aegir
If this was included now, it could always be replaced when there was full views support.
Comment #5
univate CreditAttribution: univate commentedComment #6
drummAttached is an updated patch. Looks generally okay to me, but another review would be good.
Comment #7
Anonymous (not verified) CreditAttribution: Anonymous commentedLooks like this needs review
Comment #8
univate CreditAttribution: univate commentedRe-rolled patch, so that it applies.
This is a useful feature when you want to the same thing to lots of sites.
Comment #9
anarcat CreditAttribution: anarcat commentedI committed and pushed this, we'll make a beta for this.
Comment #10
omega8cc CreditAttribution: omega8cc commentedI believe it needs more work. The UX is not enough good. After the batch is initiated, it goes via update/maintenance Garland theme before it returns to Eldir.
I would also prefer to put the select and submit below and not above the list of sites.
Furthermore, the install and import tasks shouldn't be listed at all.
Comment #11
univate CreditAttribution: univate commentedI haven't seen it doing that?
But its possible there are some style issues that need cleaning up, I know they where mentioned earlier in the issue and not sure if they where all fixed.
Comment #12
anarcat CreditAttribution: anarcat commentedThis was committed, so it's fixed. New issues were opened with the remaining issues.