Group by does not work after clicking load more with AJAX turned on.

The "Needs work" status indicates a patch was presented, but doesn't fulfill the needs to be considered fixed--or discussion is needed to ensure it is handled properly.

The View understands how to render the first page, but this module was not written to support it. A significant undertaking would be necessary to accomplish this, requiring the javascript to be capable of finding specific points where each group starts. I'm changing this to a feature request, since it is not built-in.

Actually this feature request should solve some other issues like:

• confused zebra striping (odd / even)
• vanishing group by heading
• row class issues (if using flag javascript within a row for example)
• multiple spinner / throbbers when sorting on a column (click head)

I believe these issues are all intertwined because they are the result of just adding rows to the view content.

To solve the problem in our use case it suffices to add a jquery ":last-of-type" selector to .views-table.
See attached patch for a quick fix

also, perhaps the ajax_command_restripe function can be used in cases where and odd number of results per page are used. see: https://api.drupal.org/api/drupal/includes%21ajax.inc/function/ajax_comm...

There are futher problems with the fix above... If the group heading is on the second page, it won't be loaded on "load more".

I can't replicate the issue on the latest 7.x-1.x-dev. Could you try and see if the issue still exists against the latest 7.x-1.x-dev? If it does feel free to re-open. However as wjaspers was alluding to, I'm not sure there is much we could do if the views load more pages are the same as what you get out of view when just using regular views paging with grouping.

Thanks,
Matt

I can confirm that the issue persist. Here's the patch which fixes the following:

• confused zebra striping (odd / even)
• duplicated group heading (if only part of the group was viewed on the first/previous page)
• don't bother with zebra re-stripping if it was turned off in Admin UI

Thanks @xumepadismal. I like your solution, but I'm a bit concerned of the possibility that something that isn't a header will end up being removed by this. The crux of the issue here is that views templates can be overriden. For example someone could potentially override views-view-unformatted.tpl.php and add things surrounding the title that are not the title. These would be removed.

Since we can't know what changes to the template may/may not occur, I think the most we can do is to reset the zebra stripping when present. Perhaps we could trigger a JS event that would allow other modules/themes to affect the view as a whole after it's been added to the page.

@m4olivei, I see what you mean and it sounds reasonable to me. However, I don't like idea to fix this in other modules/themes...

We can maybe add some setting in the 'Advanced options' of the 'Pager options' popup. For example it can be 'Group heading selector' which will defaults to 'h3'. And then we can modify my patch to use this selector instead of assuming all non-views-row elements.

What do you think? I will modify my patch once you accept this approach.

Making a small change to #6. In our particular case the dom had the groupheading titles at a level below odd/even row elements. In this patch, the code does a .find for all the '.grouping-title' classes and then loops thru those to remove any duplicates found.

Very simple patch based on idea from #9. Since it's quite hard to resolve the issue for all cases (for different view formats etc), the purpose of the patch was to keep it simple and fix grouping at least for unformatted views only when group title has .grouping-title class (to avoid breaking existing views). So, in order to see the work of the patch you have to override the default template views-view-unformatted.tpl.php and add .grouping-title class to h3 tag or any other tag you want to use for group title. Otherwise the patch will not impact any of your views.

I hope this helps someone!

@shevchess: the patch does not work and I do not really like to force people to create templates and adding a fixed class.

Here is a patch that fixes the issue for lists. Results are appended to existing groups if they exists or the all new groups are appended to the others.

I didn't test it for unformatted lists, but maybe it works or with small work it could be quickly fixed.
So this patch is a basis to work on if somebody is interested, as I will not work further on this except if needed for a client.

@B-Prod: you see the goal of the patch #10 was to have a very basic workaround but not a solution of the problem in general and the main thing was not to break any of existing views and make grouping work for unformatted views. It does work for the view I applied it to and I thought it's worth to publish the workaround here since the issue is old and doesn't have any solutions and it might be useful for someone to get an idea how to get it working for their specific case with minimal changes to the module's code.

Obviously that forcing people to create templates and adding a fixed class can't pretend to be a solution of the problem but it could be useful to have a workaround when there are no solutions at all.

As for the patch you attached, it looks very good for me even though I didn't test it. Great that we can use wrapper_class, wrapper_prefix and wrapper_suffix vars.
But it looks like
$vars['wrapper_suffix'] = '</div>'; should be $variables['wrapper_suffix'] = '</div>';