Fix broken Pager when Items Per Page is exposed

I have the same issue with version 4.0.0, and the same workaround.

I have a fix for this issue but it needs a bit of finessing and testing.
The ViewsBulkOperationsActionProcessor::populateQueue() method executes the view which overwrites the view pager.
A simple fix I've made is to change the pager id before executing the view.
Question is what id to use; for simplicity I just add 1000 to the real pager id, but maybe this needs to be configurable.
Patch attached.

Thanks, @hughworm for the patch, the patch working well.
The patch fix issue when selecting more than items then clicking on the pager, the pager was broken, but after applying the patch the pager worked well.

Patch #4 is working
Tested with views_bulk_operations-4.0.0
Thank you, Hugh for patching this issue

After one more round of testing with costumed "Exposed items per page options"

    // Use a different pager ID so we don't break the real pager.
    $pager = $this->view->getPager();
    $pager->options['id'] += $this->view->getItemsPerPage();

Is better.
or the pass of the current selected "Exposed items per page options" filter

Having a custom change for the "Exposed items per page options" in the following view pages:

• admin/content
• admin/content/media
• admin/content/media-grid
• admin/people

After the fix:

Content Table - Page 1 - Selected 3 - (Items per page selected 5 )

Content Table - Page 2 - with Selected 3 from page 1- (Items per page selected 5 )

Media Grid - Page 1 - Selected 2 - (Items per page selected 24 )

Media Grid - Page 2 - with Selected 2 from page 1- (Items per page selected 24 )

Can we try setting the pager ID to a negative value (-10 for example)? If that'll not work, I'd go for a big positive integer like 1000 so there are no chances this'll interfere with anything.

@Rajab Natshah, your MR reverts many other changes already introduced, please start over if you're willing to continue this work.

Thank you, Marcin for having time to follow up on this issue.
Created a new branch 3222477-2--from-4.0.x in the same issue fork.
A new MR was created with the needed changes only :)

Thank you, #15 needs to be addressed.

Thanks, Marcin for commenting and the release :)

Please, allow me to have this follow up comment.

    $pager = $this->view->getPager();
    $pager->options['id'] = 1000;

But when having a custom change for the "Exposed items per page options" number of issues will show up.

1000 May brack when having a display of pager around 10 pages with a custom exposed selection of 50, 100 in the page

As the need to do any bulk operation is paired with the selection of a big number of items. Content admins will need to switch to show 50 or 100 in custom views with VBO.

Having the option id with the items per page will make sure
So that the patch in #8 was uploaded.

    $pager = $this->view->getPager();
    $pager->options['id'] += $this->view->getItemsPerPage();

Tested the get items per page in number of projects, without any feedback on wrong behaviour.

• Issue #3245889: Fix broken Pager when items been selected by the views bulk operation
• Issue #3247625: Fix admin Content and User Admin People view old config after change of schema config by the Views Bulk Operation module
• Issue #3249335: Fix Media Table and Media Grid view old config after change of schema config by the Views Bulk Operation module

The $pager->options['id'] = 1000; will use the same id 1000 in all options ides
It will bring wrong behaviours in customed views

I hope that this point is clearer now.
I thought it was clear in #7, and #8

@Rajab Natshah, I don't understand you unfortunately.
Can you please add a testing scenario that'll fail now on 4.1.1?

Probably making it $pager->options['id'] = 1000; wasn't good, TBH I missed the += and tests passed. But I still need to know what fails now.

@Rajab, please check the above solution. Made the ID bigger by 1000 and added a check if a view does have a pager.

I decided to merge this as it was already tested. If something will go wrong, we'll just probably have one more hotfix release, no matter how bad it'll look.
Thanks for being watchful Rajab!

Thanks, Marcin for following up on the issue and the quick fix release.

Your logic is better with the check for the pager options array.

    // Use a different pager ID so we don't break the real pager.
    // @todo Check if we can use something else to set this value.
    $pager = $this->view->getPager();
    if (array_key_exists('id', $pager->options)) {
      $pager->options['id'] += (1000 + $this->view->getItemsPerPage());
    }

Working on
#3271292: Update Views Bulk Operations (VBO) from 4.1.0 to ~4.1 and remove committed patches
Following with a full round of testing for sure
I will look into @todo Check if we can use something else to set this value.