Different item count for 1st and other pages

+++ b/src/Plugin/views/pager/InfiniteScroll.php
@@ -90,7 +93,53 @@ class InfiniteScroll extends SqlBase {
+        '#title' => t('Initial items'),
+        '#description' => t('The number of items to display initially. Enter 0 for use same as items per page (show more click).'),
...
+      $form_state->setError($element, t('%name must be a positive integer.', array('%name' => $element['#title'])));

this should be $this->t() because inside pluigin

Fix tests

This seems pretty out of the 80% use case, for a module that already has a hard time keeping up with bare minimum compatibility with the rest of the views features and touch points. Maybe some test cases could be added to prove this works, but I can't say I really think this should be part of the base module.

+++ b/src/Plugin/views/pager/InfiniteScroll.php
@@ -90,7 +92,52 @@ class InfiniteScroll extends SqlBase {
+        '#type' => 'textfield',
...
+  public static function validateIntegerPositive(array &$element, FormStateInterface $form_state, array &$complete_form) {
+    $value = $element['#value'];
+    if ($value !== '' && (!is_numeric($value) || intval($value) != $value || $value < 0)) {
+      $form_state->setError($element, t('%name must be a positive integer.', array('%name' => $element['#title'])));
+    }
+  }

We can use a number type here with a #min/#max?

Fix offset option.

This patch had an issue concerning pager, the default pager assumes all pages have the same number of elements. I added a getPagerTotal override method to solve this issue with the pager.

I disagree. There is already a large volume of bugs and support requests that come up for the basic functionality. If the decision was made to allow every edge case into the module, it would be less maintainable than it already is. As of now, the functionality adds complexity, isn't tested and isn't appropriate for the 80%. Closing.

Let's set proper status - this issue no-go to becommited without tests

PS: I'm using the patch a lot and it works fine

Closing this is really inappropriate.

It's actually a perfectly reasonable product management decision. Maintainer aren't obliged to commit feature requests.

After testing the patch, I've seen it works well. IMHO, it's a valid feature request for several use cases, keeping in mind that patch is almost ready.

I've tested it with several views, displaying ViewModes or Fields, and at least at my side, no errors found, with several Drupal versions.

Small fix for edge cases in total items counting.

Fix patch after update dev version.

As it was stated before, this feature might be a game changer. Most of the people will module as it is, but there are times you need to show couple of items, then load much more.
I think it should also be possible to set initial number of values to zero. This could be used as "spoiler" feature to display attachments, etc.

We are seeing a client request for this specific case, so consider this an upvote for including it in the main version of the module if you do have the time.

Thanks for your maintenance efforts! We appreciate it.

+1 : Using patch from #9, works perfectly on latest Drupal version.
This use case seems to be pretty useful for some people !
Thank you for your work on the cool module.

Tests, updates for existing instances

Minor codestyle fixes

Thank you for this patch, working fine and very useful.

However I noticed a small bug, if the views doesn't have enough items to load the first page, and the "initial items" variable is set to 0 to get the same number as the following pages then the load more button is shown even if there's no more pages.
Setting "initial items" to the same value as "Items to display" will fix this.

Also "Initial items" could be a number field instead of a text field.

Nice work.

I am going to commit it when this will be solved:

However I noticed a small bug, if the views doesn't have enough items to load the first page, and the "initial items" variable is set to 0 to get the same number as the following pages then the load more button is shown even if there's no more pages.
Setting "initial items" to the same value as "Items to display" will fix this.

Also "Initial items" could be a number field instead of a text field.

@bobík it is resolved now

Last patch is broken, also please attach interdiff of you changes from 36 to help reviewers follow your changes

Rerolled, need to provide tests to check how it works with #2972129: Add option to initially load all pages up to the requested page when loading pages beyond the first

I think this is final version

I am on 8.8.x and patch #37 applied successfully!

Since the last update different_item_count-2852080-49.patch doesn't work anymore. Here a new patch.

Is there a patch for D9.3 as well?
The patch from #52 can be applied and I see the new input field in the pager options but on AJAX Views this doesn't result in the desired behavior that I want to define a different amount of intially shown items vs the amount of items loaded after clicking the "Load more" button.

Hi I am looking patch for D9 is there any patch for this same issue version 2.0.1

Created patch for D9

Patch at #55 did not apply successfully for me through composer patches, so I fixed it and also fixed some formatting. Patch is for 2.0.2, due to Drupal 10 upgrades.

Unfortunately the latest patch (comment #56) isn't working as desired.

I have a view with 9 results.

Initially set to display 7 and load 6 thereafter.

The initial items of 7 display, but because my view results don't have enough results to reach an additional 6 (9 results, 7 of initial page load, therefore 2 more to load in) the pager doesn't load.

I've tested by changing initially show 4 items and then 3 thereafter on load. The pager displays, loads in my 3, then no more pager, cause I have 2 items left, not 3.

This is all tested via AJAX.

Added a patch that solves my comment in 58.

Uploaded the files the wrong way around perviously - sorry!

Thanks @ChristianSanders could you prepare that as MR perhaps, please?

@Anybody done - https://git.drupalcode.org/project/views_infinite_scroll/-/merge_request... (hope i've done this correctly - this is my first time contributing a patch via an MR!) Thanks :)

Thanks @ChristianSanders. Looking quite good, but there is a conflict left. Perhaps it was based on an older branch? Could you resolve that one?

Here you can see the resulting diff from the MR: https://git.drupalcode.org/project/views_infinite_scroll/-/merge_request...
In the end it should be equal to your one?

I was facing the same issue but checked with views_infinite_scroll-2852080-2852080-different-item-count this branch it is working fine for me thanks @christiansanders

Thanks. So the last step here seems to be to add test coverage?

I checked the patch from #61, and there is another bug. My steps:
1. I set 6 items to show on load
2. I set 3 items to add on each "load more" click (I use the button)
Result: when I have 3 items in total, no "load more" button is shown (correct). But after creating another node, I have this behavior: it shows 4 nodes and (here's the error itself) the "load more" button. After clicking on this button, it disappears (without adding any item because everything is already displayed).

This is an updated patch file to fix the bug reported at #68
The number of pages needs to be recalculated
When creating a pager we set total items = current_total_items + (items_per_page - initial_items).

I updated the merge request with the changes from #69 (and the latest changes from the 2.0.x branch).

In my local testing the new options work well, thank you all.

Thanks, still needs tests (FunctionalJavascript) as last step, right? Who's our hero? 🦸🦸‍♀️

I added a test for the different initial loading and after first page loading other amount.

Alternative Implementation

Hi @all,

This approach provides another way to implement the feature without disturbing the current functionality.
Please review, test, and confirm if this works as expected.

I’ve also added test coverage to validate the behavior.

Issue Summary

This proposal adds a new “Page Control” feature to the Views Infinite Scroll pager plugin, allowing site builders to specify different item counts for:

• The first page
• All subsequent pages

This is useful in UX scenarios where the first page of a listing (e.g., landing pages or featured sections) should show fewer or more items than the rest.

Proposed resolution

• ntroduce a checkbox Enable Page Control in the pager settings.
• When enabled:
• Hide the existing Items per page field.
• Show two new number fields:
• Items for the first page
• Items for the other pages
• Modify internal pagination logic to:
• Set per-page limits conditionally based on current page.
• Adjust offset and total count logic accordingly.
• Update getRemainingItems() and getNumberItemsLeft() methods to reflect accurate counts.
• include #states logic in the options form for dynamic field visibility.

User interface changes

A new checkbox and two conditional number fields will be shown in the Views UI under the pager settings.

Example Use Case

For example, I want to display only 4 items on the homepage (page 0), but load 2 items on all other pages. This feature enables that flexibility without needing to override views programmatically.

Video Demonstration

Here’s a working demo of the feature implemented on my site:

This feature has been implemented in the branch:
2852080-Add-Page-Control

A patch has also been attached here for testing.

✅ Please review and test the patch and merge request.
💬 Feedback and suggestions are most welcome!

Use Add-Page-Control-2852080-#78.patch this patch to avoid warning errors.

Successfully tested patch #78 in our project. Thanks !

Rebased the MR and added a few changes/fixes on top:

• Coding standards fixes and return types.
• Removed the unsupported default: key from the config schema.
• Replaced the positive-integer validator with a number element.
• Fixed the button tokens: they assumed every page holds items_per_page items, so with initial=2, items_per_page=4 and 11 results the button read "Load 4 of 7 remaining" on the first page (9 remain) and still "Load 4" when 1 remained.
• query() no longer overrides the parent unconditionally: views not using the feature keep core behavior (the total_pages clamp was lost, and items_per_page=0 showed only initial items with no way to load the rest).
• Test coverage for all of the above.