After update to Drupal 8.4 VIC replace results instead of appending

I confirm the issue, but I'm not sure about why it happens.

I've been able to restrict the bug search to two repeatable use cases:

1. OK: A page with a simple single view
2. KO: A page with a view (paginated or not, no difference...) and a single attached view in it (a views block that inherit contextual filters from main view)

So, I think that:

1. "simple" page structure (use case 1) works.
2. "complex" page structure (view block in view block) doesn't.

I suppose that it should be only a jquery div selection issue, that fails in the case of a child view in the main view.

I also confirm that before 8.4 it was working, also on second use case.

Hope it helps... I'll continue to test the issue...

My pager doesn't work at all - a simple view, with the pager set to load on click.

I got this error in the console:

Uncaught TypeError: Cannot read property 'replace' of undefined in infinite-scroll.js?v=8.4.0:29

That line is using jQuery .selector, which was removed in jQuery 3.x. Drupal 8.4 updated to jQuery 3.2.

This line is fixed in the dev version.

I finally found that js is loaded, but not invoked at all (that's why it paginate as a standard ajax view ...)!

The issue is in function onResponse, in src/EventSubscriber/AjaxResponseSubscriber.php, near line 52:

  public function onResponse(FilterResponseEvent $event) {
[...]
    if ($view->getPager()->getPluginId() !== 'infinite_scroll' || $view->getCurrentPage() === 0) {
      return;
    }
    $commands = &$response->getCommands();
    $this->alterPaginationCommands($commands);
[...]

At the moment I still don't know why, but $view->getPager()->getPluginId() is null, not 'infinite_scroll', so the function returns immediately and the following alterPaginationCommands is not executed (= infinite ajax is not called...)

As a test, I tried to "force" the execution by commenting the "if" sentence and infinite scroll started working again (don't do it at home, it will affect every paginator!)

BUT, i still have to understand why getPluginID() is null... and I also suspect that getPager() is not ok...

@megan_m I think you are using an old version of the module.
That line was fixed in 1.4 ( commit http://cgit.drupalcode.org/views_infinite_scroll/commit/?id=e1dd539bc2dd... , fixed in #2902796: Stopped working with Views 3.17 )

Back to my use case: one view without pager containing an attached view block with pager.

I discovered why it fails: $view->getPager()->getPluginId() is null and not 'infinite_scroll' because it is always referring to MAIN view. It's easy to see it in the Ajax request that gets generated when you click on ANY pager, not only infinitescroll type (url: /views/ajax?_wrapper_format=drupal_ajax ... I removed not useful lines...)

view_display_id: page_1
pager_element:0
page:0,1

So, the code in src/EventSubscriber/AjaxResponseSubscriber.php line 52, will NEVER be able to run, because $view->getPager()->getPluginId() contains the pager plugin id of the MAIN view (in my usecase, "none"), not the embedded one...

It's necessary to replace the way in which we are checking if pager is infinite_scroll, but I'm not sure it is something that can be done INSIDE VIC.
I found this, where the issue is really the same, for generic pagers... #1082334-12: Separate pagers for default display and attachment display

Thanks for opening this issue. I had the same problem but I eventually resolved it by turning on the use of AJAX.

Setting "Use AJAX" in view helped me too.

I attached a new the patch 26 to https://www.drupal.org/project/drupal/issues/2833734, to allow separate pagers for attachments.

So VIS should implement similar filter function which ensures only the rows and pager which are direct target of the AJAX call will be updated.

Is this bug also in 1.5 or it was introduced later?

If you will not reply in a ~week I will release 1.6 from the current dev.

Patch #10 no longer applies clean for me.

Any idea for D7, I want to make the rows append instead of replacing. Is there any patch available for D7

Rerolled patch against latest code.

Does #14 still work?

Is this a duplicate of #2858890: Drupal.views.ajaxView is not initializing pagers in nested views?

Thanks so much for working on this issue everyone. I was able to create a patch against the latest dev version. Hopefully this works for everyone.

Hey Everyone,

Here is another patch rerolled that includes a solve for another issue "Headers in table format repeat on load more instead of adding rows" at https://www.drupal.org/node/2899705

Applying this patch now solves for both issues in case anyone is needing it and is having trouble applying patches from both issues. You should now be able to apply this patch and solve both issues.

Ok here's my final result after testing #19 with a view in layout_builder.
It works combined with #2858890: Drupal.views.ajaxView is not initializing pagers in nested views, Patch #43. Without that additional core patch it does NOT work. Also the core patch alone doesn't fix the problem for me.

RTBC+1 for #19 so, please help to move the core patch to a commit.

This is major because functionality is completely broken on the given conditions and there's no workaround for a regular user.

@Anybody dont you think we need to wait till #2858890: Drupal.views.ajaxView is not initializing pagers in nested views will be committed into drupal core?

@Neslee Canil Pinto, yes I agree, but can't see any progress there.

Let's postpone it on #2858890: Drupal.views.ajaxView is not initializing pagers in nested views as of #20-#22.
Anyway it's still major from my perspective as written above, which is a strange situation.

I guess the issues are somehow related, but #2858890 can not solve the issue. I updated this patch for my latest changes in that ticket.

Secondly it appears to be important to have pager ID to "0" for all views blocks, if they are on the same page. In case you have set a value > 0, the RequestSubscriber of VIS will fail, because the page query parameter looks like ?page=,1,,1 so $event->getRequest()->query->get('page') == 0 is TRUE.

I would also like to leave changes made in #2899705 out of this as long as it is not in master. If you need both changes in your code, @Bao Truong, I suggest a custom local patch.

I'm getting this issue after updating to 1.8.0 but it doesn't occcur in 1.7.0

The view is a very simple block, but it does have an overridden pager ID as described in #24.

Changing the pager ID to 0 fixes it in 1.8.0, but it would be good to figure out why this regressed between the versions.

I have had to downgrade to 1.7.0 to fix the problem. Changing the pager ID to 0 hasn't fixed the bug for me.

We have the same issue with 1.8 version. The issue does not exist with 1.7 version.

I set the issue status to Needs work.

As 2.0.x is the new branch where development happens, I'll switch over.

Having this issue with the pagination of a nested view (embed display).
updated patch for 2.0.x.

I had to apply also the patch from core issue #2858890 and #2833734

There's an error with the last patch (for 2.0.x) that caused it not to load more results (there is no $pager_links variable). Here's a patch new patch for 2.0.x that does not change that line and seems to work, at least in our case.

Switching to an issue fork workflow.

Since patch "filter-nested-views-2918352-30.patch" doesn't work any more in conjunction with the latest patch of #2858890: Drupal.views.ajaxView is not initializing pagers in nested views, I manually applied the last RTBC'd patch (filter-nested-views-2918352-19.patch) to this issue's fork, as no other patch after that patch provided an interdiff, it is hard to tell if it introduced any regression.

Alright, fixed the upstream core issue for 11.x! Works great, with the changes from the issue fork. Now we need to backport #2858890: Drupal.views.ajaxView is not initializing pagers in nested views to 10.1.x, create tests here and create a new SemVer branch, based on the Drupal version #2858890: Drupal.views.ajaxView is not initializing pagers in nested views gets commited to.

Thanks @Grevil for working on this! The good news is, that it even works without the core patch, which simplifies things a lot. Even with the core patch, it still works, as @Grevil confirmed.

So we only need a test now to prove it works and didn't work before and then we can finally fix this old major issue!

Attaching the current MR state as static patch for composer.

Hiding all patches to proceed in the MR finally.

Interesting, the tests do not run at all under Drupal 10 and fixing the test theme, will make them "properly" fail:

1) Drupal\Tests\views_infinite_scroll\FunctionalJavascript\InfiniteScrollTest::testInfiniteScroll
Failed asserting that 0 matches expected 3.

/var/www/html/vendor/phpunit/phpunit/src/Framework/Constraint/Equality/IsEqual.php:96
/var/www/html/web/modules/custom/views_infinite_scroll/tests/src/FunctionalJavascript/InfiniteScrollTest.php:127
/var/www/html/web/modules/custom/views_infinite_scroll/tests/src/FunctionalJavascript/InfiniteScrollTest.php:62
/var/www/html/vendor/phpunit/phpunit/src/Framework/TestResult.php:728

(without the changes from this issue)

UPDATE: The custom assertion methods use theme specific classes, which are not available in "stark", using "starterkit_theme" for a replacement for "classy" instead of "stark"

I don't get it, "testInfiniteScroll()" inside "tests/src/FunctionalJavascript/InfiniteScrollTest.php" should already fail right now... but it doesn't for some reason...

Here is a patch with only the tests adjusted, but without the changes from this issue (which should fail rn).

EDIT: They succeed, but failing was expected.

My apologies, the test doesn't specifically test views inside views...

That's why the tests succeed.

Ok, @Anybody and I just tested this extensively, and it seems the problem doesn't exist anymore for 2.0.x!

We used the drupal core "glossary" view and changed the pager to use infinity scroll, and everything worked as expected!

These are the pager settings we used:

Pager
Use pager: Infinite Scroll | Click to load, 1 item

More link:
No

After I got on the "/glossary" page and pressed "Load more" a few times, this was the output:

Note, that the duplicate table headers are unrelated (This is a different issue #2899705: Headers in table format repeat on load more instead of adding rows).

This might still be an issue related to 8.x-1.x, so I will set the version appropriately and postpone this issue, for people to still see this issue, when running into this again.

EDIT: We also tested all formatters with only the pager set (without the attachment, leading to not having a view inside a view). That also worked just fine!

The issue does not exist in the latest 2.0.x branch. But it can be committed into 8.x-1.x branch.

@Grevil: See #43 - what should we do here?
I don't think we should touch 8.x-1.x.

Still there are changes in the MR against 2.x?

@Grevil: Without the fixes here, the tests in 2.x are broken... so should we merge this into 2.x or better create a separate issue to fix the tests and close this one as the issue seems to be fixed in 2.x as of #43?

Yes, the issue is fixed and not present anymore in 2.0.x. Drupal 8 is EOL, so we shouldn't make any changes inside 1.x anymore.

Apart from the theme switch, nothing in here is worth committing.

Let's close it.

Ok, should someone encounter the same in 2.x, feel free to reopen with clear steps to reproduce. Thanks!