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

The MR is now passing with the latest changes as requested (with some allowed fails in the pipeline). Updating status for the next stage of review.

Moving to NW for the change record

But question what will happen if $usesGroupingLabelElement isn't present. Lot of contrib plugins will take a while to update.

Thank you for the feedback.

To answer your question about if a view does not have $usesGroupingLabelElement present, the twig templates handle that logic and print the title. https://git.drupalcode.org/project/drupal/-/merge_requests/7351/diffs?co...

If it is present, such as after this patch is applied, but not set, the code supports the current default of the grouping label being an h3 or empty.
https://git.drupalcode.org/project/drupal/-/merge_requests/7351/diffs?co...

Contrib plugins would have an option of using this way of handling additional HTML options or could continue doing it however they currently make it happen.

There are a few of the core themes that use the twig template overrides for views-view-unformatted.html.twig, views-view-list.html.twig, and a few more. You suggest updating these in this same patch. As I understand it, the twig templates would be updated where appropriate for claro, olivero, stark, and starterkit_theme but not stable9. The same approach would be for engines/twig excluding updates to stable9. Is that correct?

Good morning,

I have authored a proposed change record for review by others. https://www.drupal.org/node/3446094

I have also pushed an updated branch that includes theme updates to the core themes where the views templates are included. I did not, however, update Stable 9 as my understanding is that the Stable 9 theme is locked in place. I am happy to make the changes there if required.

Went to review but appears MR has some failures

The test had been failing due to this upstream bug, that has now been fixed. Thanks to nicxvan and mikelutz for troubleshooting over in #contribute on Slack.

Resolved bug that was causing test failures: https://www.drupal.org/project/drupal/issues/3448036

Tests are now passing.

Coincidentally I just needed this patch myself. I suspect that this will need to add something to the ViewsConfigUpdater since it is adding config to Views.

I did this earlier this year and it can be quite complex, I'm working on documenting it here #3447755: Document ViewsConfigUpdater

I'm not sure why tests are not triggering on the changed config already, maybe cause it's a sub item under grouping, but this adds new config: grouping_label_element: h2.
I'm also not sure why it wouldn't be limited to heading tags like the views pager update linked in the documentation issue.

I'm happy to help guide someone on the views update config changes since I know it's a pretty significant wrench in the process.

This may need additional tests too.

It might be helpful to add an example of views-view-grouping.html.twig in the change record too since the starterkit theme generation is different than the example.

I am also getting this on pages with this patch, I think on views without a grouping set:
Undefined array key "grouping_label_element" in Drupal\views\Plugin\views\style\StylePluginBase->renderGroupingSets() (line 559 of core/modules/views/src/Plugin/views/style/StylePluginBase.php).

Thanks for the feedback. I agree that the undefined array key error is because the views did not get the update to set grouping_label_element to null.

The ViewsConfigUpdater code requirement makes sense to me as being necessary. On a separate issue, https://www.drupal.org/node/2770835, the test update never fires even though I wrote a function in ViewsConfigUpdater but I was not aware you have to also call the function in updateAll(). The documentation improvements for how to use ViewConfigUpdater is a great idea.

Here is a rough idea of what I think is needed. @CarlyGerard also involved with this ticket walked me through what this may end up requiring. In the protected function addGroupingLabel() I can't quite figure out what the handler represents. The parameter defines it as a display handler, so I think a view style is represented here as the handler_type "style" and that is also the plugin_id? These ideas came from one of the issues you referenced, thank you for the pointer - https://git.drupalcode.org/project/drupal/-/blob/96d21a4603df23080a34051....

  /**
   * Performs all required updates.
   *
   * @param \Drupal\views\ViewEntityInterface $view
   *   The View to update.
   *
   * @return bool
   *   Whether the view was updated.
   */
  public function updateAll(ViewEntityInterface $view) {
    return $this->processDisplayHandlers($view, FALSE, function (&$handler, $handler_type, $key, $display_id) {
      $changed = FALSE;

      if ($this->addGroupingLabelElement($handler, $handler_type, $view)) {
        $changed = TRUE;
      }

      return $changed;
    });
  }

  /**
   * Add Grouping Label to views without one.
   *
   * @param array $handler
   *   A display handler.
   * @param string $handler_type
   *   The handler type.
   * @param \Drupal\views\ViewEntityInterface $view
   *   The View being updated.
   *
   * @return bool
   *   Whether the handler was updated.
   */
  protected function addGroupingLabelElement(array &$handler, string $handler_type, ViewEntityInterface $view): bool {
    $changed = FALSE;

    // Add grouping label element to existing views.
    if (($handler_type === 'style')
      && isset($handler['plugin_id'], $handler['type'])
      && $handler['plugin_id'] === 'style'
      && $handler['type'] === 'Grid' || 'HtmlList' || 'GridResponsive' || 'DefaultStyle'
      && !isset($handler['style']['grouping_label_element'])) {
      $handler['style']= ['grouping_label_element' => NULL];
      $changed = TRUE;
    }

    return $changed;
  }

You asked, why the allowed grouping elements would not be restricted to just heading tags like the views pager update. For the grouping use cases, grid, HtmlList, GridResponsive it seemed hard to predict that one would only ever group by heading. Using labelELements, https://git.drupalcode.org/project/drupal/-/merge_requests/7351/diffs#11..., makes it so available elements do not need to be maintained in this code as well as the views.settings. I concur that the most common use case would be headings but I am not confident that there would never be a need to group by another element.

Thanks again for the feedback, the questions, and the guidance.

At a quick glance that looks right: also if you want to link an issue in a comment where the issue status color comes up can you use:
[#issuenumber]

like this #2770835: Add support for tables with two headers in views table display

I believe the ViewsUpdateConfig functions now are properly looping through existing views and setting the grouping to the default if it is not already set.

If using grouping on existing views, the default is the h3 element as it is already set to, after the config update executes.

The Needs Review Queue Bot tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

I'm unable to apply the MR as a patch against 11.x

Well I tried rerolling the MR but ran into a bunch of PHPCS and PHPStan errors in the build, but locally they aren't detecting any issues when I run them for Drupal standards. In addition to that the patch won't apply normally.

I believe some of my trouble applying the patch locally despite the phpcs stuff is related to rebasing across a rewrite to use class based hooks.

I'll keep looking into it, started to rebase on a new branch but was still on the main branch shown, maybe I will look into that new branch again to try and avoid introducing more issues.

When I did get the patch applied though I saw the dropdown for group markup, but I think I lost the multiple grouping levels that I'd expected.

Just pushed the original back to 39368b50 from another branch, I will continue trying to rebase from the other 11.x branch I started

@robcarr confirmed the reroll of this fix onto 11.x in MR !15366 works on 11.3, and patches cleanly.

There are a lot of PHPCS constraints added to main that will require some work to clean up and make this mergable there.

How exciting to see movement on this again. Thank you for pushing this along.

It does appear that there was more to the refactoring of addGroupingLabelElement than just getting it to use an array format for the display handler and styles values.

The structure of the style config appears to have changed and is deeper than it was. it was no longer just grouping_label_element but now has more and multiple group levels.

I also found that this has no effect on HTML Lists in the Bootstrap5 theme, the views-view-list template is overridden there and is also hardcoded with an h3

I might take a closer look at the display handler structure, see if it is an easy fix, but the theme situation feels like more of a blocker to me right now