Allow batching to be skipped

You can't remove it without code changes.

You present a valid problem.
Would having the views arguments in $context solve it for you? That sounds like a good idea.

On views 'bulk operations' field ,
there is another field 'Number of entities to load at once' , set this value more than the number you expected would select at a time which is by default 10. That will remove the batch process.

No, it won't, VBO 3.1 always uses a batch.

Yeah, that's a big backward compatibility break. I'm feeling this now too. I'm using ajax to execute the VBO action and them some custom JS to close a window, but now it responds with the full batch page instead of a short JSON =(

Is there any (clean) way to turn that off without hacking VBO?

What's your use case with the AJAX?
(What action are you running, on how many items, etc).

Using AJAX to execute VBO is a tricky thing with many edge cases, so I need to see which change makes the most sense.

What I did in 3.0-rc1 was:

* do a general form alter to catch my 3 VBO views and in that form alter:
** add 'use-ajax-submit' to the submit button classes
** add JS libraries: drupal.ajax and jquery.form
** add a submit handler to #submit
* in the submit handler I create and output 1 ajax command (with ajax_render() and drupal_json_output()) and exit
* in JS I've added that command's handler to close the popup window and refresh its parent/opener window

The VBO submit (action) button posts the action with Ajax and directly receives a JSON response.

What happened in 3.1 was:

* The VBO submit (action) button posts the action with Ajax (exactly like 3.0-rc1) and receives a 302 Location to the batch page
* The response is then a bunch of batch HTML that's being read by Drupal's ajax handlers

I can imagine many devs waiting for that direct response instead of a redirect to a batch page. For now I've downgraded back to 3.0-rc1, because I know that worked =)

And to actually answer your question ("What action are you running, on how many items, etc"):

* All custom actions that take nids.
* Ranging from 1 to [full page] items. A full page is 10 nodes and the "Select all" is disabled.

I'll review this after work.

Keep in mind that you had the 3.0 release after 3.0-rc1, which has a ton of bug fixes. The batch change happened in 3.1

Now I've pushed 3.0-rc1 =) It'll do for now. Until I hear something concrete from you. No pressure.

Any progress on this, @bojanz? Anything I can do to help? Try my (nonexistent) method and create a patch?

Oh man, I thought I was the only one with this issue. Here's my setup:

I have a view set up with an action to perform on the selected users (a view of users). The action I had built takes the user and detects the current node ID as an argument (the view is on node/XXX/some-action) and then in my action, does something with both the selected user and the current node.

In VBO 7.x-3.0 this worked because the view was still under the node context - you could get the node from arg(1), or arguments (I think?)

In VBO 7.x-3.1 that context is lost because of batch being forced on.

@bojanz's solution in #1 to pass the arguments in context would be much better than grabbing from arg(1) too. It's a backwards compatibility break for actions like these but moving forward I think it's the best solution.

Course issue for reference #1883368: Cannot remove course enrollment

@bojanz's solution in #1 to pass the arguments in context wouldn't restore backward compat though. My scenario would still be broken, because it relies on directly returning feedback for Ajax. The best solution IMO is to make the batch optional. You can enable it by default, fine (although not still backward compatible), I can then turn it off.

And passing in the arguments is also a good idea.

This batch thing also breaks my use case.
I have a node with a vbo in a block. I want to remove the elements selected in my vbo from my entity reference field of the node currently viewed.
To do so, I need the current node as an argument to my rule.
The only way I found to do this is to do some php and get it from the url (arg(1)).
But, with the batch, I can't do it.
See issue #1510478: Removing a node from a entity reference field with VBO

So, both solutions are good for me:
1. Remove the batch
2. pass $context
Though the second solution seems more robust.

I have very similar problem, any solution?

I've created a patch that does it all (I think).

