Integrate multi-page selection

I'd like to keep Views Form simple for now, and just give people a chance to use it and report limitations.
An issue an always be opened in the Views queue if someone else wants to champion it.

Nice to have in VBO though (GMail also supports this, it's a very nice trick).
#ajax on the checkboxes might be a viable approach.

Tagging.

Removing the d7 release blocker tag tag.
I spent enough time on this to finish fields.action.inc twice. And that only brought it to 50%.
Doing it properly so that it works with "select all" on current page / all pages takes a huge amount of time.
And now I managed to lose the whole patch in a freak accident. So I'm giving up. Maybe in some other release.

Sorry to hear that. :(

Do you think it'd be possible, since it's still fresh in your mind right now, to barf out some text explaining the general approach you took? That way it's possible that someone could pick up your breadcrumbs where you left off.

Good idea. Was frustrated last night, should have written down the whole thing weeks ago, when it was even fresher in my head...

The basic idea can be seen in 6.x-1.x.
After one of the VBO elements (operation selector, select all, select item checkbox) gets changed, an AJAX request (from the VBO js, no point in using #ajax cause nothing in the form changes) is fired to a VBO-provided menu callback that stores the new data in session.
Data in the session is keyed by "view id", which is a generated hash consisting of view name, display name, arguments, and the exposed input.
So when a user changes an exposed filter, or number of items per page, the selection gets dropped.
There might be ways to keep it (VBO in D6 creates a hash of each serialized row), but it complicates the code further and I'm not sure it's worth it.

The complicated parts:
1) Some actions require the full views rows to be provided to them.
I'm generally not convinced that it is even a good idea, but views_send-7.x-1.x depends on it, and we couldn't figure out an approach that is as flexible as that one (though I did argue that a bit less flexibility might not be a bad idea).
So, that means that before an action gets run, VBO only has the "row id" and "page" of each row, and needs to build the main view, execute each page that has selection, and fetch the full rows.

2) Select all on this page / all pages.
With "select all on this page" it's easy, just send all row numbers of the current page back to the callback.
Each selection checkbox has the entity id as the value, and the row number and page as additional attributes (though page might be fetchable from other places).

"Select all on all pages" is a bit tricky, because we can't know all of the row numbers.
So we just send a "select all" flag that tells VBO to fetch all rows upon execution.
But what happens when we select "select all on all pages" and then uncheck one checkbox. The "select all on all pages" gets cancelled, and only the other checkboxes on the same page stay selected. So in that case a request needs to be made to the backend that unchecks "select all" and checks all checkboxes other than the one that was clicked.

All VBO code that gets the selection from form state needs to be modified.
A first guess would be to use the selection from the session if "selection preservation" is on, otherwise use the form state.
However, there's a problem here. Each checkbox click will cause a drupal bootstrap, which takes a while (might need to port http://drupal.org/project/js and integrate with it). So a user clicks 5 checkboxes, and then clicks "Execute", by which time perhaps only 3 checkboxes ended "registering".
So I guess the best formula is: use form state for the current page, the session for all others.

The selection code grows fast, so after the first working patch is written, would be good to move the code to a ViewsBulkOperationsSelection (or something similar) class that can be autoloaded, instead of being included in non-VBO pages as well.

I've taken a bit of a look and these are some of my thoughts:

Checkboxes use ids like edit-views-bulk-operations-5 which aren't universal to the view. Using something unique like node ID in the checkbox id would be better.

Over in #1432236: Create a pager to do a submit? I discussed a way to make pagers do a post (while preserving the query string for filter and page number). We'd need unique IDs global to the view to use that type of technique.

I think the post method is better than the Ajax one. There's no need to bootstrap Drupal on each click, and on the server side you can simply store the unique IDs in the Session and get them from the form state. Any operations that need full rows can identify the correct row from the unique ID (or, I suspect what they really need is the entity itself and the unique ID would enable direct access to that.

The major issue I see is that my "solution" for the pager could charitably be described as a bit of a hack. Perhaps a custom pager using real buttons instead of wiring up links with JQuery. The form submit handler would also need to be modified to only trigger the associated actions at the appropriate time (i.e. only when the action button is clicked, not on every form submit).

It doesn't seem to me that this should be all that difficult to implement.

So I've rethought things, and I've added the Flag module and have created a flag to allow users to flag items they're interested in. I've also created a view of the flagged items, but now I'm wondering if I need VBO at all. I'm sure I can call my existing rules and pass my own list of nodes from the view. VBO would be easier if there was a way to display both the view and the rules component form together. As it is, it looks like I'd need to have the user reselect everything from the flagged view and then do the normal VBO submit to trigger the rule.

Am I missing something? Is there a way to trigger VBO automatically using the entire View results?

Thanks.

As this issue is unassigned, I just wanted to know: is the port of this feature to 7.x currently being worked on?

No.

Just created a patch for this issue, following #5
This is a proof-of-concept (leaving issue status to active).
The idea (roughly):

1. Javascript posts an AJAX call with the selected entity IDs
2. $_SESSION stores the state of all selections, per view
3. Upon submitting, the selections are removed from the $_SESSION

Hi there, just stumbled upon this issue because I'd like to be able to do several searches through thousands of rows via exposed filters to find the few entities that need to be processed via VBO.

For example I need to process each time about 20 users out of 7K. The admin would do a last name search and click the checkbox, then do another last name search and click the checkbox.

I'd like to be able to keep the checked rows in the view while searching for the other users, so that it is only one processing action.

Is this possible... or would this be possible even in preliminary stages with your patch?

Hi,

Have been using it for a project and works the way you describe.
Just give it a go, happy to get some feedback.
Cheers

Great! Thank you! I'll try it out.

I was not able to get it working, unfortunately. After the patch it still does not save the previous selection. Also when I process one row, it gives an error and says I have not selected a row.

Hallo again,

Sorry to hear that. Just tested it quickly on a fresh Drupal 7.27 with VBO 7.x-3.2 and it worked.
All I did was apply the patch and clear the cache.
And it worked.
If you need help with debugging, I would need some more info about your setup.
You could also contact me directly (in order to keep this thread clean-er).

Bye!

array_filter() expects parameter 1 to be array, null given in _views_bulk_operations_get_selection()

#10 Works greate even with https://www.drupal.org/project/views_load_more pager.
Thx stefanos.petrakis!

Few issues appeared during using patch #10:

1. Ajax url should be changed to Drupal.settings.basePath + 'vbo_preserve_selection/toggle/' ...
2. We should also store in session information about selecting "All-Pages"
3. Also not sure about access permission form ajax callback, is "'access content'" a good solution?

Fixed 2 first issues mentioned above in attached patch.

In patch #19 I have made VBO JS behaviours to be called only once, and this caused behaviours not to be applied after ajax load. So i have fixed that in the patch below.

Added check to see whatever Drupal.settings.vbo is set.

Continue to struggle with JS. Now Preserve Select Behaviour and Ability to Click on row anywhere to select it applying only once per row.

Subscribing

Perhaps I'm not doing this right, but when I place the patch file views_bulk_operations-integrate-multi-page-selection-1207348-23.patch in the module root for views_bulk_operations and try to apply it via
patch < views_bulk_operations-integrate-multi-page-selection-1207348-23.patch
the patch can't find any of the files. I manually point it to the files it doesn't seem to be seeing, and it seems to run, but then it only applies some parts of the patch, and not others.

I guess I'll just use a View that has all items on one page.

$ patch < views_bulk_operations-integrate-multi-page-selection-1207348-23.patch
can't find file to patch at input line 5
Perhaps you should have used the -p or --strip option?
The text leading up to this was:
--------------------------
|diff --git a/js/views_bulk_operations.js b/js/views_bulk_operations.js
|index ca76df8..0960c9c 100644
|--- a/js/views_bulk_operations.js
|+++ b/js/views_bulk_operations.js
--------------------------
File to patch: js/views_bulk_operations.js
patching file js/views_bulk_operations.js
Hunk #4 FAILED at 86.
Hunk #5 succeeded at 162 (offset -2 lines).
1 out of 5 hunks FAILED -- saving rejects to file js/views_bulk_operations.js.rej
can't find file to patch at input line 133
Perhaps you should have used the -p or --strip option?
The text leading up to this was:
--------------------------
|diff --git a/views/views_bulk_operations_handler_field_operations.inc b/views/views_bulk_operations_handler_field_operations.inc
|index e478e7e..e32e188 100644
|--- a/views/views_bulk_operations_handler_field_operations.inc
|+++ b/views/views_bulk_operations_handler_field_operations.inc
--------------------------
File to patch: views/views_bulk_operations_handler_field_operations.inc
patching file views/views_bulk_operations_handler_field_operations.inc
Hunk #1 succeeded at 251 (offset -7 lines).
patching file views_bulk_operations.module
Hunk #1 succeeded at 451 (offset -6 lines).
Hunk #2 succeeded at 514 (offset -6 lines).
Hunk #3 succeeded at 620 (offset -15 lines).
Hunk #4 succeeded at 644 (offset -27 lines).
Hunk #5 succeeded at 697 (offset -27 lines).
Hunk #6 succeeded at 1289 (offset -27 lines).

I also get the issue reported above about missing files and one failed hunk.

I've manually applied #23 to dev and re-rolled. See attached. NOT TESTED AT ALL! It's literally #23.

On #23:

• Many Drupal coding standards violations
• Using SESSION means anonymouses can't use this functionality..? Can be a pretty big downside.
• view_machine_name isn't a valid form attribute, so prepend it with data- to make it a valid data attribute
• I don't think AJAX + SESSION is the way to go. Why not use localStorage or sessionStorage (the one that works everywhere) to remember selection locally? No need for SESSION or AJAX.

I'm trying it out now. Maybe fixes later.

This one applies to 3.2. Still literally #23.

I don't think it's possible the way VBO is created now. VBO selects row indexes, not entity ids, but multi page selection would have to remember entity id's, because of sorting and filtering etc. In normal VBO, a single entity id can occur many times in the view results. Multi page selection would remember only 1 id, meaning they're all selected. The 2 don't really work together, whatever method we choose.

I solved my specific problem with a separate module that extends the VBO form with a hidden input, remembers ids in localStorage and adds them to the VBO selection in the #validate phase. It works, but it makes assumptions the real VBO couldn't make. I'll clean it up and post it here. At least it's practical.

Sandbox: https://www.drupal.org/sandbox/rudiedirkx/2446867

Hi rudiedirkx,

I need to implement multi page selection.

I downloaded your sandbox module but unable to use as described in vbo_multipage_selection_form_views_form_alter, please suggest how to implement.

Thanks in advance
Atul

@atuldubey Please create an issue in the sandbox module, so we don't clutter this issue with another module's issues.

It was imposible to select entities through vbo when display is not table - fixed.

#27 is an awesome patch for me...please apply to the next release

This seems like a great addition, but I can't apply the patch in #34. @Niremizov or @jdpable, can you reroll the patch so that it can be applied? I'm getting "fatal: corrupt patch at line 34", and also there shouldn't be /sites/all/modules/contrib/views_bulk_operations... in the file paths. I'm looking forward to trying this out.

#27 worked for me but has one issue. I have 4000 records in a view and when I click select all rows, choose the operation and click execute, it lands up to a blank page.

Anyone who can help with this ?

Thank you

Have tried the dev patches against the dev version, and the non-dev patches against RR, and none of them seem to apply.

I can understand why the dev patch no longer applies, since the patch is older than the most recent dev release.

That is less clear with the RR, which dates from July 2015: since we use "nice dates" and the dev patch was added 10 months ago, that's July. Since I can't see the exact date for the patch (grrr, nice dates) it's unclear whether it pre-dates or post-dates the latest dev release.

Given that it won't apply, my assumption is that the patch pre-dates the latest dev release, and thus no longer applies.

@harora Have you tried selecting a smaller number of rows on a test view, perhaps just 20 or 50 and seeing that works? 4,000 rows could be a lot of data, and you may be running up against memory limits.

#27 work for me too. Drupal 7.50 and VBO 7.x-3.3....please apply to the next release!!!
Thank you so much @rudiedirkx

I wasn't able to apply #34 against the 7.x-3.3 branch. I kept getting "fatal: corrupt patch at line 34"

I manually applied the patch and re-rolled it. It's the same exact patch, it just should be capable of being applied now.

After all that, I uploaded the wrong patch file. #43 was my attempt to let phpstorm create the patch.

Works great. Thanks so much!

New patch against the 7.x-3.3 branch.
Contains small fix to the javascript, Checkbox obj was passed to "initPreserveSelectBehaviors" instead of the table row.

I downloaded the #46 patch and tested it locally and it worked great, as long as I only used the pager to navigate around my VBO-enabled view. Unfortunately, that view also has an exposed filter associated with a Taxonomy vocabulary. As soon as I reduced the results using the exposed filter, it went back to only giving me whatever checkboxes were in that particular reduced results set. I spent a good portion of my day poking around in Xdebug in PhpStorm and think I came up with a workable solution:

@@ -1115,10 +1138,14 @@ function views_bulk_operations_queue_item_process($queue_item_data, &$log = NULL
 function views_bulk_operations_direct_adjust(&$selection, $vbo) {
   // Adjust selection to select all rows across pages.
   $view = views_get_view($vbo->view->name);
-  $view->set_exposed_input($vbo->view->get_exposed_input());
   $view->set_arguments($vbo->view->args);
   $view->set_display($vbo->view->current_display);
+  // Remove pager pager to get full result set.
   $view->display_handler->set_option('pager', array('type' => 'none', 'options' => array()));
+  // Remove any exposed filters to get full result set.
+  foreach ($vbo->view->get_exposed_input() as $field_name => $value) {
+    unset($_GET[$field_name]);
+  }
   $view->build();
   // Unset every field except the VBO one (which holds the entity id).
   // That way the performance hit becomes much smaller, because there is no

This may end up breaking something, but I can't conceive of how, if you were persisting across the entire view, where you were already trying to get the full result set with $view->display_handler->set_option('pager', array('type' => 'none', 'options' => array()));, why you wouldn't also want to drop any exposed filters. Can anybody explain why $view->set_exposed_input($vbo->view->get_exposed_input()); would have been there in this function in the first place?

In any event, I re-rolled the patch with these changes and am submitting it here.

Sorry, noticed I put an unused variable in my patch and couldn't leave it. Please use patch #49. Changes as follows:

@@ -1115,10 +1138,14 @@ function views_bulk_operations_queue_item_process($queue_item_data, &$log = NULL
 function views_bulk_operations_direct_adjust(&$selection, $vbo) {
   // Adjust selection to select all rows across pages.
   $view = views_get_view($vbo->view->name);
-  $view->set_exposed_input($vbo->view->get_exposed_input());
   $view->set_arguments($vbo->view->args);
   $view->set_display($vbo->view->current_display);
+  // Remove pager pager to get full result set.
   $view->display_handler->set_option('pager', array('type' => 'none', 'options' => array()));
+  // Remove any exposed filters to get full result set.
+  foreach (array_keys($vbo->view->get_exposed_input()) as $field_name) {
+    unset($_GET[$field_name]);
+  }
   $view->build();
   // Unset every field except the VBO one (which holds the entity id).
   // That way the performance hit becomes much smaller, because there is no

After executing a bulk operation.

Notice: Undefined offset: 48 in views_bulk_operations_execute() (line 838 of views_bulk_operations/views_bulk_operations.module).

if ($operation->needsRows()) {
  $rows[$row_index]['views_row'] = $vbo->view->result[$row_index];
}

@duban: You're not giving us a lot to go on… Are you using a version of the patch? Is it applied to 7.x-3.3? I've got my patch applied to the VBO module and for me, line #838 is a comment and not likely to be throwing errors.

@deetergp Thank you for the patch. It works properly for "row checkbox clicking" selection. However, the patch didn't fix the issue in case of "Select all items on this page" using.
http://screencast.com/t/VTGs1bvV
http://screencast.com/t/ErhUnRgtvI6v
http://screencast.com/t/sUwaxENa1

When attempting to use VBO with the aforementioned patch #49, I am getting the following:

Notice: Undefined index: views_bulk_operations in _views_bulk_operations_get_selection() (line 712 of /var/www/html/sites/all/modules/contrib/views_bulk_operations/views_bulk_operations.module).
Warning: array_filter() expects parameter 1 to be array, null given in _views_bulk_operations_get_selection() (line 712 of /var/www/html/sites/all/modules/contrib/views_bulk_operations/views_bulk_operations.module).
Warning: array_keys() expects parameter 1 to be array, null given in _views_bulk_operations_get_selection() (line 712 of /var/www/html/sites/all/modules/contrib/views_bulk_operations/views_bulk_operations.module).
Warning: in_array() expects parameter 2 to be array, null given in _views_bulk_operations_get_selection() (line 712 of /var/www/html/sites/all/modules/contrib/views_bulk_operations/views_bulk_operations.module).
Notice: Undefined index: views_bulk_operations in _views_bulk_operations_get_selection() (line 712 of /var/www/html/sites/all/modules/contrib/views_bulk_operations/views_bulk_operations.module).
Warning: array_filter() expects parameter 1 to be array, null given in _views_bulk_operations_get_selection() (line 712 of /var/www/html/sites/all/modules/contrib/views_bulk_operations/views_bulk_operations.module).
Warning: array_keys() expects parameter 1 to be array, null given in _views_bulk_operations_get_selection() (line 712 of /var/www/html/sites/all/modules/contrib/views_bulk_operations/views_bulk_operations.module).
Warning: in_array() expects parameter 2 to be array, null given in _views_bulk_operations_get_selection() (line 712 of /var/www/html/sites/all/modules/contrib/views_bulk_operations/views_bulk_operations.module).

It seems to occur specifically when a user tries to apply a vbo action more than one thing. Doing with one item does not throw those errors.

3.4 ?

Here's a version compatible with 3.4.

Actually it is a complete rewrite of the previous patch. AAMOF I got in touch with Joel and asked him whether he would be available to commit #48 or something along those lines and he told me that at this stage of VBO's development he'd felt way more confident with such a feature living in a separate module.

Hence I started from the promising patch in #48 and tried to reduce the changes to the VBO's core codebase to the minimum. In the process I discovered some scalability issues with the previous approach and also I realized there were a few problems with exposed filters and the "Select all pages" feature.

For that reason, I got back to #5 and tried to follow the suggested approach more closely and address all the issues raised there as well as I could:

Some actions require the full views rows to be provided to them.

This builds on the previous approach and works by expanding the current selection with the items stored in the session data by altering the selection view. The main difference is that by altering the view query we perform the adjustment in batches and so we avoid the need to load all rows in bulk, which definitely resulted in OOM errors when dealing with hundred of thousands of nodes.

Select all on this page / all pages.

To address the unselect issue, the patch is storing an all_rows flag in session and tracking which items were unselected. In this case the selection view is adjusted by excluding those items, instead of narrowing the result set to the selected ones. This allows to deal with huge numbers of rows without having to worry about the amount of data stored in session.

All VBO code that gets the selection from form state needs to be modified.

This is also addressed by adjusting the selection view.

Each checkbox click will cause a drupal bootstrap, which takes a while [...]

This provides optional JS module integration, but also implements a small additional safeguard on top of that: the frontend code tracks how many pending requests we have and does not let the form be submitted until all of them have returned. If the user tries to submit the form meanwhile, the action is recorded and the form is automatically submitted when all requests are complete.

I hope this works well for people using the previous versions. One more caveat: now this functionality needs to be explicitly enabled in the bulk operation settings:

Reviewing my own code:

1. +++ b/modules/views_bulk_operations_multipage/views_bulk_operations_multipage.module
   @@ -0,0 +1,495 @@
   +      // Generate and store and identifier for this VBO form. We use a "data-"
   

   typo

2. +++ b/modules/views_bulk_operations_multipage/views_bulk_operations_multipage.module
   @@ -0,0 +1,495 @@
   +      $js_settings['selectAllRowsEnabled'] = ¶
   

   trailing whitespace

3. +++ b/modules/views_bulk_operations_multipage/views_bulk_operations_multipage.module
   @@ -0,0 +1,495 @@
   +      // Check whether the user selected all rows and notify the frontend about
   +      // that, so it can automatically display it.
   

   bogus comment

4. +++ b/modules/views_bulk_operations_multipage/views_bulk_operations_multipage.module
   @@ -0,0 +1,495 @@
   +  // selections on submit to avoid having lingering selected items, that would
   

   improve this comment

5. +++ b/modules/views_bulk_operations_multipage/views_bulk_operations_multipage.module
   @@ -0,0 +1,495 @@
   +        $exposed_input = array('__views_bulk_operations_multipage' => NULL);
   

   Missing comment here

6. +++ b/modules/views_bulk_operations_multipage/views_bulk_operations_multipage.module
   @@ -0,0 +1,495 @@
   +    return $value && $value !== 'All';
   

   this will exclude legal 0 values

Updated patch addressing my review and fixing a couple of issues I found while testing this.

Sorry, I forgot to mention that since the patch implements the functionality as a new module, that needs to be enabled for the options outlined in #55 to show up.

Did a bit of cleanup recently could you swap this out? input[id^="edit-views-bulk-operations"]
#2867407: 2 patterns of jQuery selector are used for the same elements in views_bulk_operations.js

Hope someone can give this a test soon. I'll be giving it a try soon but just trying to get some bugs sorted first.

Hi, I'm testing patch from #58 on production site.
I did indeed after patching enable the new submodule.

Thanks for the effort

This addresses #60

I have attempted to patch the multipage page into the current version of VBO, but I am getting:

vbo-multipage_selection-1207348-62.patch
can't find file to patch at input line 5
Perhaps you should have used the -p or --strip option?
The text leading up to this was:
--------------------------
|diff --git a/js/views_bulk_operations.js b/js/views_bulk_operations.js
|index 1288f28..c95a187 100644
|--- a/js/views_bulk_operations.js
|+++ b/js/views_bulk_operations.js

In the comments on #59 that it needs to be made into a new module. I changes the names in the VBO package, and attempted the patch but get the same error. Can some one please advise? Thank you for your help.

•••••••UPDATE - when patching this I did miss the -p, and found that if I used the -p1 it worked as expected.

@ashumateDrupal: Make sure you read the documentation (https://www.drupal.org/patch/apply), the patch from #62 applies cleanly, I just tested it.

+++ b/modules/views_bulk_operations_multipage/views_bulk_operations_multipage.info
+dependencies[] = views_bulk_operations

The multipage selection worked only after I enabled jquery_update. We could add this module as a dependency in order to get a fresher jQuery version available.

I hope I can review more of the code too, for the time it works great, thanks!

Thank you Steganos. I went back at it yesterday and did get it to work. Once I had it running and testing it, it did work as expected.

As per testing- when you are selecting multiple items across pages there is no UI element to show how many you selected as in the prior version. It did keep the selections as expected. The concern is when you have to create a new VBO select list, you may accidentally keep selections on alternate pages without your knowledge.

The past version in Drupal 6 had a row below the header that would keep count. This row exists in the D7 version only when you select all.

Thank you for your work. Trying to give good testing feedback to the group.

Patch #62 works. Indeed with jquery_update enabled.

Screenshot

With this patch there is no visual feedback for how many nodes you have selected. In the drupal 6 version you have this above element to for the feedback. When you select all of the nodes in the VBO you get the same element with the count. How can we connect the patch into that element? I am willing to contribute for this item.

On the Drupal 6 there is a header for the number of nodes that are selected. When you select 3 items it reads under the table header:

3 items selected. {Clear Selected}

In Drupal 7 version, you only get this feedback when you select all. What is the effort to make this patch work with that item? I am willing to contribute to help make this possible.

@stefanos.petrakis:

Good catch, I indeed have jquery_update enabled in my project, I didn't realize it was an hard dependency. I agree adding it as a dependency to the VBOM submodule would make sense.

@ashumateDrupal:

In Drupal 7 version, you only get this feedback when you select all. What is the effort to make this patch work with that item? I am willing to contribute to help make this possible.

Well, that part was taken care of differently in my custom theme so I didn't think about it. Feel free to update the patch at #62 to implement it.

I have rerolled the patch to the latest version.

@harings_rob: you mean you rerolled the patch to the latest dev version of views-bulk-operations?
I tried it against the latest dev (nov 10) and it applied cleanly & the patch seems to work perfectly!

This seems like a really important feature for VBO. Would love to see progress on getting this working and done, and ported to D8. Sadly, right now I don't have any D7 sites I'm working with that need it, all my attention these days is focused on D8 sites. So I don't have much to contribute to the current patch. Not sure where to put my energy on this issue.

At the very least, adding a link to an issue about a similar feature for the "bulk form" feature in D8 core's version of Views.

Curious if this feature can land in core, or if it'll need to be ported to D8 VBO. Advice + input welcome.

Thanks!
-Derek

The patch in #62 has been deployed to production for 8 months now and we didn't get complaints, so I'd say that once #64 is addressed, that could be a solid starting point. We could commit it and address potential bugs as separate issues, as usual.

I do not know if I'm wrong, but it does not seem to work:

• I have update to 7.x-3.5
• Apply the patch in #71(1207348.patch)
• Enable Jquery_Update and set it to 1.7 version
• Enable "Views_Bulk_Operation_Multipage" submodule
• Go to my views that contain list of nodes of my site(there are 3 pages).
• Select 3 items in first page, go on second page and select three items too.
• Select "Delete" operation in VBO, click delete, but only the elements of the second page are deleted.

Thank you so much for your help.

EDIT
I'm sorry, I forgot to enable "Multipage" and "Ignore Expose Filter" option in the view settings.

It works great with Drupal 7.59 and VBO 7.x-3.5

See the screenshots at #55 and #59.

This adds back a comment that was lost in the reroll provided in #71 (thanks!) and addresses #64. Since this patch has been successfully used by many people here (including myself), I think it would be ok to RTBC it.

Incorrect use of the "vbo-multipage-id" data attribute in the multipage module.

After a few tests, we noticed that when we quickly clicked the checkboxes, not all clicks performed an update selection ajax call. After some research i found this.

The main benefit of binding to the change event over the click event is that not all clicks on a checkbox will cause it to change state.

I also rewrite the code to use event delegates to bind the change event to all the checkboxes on the page.

Can confirm patch in #80 applies without difficulty to 7.x-3.x-dev (2019-05-16).

#80 no longer applied against the newest dev or stable. Here is a re-roll. Please review.

After re-rolling the patch, I did some testing. I noticed a few issues with the current functionality.

1. If you check a box on the first page, the vbo action is made available and can be clicked, however if you go to the next page the action is made unavailable again until you either check another box on this page, or will be re-activated if you go back to the previous page. Since a row has already been selected the action should be enabled regardless of the page you are on.
2. If you make a selection and use an action, the checkboxes are still set afterwards on the form and can only be cleared by manually removing the checkbox on every page. They should be cleared the moment and action is performed. In this case I am using "Pass IDs as Arguments to a page"
3. In general, I believe there should be a way to cancel the current selection, since currently you would have to navigate to each page