More link is missing in pager

Yup, this is a regression, easily reproduced manually.

Here is a test and a proposed fix for this.

The Needs Review Queue Bot → tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

This does not mean that the patch needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

I ran checks and everything, apparently still got it wrong.

This should be better....

The last submitted patch, 5: 3381979-5-TEST-ONLY.patch, failed testing. View results →

The last submitted patch, 5: 3381979-5.patch, failed testing. View results →

Lets see if this gets all the fails fixed

Confirmed the issue following the steps in the IS.

After applying patch #8 the more link does appear in the preview even without "Always display the more link" setting. See screenshot

Saving credits: @francismak for a good issue report, @Lendude for the fix, and @smustgrave for manually testing.

1. +++ b/core/modules/views/src/Plugin/views/pager/Some.php
   @@ -18,6 +18,13 @@
   +   * The original number of items of the query before the limit is applied.
   

   "items of the query" doesn't make sense to me. How about:

   The total number of items in the result set before the pager limit is applied.

   Is that an accurate description of what this quantity is? Because "limit" without any modifier means something specific in SQL, and you can't get "the number of items before the limit" from an SQL query. You can, however, get the whole result set from a view and then chop it up into pages based on the total number of results versus the items configured to display per page.

2. +++ b/core/modules/views/src/Plugin/views/pager/Some.php
   @@ -18,6 +18,13 @@
   +  protected int $numberOfItemsBeforeLimit;
   
   @@ -73,7 +80,18 @@ public function query() {
   +    $this->numberOfItemsBeforeLimit = $this->total_items;
   

   Along the lines of the above, I'd suggest a different name for the member property. Maybe $totalItemsBeforePagerLimit?

3. +++ b/core/modules/views/src/Plugin/views/pager/Some.php
   @@ -73,7 +80,18 @@ public function query() {
   +    // Use the original number of items if it has been set to determine if there
   +    // are more records.
   

   I don't understand this. Maybe:

   Determine if there are more records by comparing the total number of items to the items per page.

4. +++ b/core/modules/views/src/Plugin/views/pager/Some.php
   @@ -73,7 +80,18 @@ public function query() {
   +    return $this->getItemsPerPage()
   +      && ($this->numberOfItemsBeforeLimit ?? $this->total_items) > $this->getItemsPerPage();
   

   This is awfully complicated logic for a return statement. I'd suggest breaking this out into if/else statements at least. Quoting from the PHP coding standards → , we shouldn't "attempt to win the Most Compact Condition In Least Lines Of Code Award™".

5. +++ b/core/modules/views/tests/src/Kernel/Plugin/SomePagerTest.php
   @@ -0,0 +1,36 @@
   + * Tests the "Some" page.
   

   I'm pretty sure this should be pager, rather than page.

6. +++ b/core/modules/views/tests/src/Kernel/Plugin/SomePagerTest.php
   @@ -0,0 +1,36 @@
   +   * Tests "Some" pager hasMoreRecords().
   

   This is a bit... gnomic. How about:

   Tests that the "more" link works correctly with the"Some" pager.

   And we can add @see to Insert\Namespace\Here\Some::hasMoreRecords().

Thanks @xjm for the feedback and @Lendude for making the progress on this issue is good to have in core.

Latest feedback looks valuable to me I have updated those with patch while using the above patch on my project.

Please Review and let me know if i can improve further.

Updated the patch to fix PHPCS Errors.

Sorry for the multiple alert this should FIX the CS now.

Thanks all

Seems @xjm points have been addressed.

One additional thing i am observing is that after the changes done in https://www.drupal.org/project/drupal/issues/3265798 🐛 [view:total-rows] problem in Display a 'Specified number of items' pager Fixed , if we try to access `$view->total_rows` in custom code, then it returns the count after the pager is applied and not the actual number of results.

Scenario

in custom code implement:
`hook_views_pre_build` and add something like:

`$view->getPager()->setItemsPerPage(3);`

Then implement: `hook_views_pre_render` and then do something like:
```
dump($view->total_rows);
```
Assuming initial results were 6, but after calling setItemsPerPage, the total_rows count come out as 3.

Not sure if i am doing something incorrect here. but if i comment the code from https://www.drupal.org/project/drupal/issues/3265798 🐛 [view:total-rows] problem in Display a 'Specified number of items' pager Fixed then the total_rows count reflects correctly.

@smustgrave, @Lendude, @xjm

Is this still needs some work as its throwing WSOD on the unpublished entities with the indexed views block (Using search_api) with the "some" pager.

Backtrace report:

Steps to reproduce :

1. Create a indexed view block (using search_api).
2. Place the block on any unpublished node.
3. Visit the unpublished node page it will throw WSOD error.

Is the above relevant to fix as a core bug or is it separate thing ?

The last submitted patch, 13: 3381979-13.patch, failed testing. View results →

I'm actually running into this bug not just with the "preview" but with my view block display as shown on my site -- but y'all are only running into this bug with the view preview? (I'm trying to figure out if I've run into the same bug or something different.)

(Or maybe it's not just me, per @tjmoyer over here: https://www.drupal.org/project/drupal/issues/3265798#comment-15159116 🐛 [view:total-rows] problem in Display a 'Specified number of items' pager Fixed )

About me:

• Drupal 10.1
• View block display with "display a specified number of items" (I reduced it to "1" for testing)
• More link: Yes ("always show" unchecked -- but when I check it, it does show)
• Link display: Custom link (b/c we've got custom argument stuff going on)

When I view a page where the view block display is placed, the "more" link doesn't show unless I enable "always show." Furthermore, we happen to still be working on the Drupal 10 upgrade for this particular site, so I can see that the "more" link behavior works fine on the Drupal 9 version of the site, and is broken on the Drupal 10 version of the site.

FWIW, I tried the patch on #13 applies cleanly and fixes the bug for me (on core 10.1) 🎉

(Sorry for the comment noise due to me not thinking to try it before posting my previous comment........)

Patch #13 solved the problem initially but I'm seeing the problem re-occurring after a while and requiring a cache clear to bring back the 'more' link.

Using patch #13 with D 10.1.8 fixed the issue.

Switching to RTBC - failing tests for D 11.x in #13 doesn't seem to be relevant.

The caching issue mentioned in #20 didn't show up for me: tested by unpublishing/publishing contents and the more link was hidden/shown as it should be.

The Needs Review Queue Bot → tested this issue.

While you are making the above changes, we recommend that you convert this patch to a merge request → . Merge requests are preferred over patches. Be sure to hide the old patch files as well. (Converting an issue to a merge request without other contributions to the issue will not receive credit.)

The patch only works when caching on the view is disabled. When selecting "Advanced -> Caching" and set it to either tag based or time, the more link only shows up the first time it displays, but stops working the next time the page is loaded. Only the first page load after a cache clear the "postExecute" method is triggered.

I just experienced what @jjpost said at #23.

Here's a great elaboration 🐛 More link disappears when time-based views cache is enabled Needs work for the issue, and why we have issue with caching.

@akshay_d
I couldn't reproduce the issue in #16...
I followed your steps and besides I used both block and embed display types...
Also tested it with/without having indexed items...
For me: $this->total_items is "0" in all cases!

Re-upload #13 patch as my composer expects patch to be relative to the core install.

I have a peculiar issue with one view that is filtered by a certain content type. For some reason it appears to only show half of the required items! If I switch the content type then it appears fine.

Also, with this same view, the more link has disappeared from the block version of this view. Applying this patch seems to fix the more link issue for me.

Many thanks

Hi,

Patch from comment 28 fixed the issue for me on Core 10.3.1. But it does not apply with Composer.

So, I have created a MR against 11.x to push the issue forward. And here is a patch from the MR for Composer usage. (it applies on 10.3.1 too).

For support for applying patches with multiple patch levels you may need to patch composer patches.

https://github.com/cweagans/composer-patches/issues/579

I feel the solution pursued so far may possibly be the wrong approach.

It was the solution to 🐛 [view:total-rows] problem in Display a 'Specified number of items' pager Fixed that triggered this regression. It was fixing the value returned for the token [view:total-rows] that resulted in PagerPluginBase::$total_items always being set to the number of limited query results for the "Some" pager.

But what if this assumption was incorrect, what if [view:total-rows] should not always return number of limited query results. For example, if I am using the "Some" pager, limited to 5 results when there are 20 and I have a "More link" enabled, I think it would be valid for me to want to add the text "Displaying 5 or 20 results". In which case I would want [view:total-rows] to return 20.

If the code is changed to only override PagerPluginBase::$total_items in the postExecute() if a "More link" is not enabled, then this issue would be fixed.

I have opened another issue ( 🌱 "Some" Pager Plugin and [view:total-rows] Regression Issue Active ) to discuss this proposal as it may require other actions unrelated to this issue.

hi
#32 applied correctly on D10.3.6.
But on page refresh the link ALWAYS disappear and only come back after drush cr