It adds an option per operation (in the view field settings): dont_batch that will circumvent the batch/queue by executing a new function views_bulk_operations_direct_process_singles() that executes the operation for all entities (but per entity, not with all entities at once, like views_bulk_operations_direct_process() does). (I need this option, because I can't use a batch.)

If you don't use that function (because you need the batch/queue) the view arguments etc are passed to the action callback inside the batch/queue. That's because several useful variables are stored in $options AND $options is now passed into the action callback's $context arg. (This option was voted for most.)

And it's fully 3.1 backward compatible. If you don't use the settings, nothing's changed (but the extra stuff IS passed into the action callback.

Now you can:

<?php
function my_custom_action_callback($node, $context) {
  // Get uid arg directly from the View object. ONLY WORKS WITH dont_batch, because
  // the batch/queue won't have a live View object.
  $view = $context['options']['view'];
  $uid = $view->args[0];

  // Or get it from the ((un)serialized) batch args.
  $uid = $context['options']['view_args'][0];

  // Or even from the caller uri.
  list(, $uid) = explode('/', $context['options']['caller_uri']);

  // You could already do this.
  $last = $context['progress']['current'] == $context['progress']['total'];
  if ($last) {
    drupal_set_message('Good job, buddy!');
  }
}
?>

Extra stuff passed into the action callback (serialized in queue):

'view_name' => $vbo->view->name,
'view_display' => $vbo->view->current_display,
'view_arguments' => $vbo->view->args,
'view_exposed_input' => $vbo->view->get_exposed_input(),
'caller_uri' => request_path(),

I think the code is sound, but I'm not sure about the details:

• Have an option "Don't batch" which is default OFF, OR have an option "Do batch" which is default ON?
• What to call that option? (dont_batch might not be 1st choice, but I don't care about such trivials)
• It would be goood if views_bulk_operations_direct_process_singles() and views_bulk_operations_direct_process() could be combined, because they ALMOST do the same. (Could be done later, with backward compatibility even.)

I can confirm that the patch worked for me on version 7.x-3.1+2-dev base module. Thanks for your hard work!

I just tested the patch and it worked as expected. I actually used it to troubleshoot some batch / Ajax issues I was having with a specific VBO so it was nice to have this as an alternative to get to the root of my specific issue. I like the per operation setting so you don't have to have all operations use or not use batch. Thanks.

#15 patch works for me

works for me

Marking as a feature request because of the patch in #15.

Great, it would be useful for exporting into files, e.g.:
#1436726: Add integrations with Views Bulk Operations (sample VBO action to expose selected records to CSV export included herein)

There is no reason for views_bulk_operations_direct_process_singles() to exist, it is the equivalent of setting entity_load_capacity in the VBO handler settings to 1, no?
I will roll a new patch and commit it (the next time I have VBO time).

@bojanz No. If you set entity_load_capacity to 1, it will execute the action once for every item. This patch (and dont_batch) executes the action once, with all items. It's different. Unfortunately there's no way to reuse VBO code in views_bulk_operations_direct_process_singles() without potentially breaking API.

This patch also adds context to the batch, not just the dont_batch function.

EDIT: Removed comment that was not valid (my guess was wrong).

How can you completely remove a working option and break many views? That can't be worse than maybe sometimes some day have a broken action that can be fixed by the person that notices it.

All ajax actions require the aggregate function and a direct JSON response, which is easy if it doesn't batch. How can it not be an option?? Even have it as a broken option is better than it be completely impossible without hacking VBO.

Weird.

Sorry, I misunderstood the last patch and I forgot what the current codebase supports in this regard.

To clarify:
The option to execute directly instead of batching is needed, it was removed in 3.1 and it was a mistake.

The current "execute directly" code assumes aggregation (loads all entities at once and passes them all to the action), which should not be the default for when the "skip batch" option is selected, we should be executing one by one, which is what the patch does.

I'll try to clean up the code a bit and make one function handle both aggregate and non-aggregate execution, and report back with the final version.

Yes, that! Much thanks. It would be extra fantastic if the option would still be called 'dont_batch' so existing exports/imports/features still work, but that's up to you obviously. I always considered Don't Batch kinda weird an option, but I needed a solution more than nice naming.

I'm very curious to see the good result!

I've committed $context['view_info'] (with name, display, arguments, exposed_input) separately in #1548790: Adding view related information in the context of an action.
That solves half of the complaints in this issue.

The other half is the AJAX use case, for which this patch is still needed.
Here's my version, written from scratch.
Notes:
- uses views_bulk_operations_direct_process() for all direct execution.
- forwards to the queue item callback for non-aggregates, to minimize code duplication.
- makes the aggregate use case behave the same for skipped entities (The "Skipped $operation on item $entity_label" message per entity + final "Performed $operation on $count items", where $count is both the skipped and the unskipped entities).
- The option is called "skip batching" and is per view, not per operation. This still matches the use case while preventing the UX confusion of having it per-operation next to the "Enqueue the operation instead of executing it directly" option. (Also, "Bulk operation settings" are collapsed by default).
The warning could probably use some tweaking.

Possible followup:
- Change the "Performed $operation on $count items" message to only count the entities that were operated on, so not counting the ones skipped due to access reasons.

Okay guys, it's been 10 days and I need to make a release.

Did more work on the patch, improved the warning and made "select all on all pages" work when batching is skipped.

Committed in two commits:
http://drupalcode.org/project/views_bulk_operations.git/commitdiff/eb4a5...
http://drupalcode.org/project/views_bulk_operations.git/commitdiff/1796c...

Reopen for any followups.