Headers in table format repeat on load more instead of adding rows

I had a look at the code, and in it there are no rules to prevent that from happening. Unfortunatley, I am not experienced enough to poke at it yet.
An easier workaround, for the time being, is to hide all headers except the first one like this in CSS, or less:

.views-infinite-scroll-content-wrapper{
	.table-responsive table thead{
		display: none;
	}
	.table-responsive:first-child table thead{
		display: table-header-group;
	}
}

This might do the trick.

The patch in #4 works for me, thanks!

However, would it be better to do this with an attribute? i.e. in views_infinite_scroll_preprocess_views_view(), check if the display is set to table mode & add an attribute similar to data-drupal-views-infinite-scroll-content-wrapper. Then in javascript we can check for this attribute & if present, rather than check for $(contentWrapperSelector + ' tbody').length - if there is a table within the rendered results (but not using table mode) this could trigger that check? The attribute method wouldn't.

Leaving as needs review rather than RTBC so we can discuss the above.

Here's a failing test. Going to look into changing the wrapper at a plugin level.

I tried looking at a solution from the preprocess level but I'm not sure if it'll be possible. The problem is is that in views_infinite_scroll_preprocess_views_view(), $vars['rows'] only contains the row results. It's not until template_preprocess_views_view_table in views.theme.inc that it adds the rows and headers into different keys in $variables. Since the 2 hooks have no way of interacting I'm not sure if this is possible without a decent change in architecture.

Having issues with the tests running locally so I'm uploading a patch with #6 and #4 combined to see if that passes.

I agree that the patch in #4 is using a too generic selector which may cause messy results if there are any unrelated tables inside the wrapper. Maybe this one will be good enough (thanks for the test, acbramley!).

Messed it up a bit :)

Made the selector safer.

Hi, same problem is for the Drupal 7.x-2.1 Version. Is there a backport for the patch?

OK, problem for 7.x-2.1 is solved with the patch in https://www.drupal.org/project/views_infinite_scroll/issues/2736419#comm...

#2899705-13: Headers in table format repeat on load more instead of adding rows is working fine :-).

Doesn't work for me with version 8.x-1.5 :(

What do you need for reproduce this?

@Daniele Nicastro maybe the javascript console is showing some errors? Are you using a custom theme? Maybe you are customizing the twig output of the table?

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.

Just applied the patch in #13 on Drupal 8.6.15 and it applies fine but doesn't seem to do anything. The load more button still loads in the table headers.

Re-rolling patch in #24 against current 8.x-1.x

Fixed line indents.

Please contribute to #3098132: [MASTER] Handle style plugin specific wrappers around views rows properly to find a clever solution and write tests for all core and contrib views style plugins. :)

The patches here show one possible solution but should then be more generalized. We shouldn't add case if clauses for specific views style plugins or > thead, ... That's why I'd suggest to close this issue in favor of #3098132?

It sounds like some things may need to change from an approach standpoint, but FWIW, the latest patch (from #26) reverses a change/fix made in https://www.drupal.org/project/views_infinite_scroll/issues/2945524.

The patch in #26 works for me.

#4 Work for me.

Patch doesn't apply to the latest dev codebase, needs a reroll

   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  3005  100  3005    0     0   1946      0  0:00:01  0:00:01 --:--:--  1944
error: patch failed: views_infinite_scroll.module:36
error: views_infinite_scroll.module: patch does not apply

Re-rolled patch, please review!

patch in #33 no longer applies.

Re-rolled patch.

The tests from #6 need to be added back in and should be uploaded as 2 new patches with the failing tests again + the fix and tests.

Are these successful patches going to be included into a new version? There seems to be a lot.

Applied #35 to 8.x-1.8 but still the table header is repeated. Tried with normal table and bootstrap table.

#35 worked for me on Drupal 8.9.19

I had the same problem with Duplicated headers.
#35 worked for me.

However I have another View Style Module that extends the Table View Style.
In this case, the solution in #35 won't work, so the logic must be duplicated for every View Style extending Table View Style.

I guess a more generic solution could be made by using a different hook in #35 patch.

Maybe instead of: views_infinite_scroll_preprocess_views_view_table
replace with a hook like: hook_preprocess_HOOK, and check if it current View Style is extending Table View Style

hope to find some time to work on it.

The patch from #35 applied well and worked to stop the duplicating of headers. However it didn't work along side using the views_bulk_operations module, as it cleared the attributes and classes set on the container that are required for VBO to work. This may also have the same effect when used in conjunction with other modules.

I have updated the patch so that it adds these attributes and classes, rather than replaces existing ones.

This is using views_infinite_scroll 1.8, and using Drupal Core 9.3.6.

Thank you very much @mjmorley - to push this forward it still needs tests.

This is using views_infinite_scroll 1.8

but your patch is against 8.x-1.x-dev I hope? :)

Hi @Anybody, both of the tests on 8.x-1.x have ran successfully :)

@mjmorley, see #36. These tests from #6 / #8 are still missing in your patch, until the required tests are present, this won't be ready for the final review.

@Anybody I seem unable to select any D8 version in testing?

The patch from #41 applied succesfully on the new 2.0 branch on 9.4.8. and seems to be working as expected.

Applying patch from #41 solves the issue for me as well. Using Drupal 9.4.8, but you need to clear the caches after applying to patch.

Can we push this to production? Seems like something already fixed just needed a bit of googling to find the patch.

Fixes test module .info.

Dev is on 2.0.x now

Patch had some fuzz, rerolling for 2.0.x

This issue exists for unformatted list and html list as well. The patch does not include that.

These patches fix one problem instead of underlying issue - this module needs to receive only new content via AJAX, not whole view output as in ordinary pagers. Problem is larger one - with table headers, lists, exposed filters and probably more.

The patch of #10 from https://www.drupal.org/project/views_infinite_scroll/issues/3093929 works well to replace the header and footer of the view.
In addition to the patch, I have made changes to remove the "Headers in table format repeat on load more"

So this patch will help solve the issue of the repeated table headers and static View Result Summary in 2.0.x
Also in 'Global: Result summary', "Displaying @start - @end of @total" might be misleading instead "Displaying 1 - @end of @total" can be used.

Could we please prove the situation before and after with a test?

Confirming that #53 did the trick for me on 2.0.1, while #56 didn't solve the problem?

I'm running Drupal 10.1.0 and I had the issue as well with the table headers being repeated, so I can confirm this is still an issue.

Thanks @florianmuellerCH what this module really needs are tests for all core view display formats. That way we can be sure, fixing one doesn't break another.

I assume this won't be merged, until the community did that. Furthermore, it might be discussable to allow alterations for different display formats, as tables just have different structures from lists, grid, ... as one can see.

So this still needs review and work for the tests. #56 has no interdiff, so I'll hide it and we proceed with and review #53.

Needs tests, please.

I've noticed one problem with the patch above in case when using the option 'Grouping by field' its value is lost for results loaded by scroll.

Here is a patch that saves the grouping field(caption) with the next table data load.