Allow a custom HTML element to be selected for a grouping field

Even overriding a tpl doesn't help as this is not themable at the moment.

There is an issue #477338: Multiple group: group by more than one field which would allow you to theme that.

Well you could try to use the views_field_view module, but it's probably kind of hard to get the groupby working with it.

Reg,

I'm dancing around with views grouping fields with strange results. I have a users view that creates a "staff" page with these fields:

• Username
• Image (image field on user entity)
• Bio (long text field on user entity)
• Title (authored-by-user relationship: title of node)
• Subtitle (authored-by-user relationship: text field on node)

If i choose to group by username, the grouping gets surrounded by an H3. I then exclude this field from display so that it doesn't display in both the grouping andinterior fields. But if i follow the same logic by adding the bio field as a second grouping field, then it gets the H3 and the username becomes a simple div. Obviously wrapping a long text field in a H3 is not what i want to do. What i ultimately want is something like this:

<h2>Username</h2>
<img>image of user</img>
<p>user bio</p>
<p>posts by user</p>
<h3>title</h3>
<h4>subtitle</h4>

I don't know how to build the kind of views parent/child relationship using contextual filters which you've described. Can you help me and others understand how this works?

Thanks for your reply Reg,

I was hoping to solve my use-case without an extra module, but if i absolutely cannot, then i'll definitely look into Views Field View.

Personally, I think this could use a basic fix: Honor the HTML tag setting of the field that the grouping is based on ('Grouping field nr.N').

All the functionality is there, including the ability to override the content, change the surrounding tags, etc. If the grouping setting just used the related fields settings this would be a breeze. I also think this would naturally be expected (at least I anticipated this would be the default behavior).

There are problems with doing this automatically

• This would break all existing groupby views, because people never expected to work like that
• You have to make it configurable based on the first argument

If you change the format to HTML list and select a grouping field it gives you options to add classes to the wrapping element as well as the list and the list parent.

I just created a template file that overrides for only that one view and changed the H3 to an H2

I just ran into this issue as well. It was a simple matter of switching the display to Semantic Views (you'll need that module to do this) and then change the "GROUPING TITLE > Element" to h2. I don't think this is really an issue with Views, it's a themer's task to solve things like this (i.e. #13 above using a template file is a good example as well). Views gives you what are reasonable defaults but it can't anticipate every possible scenario and use case for a themer and a design.

I solved this problem using the solution in #13 of overriding the views template file in my custom theme.

I can confirm that it does work despite the comment in #2. You must override the views style template for your currently selected style (I used unformatted list so that is the template I describe). Here are the exact steps I used.

1. Copy the views-view-unformatted.tpl.php template file from sites/all/modules/views/theme and place it in your theme's templates folder.

2. Figure out the machine name of your view. Mine was called products_by_category. One way to see this machine name is to edit the view and then look at the URL in your browser address bar. It will contain the machine name: admin/structure/views/view/products_by_category/edit

3. Rename the template file you copied in step one to have your view name after --. So I renamed mine to: views-view-unformatted--products_by_category.tpl.php so it would only override for this particular view.

4. Edit the template file and adjust the line displaying the title to use whatever you want instead of h3. I made mine use a <div class="category-description"> instead of the <h3>:

<?php if (!empty($title)): ?>
  <div class="category-description"><?php print $title; ?></div>
<?php endif; ?>

5. Save everything and clear your site caches.

6. Now when you load your view it should use the new overridden template and your group field will have the markup you want.

#14

I don't think this is really an issue with Views, it's a themer's task to solve things like this

That's why Views should not be adding h3 tags to every group 2 level...

Views adds h3 tags for both HTML List and Unformatted list for group 2. Group 1 gets no heading at all it seems.

One can already provide custom style settings for a field. Views should use that instead of this hardcoded h3...

Just in case someone is interested, I opened a feature request against Drupal 8.

awesome, here is the ref #1880100: Allow to configure the h3 element for view style plugins

Just peeked at your post tracker dawehner. Wow, you're doing a massive amount of work. A thread updated around every 10 minutes :)

The drop is always moving!

I just encountered the same problem.
And I can't for the life of me understand the logic behind views adding a random h3 tag in the middle of everything.
It makes no sense at all, and just creates extra work since you have to create a workaround.
Please remove the h3 tags and make everything unformatted unless you add custom style settings to it.

The solution in #15, works in version 6.x too.

Solution in #15 works perfectly. I changed the H3 to H2 and it all works beautifully. Should not have been an issue at all though - views really should allow you to select the style for the grouping fields just as it does for other fields, as giorgio79 suggested.

#13 worked for me!

#15 perfect fix for Grid style as well.

#15 (damien_vancouver) So easy! Thanks for the instructions. With this custom template I could also add an extra div wrapper around the list to simplify placing on a susy grid.

Thanks. Post #15 worked for an html list presented in a block. In my case I am using an html list view so my filename is views-view-list--rss_block.tpl.php.

There is a themeable function that you can override to style the group however you want. Simply use this function in your template.php file in your theme: (This function originally comes from theme.inc within the view module)

function YOURTHEMENAME_views_view_grouping($vars) {
  $view = $vars['view'];
  $title = $vars['title'];
  $content = $vars['content'];

  $output = '<div class="view-grouping">';
  $output .= '<div class="view-grouping-header">' . $title . '</div>';
  $output .= '<div class="view-grouping-content">' . $content . '</div>' ;
  $output .= '</div>';

  return $output;
}

Am I crazy, or does this (the theme function above, as well as the views-view-grouping.tpl.php file) only work if you have multiple levels of grouping? I suppose that's because of dawehner's comment about breaking backwards compatibility?

So a nice little trick I just figured out:

1) Set the grouping field to the same field for level 1 and 2

2) Remove this chunk from your views-view-style.tpl.php file (copy it to your theme and modify there)

