As a module maintainer, I experienced lots of trouble when implementing a Drupal\views\Plugin\views\filter\ManyToOne filter on a computed field. It modifies the results AFTER the Query is executed, either in a hook_views_post_execute hook or a hook_field_views_pre_render.
However, data was never consistent when using the results on a paged view.
It seems the problem was not in my lack of knowledge, but in the Sqland Pager classes i core, and many issues around that already exist.
Hence, let us prune all 'pager'/'pagination' related issue reports in core, and find if any of those has the best solution already. See the 'Remaining tasks' section.
- create many nodes
- create a table view with fields, pager, and filter/sort
- execute the view, go to next page
-- sometimes, the view stays on the first page, no matter how ofter you clikc on a page number, [next/last] button
-- sometimes, the first of next view does not contain the expected number of items
-- sometimes, an item is repeated as last item on page and first item on page n+1, or an item is not showing,
When adding multiple pagers on a view:
- pagination on 1 pager leads to pagination on all pagers
When adding view/exposed filters in a block, problems arise.
- Determine if problems exist with ajax enabled views only
- Introduce Ajax-enablement not only on display-level, but also on filter/sort level
- Fix problem in Sql, Pager classes. Pagination ('range') is already done in the SQL statement, not afterwards (possible to avoid memory problems when having huge amount of data.)
- To easily find all related issues, first search on 'pager', 'pagination', 'navigation' keywords in core issue queue, clarify the title if needed , starting the issue title with 'Pager'. This way, the issues can be sorted alphabetically.
- For 'Feature requests' use the 'Add pager ...' title, and categorize the issue as such, moving to views_ui.module if needed.
- Move all general error reports to the 'views.module', even though it seems 'base system' seems technically better. but 'base system' is a big hairy technical thing, whil 'views'/'views_ui' is more user friendly. And all core views/lists queries are supposed to be converted to Views lists, anyway. Most issues are already in 'views.module' or 'views_ui.module' already, since many users experience problems when introducing (exposed) filters using the Views UI module.
- When an error report exists on a specific view/list/report in a core module, leave it there. It will be magically be solved with the general issue.
- Repeat for the 'filter' keyword, extending it to 'exposed filter'. Most problems also exist for hidden/programmatic filters.
- Categorize the bug reports (see Steps to reproduce)
- Find the best solution for each problem
- After solving the problems, search and re-visit the module-specific issues, evaluating them again.
Not foreseen, except for the 'feature requests', which are out of scope for this plan.
The following keyword are encountered (also added to 'Issue tags')
'Pager'
'Pagination', 'paging', 'navigation'
'filter(s), '(views) exposed filter(s)', exposed form', 'selection box'
'ajax', 'ajax request'
Active
11.1 🔥
views.module
@johnv, thanks for working on the pager issues!
This should be on 11.x (our main development branch) .
Updated the summary test script with:
"-- for better analysis, you may add 'Global: Result summary' to the header section.
"-- for better analysis, you may add 'Global: View result counter' as a field.
Added 'Exposed filter' vs. 'Exposed form' explanation.