Add Views Bulk Operation support for node selection
| Project: | Deployment |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed |
Jump to:
This is a use case I have for which I'll be coding stuff.
I'd like to contribute this to deploy module, if there's any way some of what I work on can be integrated into deploy in a manner that's generic and reusable.
It's vaguely related to #443268: Deploy nodes based on a view in that it's concerned with being more selective and dynamic about what is deployed.
Here's the use case:
I have one source site, and several destination sites.
I have a node type, 'sponsor'.
Some of these nodes should be pushed to the destination site, but not to all of them. Which sites they go to will change, depending on which sponsors decides sponsor which site!
Sponsor nodes should also update on the destination sites, in case their details need to be changed.
So what I am thinking is create site nodes that represent each site, and hold the server URL.
This works nicely for my case, as the main site needs a list of all the destination sites anyway.
Feasibly, this could be done with taxonomy too, or a custom field on nodes where the editor selects a server from the list deploy module knows about.
At any rate -- each sponsor node knows the URLs it should be pushed to.
When the site editor edits a sponsor on the source site, they select the site in the node edit form.
Submitting a sponsor node fires hook_nodeapi(), which then:
- checks if the node is in a plan -- this plan would probably never actually get used, but serves to track which nodes are meant to be synced.
- checks the noderef
- figures out which sites are needed
- redirects to the username and password form
- runs a batch
Obviously if with #537488: Add the ability to push deployment plans without user input (for instance from cron) this process could be simplified.
So basically the system would keep nodes on the central site, and the content would get pushed out to destination sites according to how the nodes are tagged/noderef'ed, and do it when the node is updated.
Might be too specific a task for this module, but let me know if there's some of this code you'd be interested in.
#1
One thing someone suggested to me over the weekend is the ability for Deploy to integrate with Views Bulk Operations in order to make it easier to granularly select nodes for deployment. This would (probably) not be too hard and would help in your situation as well.
As far as your idea and workflow, it seems like that wouldn't be too difficult to manage. I agree that it might not be generic enough for the module itself, but it would be interesting to see what you come up with. Let me know if you need any help with the API. I've been meaning to write some developer docs for a long time, and I just never get around to it.
I'm going to change the title of this issue to more accurately reflect where I think its heading for the module.
#2
I'm going to try and break down my long list of stuff into what that could mean for the deploy architecture:
- on-the-fly deployment of items rather than a plan -- though the current system of having a hidden, temporary plan is okay I suppose.
- associate nodes with servers they should deploy to, rather than pick a server when deploying.
- probably fix the way the batch system currently reads in urls and plan ID from variables; though I don't know batchAPI well enough to suggest a different way. Batches can be called from a form and therefore get parameters, but from what I can tell because you're calling two batches in succession you have to do it with menu items and drupal_goto / returning the new destination after the first batch.
#3
Yeah the batch is a two-step process, because I have to do the dependencies and weighting before I deploy anything. One thing about Batch API is it involved making multiple HTTP calls, so holding information during batch execution is difficult (this is also why you can't cache anything during a batch using $static.) If you have better solutions to the problem of using variables I'd love to know.
#4
Within a batch, there's $context, apparently: http://drupal.org/node/180528
The problem is getting stuff into the first batch, and then from the first batch to the second.
Could we just chuck a row into the cache -- http://api.drupal.org/api/function/cache_set ?
#5
I'm not sure the cache gains us much over the variables, and it could be dangerous since if someone clears cache at the wrong time we could get seriously hosed. The other thought is using $_SESSION which I'm not a fan of but it's not without precedent either.
These thoughts are off-topic for this issue though, feel free to propose ideas in a new issue if you like. The good news is I can now close this issue because, Deploy supports Views Bulk Operations! Basic instructions here:
http://drupal.org/node/623892
I hope to include a default view in a future version of Deploy, if I can figure out a graceful way to handle the VBO dependency.
#6
I would do:
// pseudocodefunction hook_views_default_views() {
if (module_exists(vbo)) {
// default view code here
}
}
#7
Yeah I was hoping there was a more graceful way but apparently not. I'm committing this now.
#8
Automatically closed -- issue fixed for 2 weeks with no activity.