<?php if (!empty($title)): ?>
  <h3><?php print $title; ?></h3>
<?php endif; ?>

This removes the grouping markup for level 1

3) Copy the views-view-grouping to your theme and go nuts. You can (probably want to, unless you want to modify all groupings) rename to target just the view you're working on (views-view-grouping--view_machine_name--display_id.tpl.php or the like). If you're ok with targeting the way ALL groupings are rendered, the theme function that @ladybug mentioned should do the trick too.

In fact, I created a views-view-grouping--view_machine_name--display_id.tpl.php, which worked great, but then I tried a preprocess function named MYTHEME_preprocess_views_view_grouping__view_machine_name__display_id(&$vars) but it didn't work. I tried getting less specific, like just MYTHEME_preprocess_views_view_grouping__view_machine_name(&$vars) but to no avail. Only the MYTHEME_preprocess_views_view_grouping(&$vars) works from what I tried:

function ltl_preprocess_views_view_grouping(&$vars) {
  $vars['title'] = 'Group ' . $vars['grouping_level'];
}

Finally, note that there is a known bug that is being worked on, where $vars['grouping_level'] is always 0 to the template from the preprocess function above. #1488744: Grouping level is always zero in views_plugin_style::render_grouping_sets() has a reasonable approach to handle in your theme and patches underway.

Also, while I'm here, any ideas how to get a count of the groups? I don't see any way to do so at first glance...

#15 +1 cool

Regarding formatting titles of the 1-st (outmost) grouping level in multi-level grouping case, my solution: I've used firebug and noticed that they have css class="view-grouping-header". This class is used in views-view-grouping.tpl.php (and in theme.inc as well). So I've simply declared this class in vews.css (just for testing) and set desired font setting there, and now my 1-st level titles looks great.

Why not rewrite the output of the field that is used for grouping, wrapping it with the required HTML tags?
No hook nor template nor extra module needed (at least with Views 7.x-3.18).
This also works for multiple groupings: rewrite each field output as wished.

Re: #33 - I am doing that, but all the rewriting is being wrapped in a H3 tag. My rewriting is in a custom field which is used as the grouping field. @PhilY - how did you get it working?

@millioleaves: on the view's fields list, edit the one you wish to use for grouping to rewrite its output to (for example): <h2>[node:field_myfield]</h2>. Usually, you would also hide that field.
Then, when you use it for grouping, it outputs as rewritten rather than with native <h3> wrapper.

#12 Simple and easy solution of the problem. Thank you very much Travis. You saved my time

