Views: expose items per page as config option

This sounds like an interesting improvement. I wonder, while being on it, if there are other properties too, that we may want to change at the same time.

It depends a bit on how flexible you want it to be. If you search for "function set" on this page: https://api.drupal.org/api/drupal/core%21modules%21views%21src%21ViewExe..., you'll get a list of all the items you can alter/set before executing the View.

For now, I'm just limiting it to the arguments (already there) and the items per page.

However... Testing the change now... When I set the items per page on the View-object, it works when it's rendered initially. But the second page just loads the amount of items that is configured in the View itself...

Left a couple of comments in the MR.

When I set the items per page on the View-object, it works when it's rendered initially. But the second page just loads the amount of items that is configured in the View itself.

That's strange. Maybe we could check in the views block plugin and check how they've done it there.

I've implemented your remarks, thank you for the feedback.

Regarding the items being returned for the second "page", I believe it's an issue coming from Views Infinite Scroll. I'll link the ticket. But this shouldn't stop this particular feature request.

For reference, this is how the Views Block plugin is overriding the items_per_page config item: https://git.drupalcode.org/project/drupal/-/blob/11.x/core/modules/views.... The ECA Action is doing the same thing.

The MR looks great. We probably need a update hook so that existing models will be updated for the new config property.

Having said that, the default value of the items_per_page should probably be an empty string, not NULL.

Following your comment #7, does that mean that it works correctly if Views Infinite Scroll is disabled?

Summary of the latest changes:
- [eca_render]: Refactored the way the configuration key is translated to a value (either a token or a regular string)
- [eca_render]: Added update-hook to update existing and their config
- [eca_views]: Added eca_views_set_pagination_values-action to keep the pagination setting across different http-requests. The "issue" mentioned above, with views_infinite_scroll, was not related but did send me in the right direction. Overwriting the pagination via the eca_render_views-action works, but only for the initial rendering. When using ajax pagination, Views falls back to the setting of the View itself.
So I had to tackle this from another angle: hooking into the pre-execute or pre-build event of that View. So I've created a "copy" of the eca_views_set_filter_value-action, and changed it so it sets the pagination- and offset-config.

For my particular use-case (see screenshot) this approach now works: in one model, you render the View and alter it via the pre-build event. There's only one bug, not sure if it is one, and that's data of the event that is available. See separate issue.

Left a few comments in the MR.

While I like the new plugin ViewsSetPagination, I think this is a nice separate new feature, but it should be the "solution" for the issue with subsequent pager requests. The reason being it that this would only work if one has a complex ECA model always around which fixes the issue with the pager. That's not sustainable.

We need to look into the rendered view as prepared by the render views plugin and see why this isn't working across multiple ajax pager requests. We need to get this to work without any extra events to hook into the logic. If core renders that view with a pager, it lets us page through without any issue, the same needs to be achievable by "custom" code, i.e. from within ECA.