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

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.

theMusician → changed the visibility of the branch 1383696-how-to-change to hidden.

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.

fjgarlin → changed the visibility of the branch drupal-1383696-82 to hidden.

fjgarlin → changed the visibility of the branch drupal-1383696-82 to active.

acbramley → changed the visibility of the branch gerardc/1383696 to hidden.

acbramley → changed the visibility of the branch gerardc/1383696-c to hidden.

acbramley → changed the visibility of the branch packern/view-grouping-header to hidden.

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

CarlyGerard → changed the visibility of the branch drupal-1383696-drupal-1383696-82 to hidden.

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.

https://www.drupal.org/project/drupal/issues/3448036 🐛 InstallerTranslationExistingFileTest fails on 11.x branch Active

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 📌 Document ViewsConfigUpdater Active

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 ✨ Add support for tables with two headers in views table display Needs work