As of today the issue dawehner created did not get into core.
#15 appears to be the most manageable workaround with the least tradeoffs.

I stumbled upon this issue now. I have to say that this really sounds strange that you have no way to select the tag for grouping when you have it with normal fields. And then there is forced H3 for the first last grouping item.

How in the Earth this kind of thing has passed testing years ago and is still not fixed? :)

The h3 should not be hard-coded. Will the maintainers accept a patch that makes the grouping element be configurable?

h3 should not be hard-coded, I agree. I have found a workaround since then by applying a class on the text affected by it via a custom field. It is so strange.

I just ran into this myself in Drupal 8 core Views UI. There is probably very little chance this will get 'fixed' in Drupal 7 contrib Views so updating the IS accordingly.

Project: Drupal core
Version: 9.1.x-dev
Component: views_ui.module

Chiming in with this, as well. I also just ran into this. Although, I found that the previous dev hardcoded it. I'd love to be able to delete this comment now, but it seems that's not an option.

Here's a work-around for this pesky problem...

• Edit the field being used for grouping
• Open "Rewrite results" > Check "Override the output"
• Begin the override text string with </h3>, which cancels the troublesome html element
• Insert your own tags and/or elements

Example:
The grouping field has the machine name of "field_model_component".
The override text =</h3><div class="my-style">{{ field_model_component }}</div>

@#43: This likely works visually in many themes, but it would result in invalid HTML and would have accessibility problems due to the empty header element.

I've solved this for years using the template copy method in D7, but also never understood why you can change the H-level in the field UI but not for the grouping. I ran into it yet again just today and so came back to see if anyone else had recently posted. 😄 IMO, headings should always be configurable, whether in a field, a block, view, layout builder, whatever for proper outline/accessibility.

I just ran into an issue in Drupal 8.9 where I cannot override the views grouping template at all if I don't have at least two grouping levels. views-view-grouping.html.twig does not seem do anything at all in this situation, nor can I trigger template_preprocess_views_view_grouping(). If I use two grouping levels, the second one does not have a template that I can override. This seems similar to what scotwith1t mentioned in #28, but his solution appears to have been for D7 and I cannot find a corresponding workaround for D8.

If I enable the twig markup debugging, it says the grouping title uses views-view-field.html.twig, but there does not seem to be any actual grouping going on in the templates at all. I don't have an h3 at all to remove, but I desperately need to be able to wrap field groupings in custom markup and I cannot. Has anyone discovered a similar workaround for this? Drupal's theme layer is basically telling me that the grouping I set in the views UI is not actually a grouping. It is maddening.

So far, the only simple workaround I've found is to add a dummy custom text field to the view, hide it from display, and use that as the first grouping level. Then, the real group I actually wanted to create can be grouping level two and Drupal will let me theme that.

Alternatively, you can edit your twig template, in this case, views-view-unformatted.html.twig and do some complicated logic where you repeatedly check the condition

{% if view.style_plugin.options.grouping %}

and then insert and modify whatever markup is needed to properly group things together. For second level grouping and deeper, you'd still have to modify views-view-grouping.html.twig.

But this seems like a really bad bug that needs to be fixed. I imagine it shouldn't be so confusing to figure out that grouping is treated differently depending on the grouping level and then come up with completely different approaches.

The Semantic Views contrib module mentioned in #14 seems to work as a workaround, as long as you want your view to display as an unformatted list or html list. And I was able to use CSS to make an unformatted list in a Semantic Views Style display look like a multi-column vertical-alignment grid display.

But I'm a +1 that this needs to be fixed in core.

Is it possible for this to be back-ported to 9.4.x? I'm running into an issue that I think this issue resolves where grouping by a date field results in duplicate content because when editing the views-view-unformatted.html.twig file it thinks that

{% if title %}
	<h3 id="{{ title|striptags|replace({"\n":'', "\r":''})|lower }}">{{ title }}</h3>
{% endif %}

is the title field, when in fact it's the grouped by field. Thus making it almost impossible to then create a {% for row in rows %} loop.

Hi Laura, since this is a new feature, Drupal recommends we develop for 10.1.x (see comment #59), so our team can't backport this fix to 9.4.x. If you have the dev time and need this for your site, you're welcome to use the dev branch as a baseline and make a custom 9.4.x patch for your site and/or theme.

Just a warning, since I have no idea what the actual state of this is, the MR currently contains a massive amount of unrelated code clean up, if this is to have any chance of landing those need to be removed.

Thanks for taking a look and giving the pull request a review @lendude. I think "needs work" as a status makes sense for now--it is an active ticket but the next major task on our list is writing tests, and I think there's redundant line cleanup I agree needs to happen before we go on to that step (it seems like there were some rebase/conflict issues I missed, causing the repeated lines).

Some code changes, though, are based on results we get from running the PHPCS Drupal standard, would you consider that "unrelated code"? When we run Drupal PHPCS on the 10.1.x version of Grid.php on line 64, for example, we get the following error (this becomes line 71 with the MR 2922 changes):

FILE: [base-path]/test-drupal10/web/core/modules/views/src/Plugin/views/style/Grid.php
-----------------------------------------------------------------------------------------------------------------
FOUND 1 ERROR AFFECTING 1 LINE
-----------------------------------------------------------------------------------------------------------------
 64 | ERROR | The array declaration extends to column 96 (the limit is 80). The array content should be split up
    |       | over multiple lines
-----------------------------------------------------------------------------------------------------------------

Since we're developing on this file and should push code that meets Drupal's coding standards, it seems like it would be our responsibility then to help get the newer version of the file up to standard. Agreed all of our new code should follow that standard, but if there are minor changes like that one (1-5 lines tops), should we not get the code syntax up to standard as well?

I will write the change record for this ticket.

I think this would apply to WCAG SC 1.3.1

This patch file re-rolls previous MRs from Gitlab workflow as a patch file for 11.x Work still needs to be done in figuring out caching so the wrapper tag option is stored properly. A new patch is needed once that's addressed.

Should fix Drupal command fails in 11.x re-roll patch from #80.

It appears the patch was applied cleanly. There is what seems to be an unrelated error in a unit test when testing the merge request.

https://git.drupalcode.org/issue/drupal-1383696/-/jobs/1255878

Drupal\Tests\editor\Functional\EditorSecurityTest 0 passes 1 exceptions
FATAL Drupal\Tests\editor\Functional\EditorSecurityTest: test runner returned a non-zero error code (2).
Drupal\Tests\editor\Functional\EditorSecurityTest 0 passes 1 fails

---- Drupal\Tests\editor\Functional\EditorSecurityTest ----
Status    Group      Filename          Line Function                            
--------------------------------------------------------------------------------
Exception Other      phpunit-93.xml       0 Drupal\Tests\editor\Functional\Edit
    PHPUnit Test failed to complete; Error: PHPUnit 9.6.15 by Sebastian
    Bergmann and contributors.
    
    Testing Drupal\Tests\editor\Functional\EditorSecurityTest
    ..E                                                                 3 / 3
    (100%)
    
    Time: 00:23.789, Memory: 4.00 MB
    
    There was 1 error:
    
    1)
    Drupal\Tests\editor\Functional\EditorSecurityTest::testEditorXssFilterOverride
    Behat\Mink\Exception\ExpectationException: The field "edit-body-0-value"
    value is "Hello, Dumbo Octopus!alert(0)", but "Hello, Dumbo
    Octopus!alert(0)" expected.
    
    /builds/issue/drupal-1383696/vendor/behat/mink/src/WebAssert.php:888
    /builds/issue/drupal-1383696/vendor/behat/mink/src/WebAssert.php:781
    /builds/issue/drupal-1383696/core/tests/Drupal/Tests/WebAssert.php:968
    /builds/issue/drupal-1383696/core/modules/editor/tests/src/Functional/EditorSecurityTest.php:447
    /builds/issue/drupal-1383696/vendor/phpunit/phpunit/src/Framework/TestResult.php:728
    
    ERRORS!
    Tests: 3, Assertions: 137, Errors: 1.

All old MRs and patches are now hidden, work should be continued on https://git.drupalcode.org/project/drupal/-/merge_requests/7351

New code appears to be passing.

Left some comments.

Didn't check but if any of those templates are declared in a theme in core they'll have to be updated too.

Definitely will need a CR and probably submaintainer sign off