Problem/Motivation

Fields label in views can be configured to display or hide the colon after the label.

Hiding the colon does not work when the field is used as grouping field: the group label will always display the colon regardless of the selected option.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

FiNeX created an issue. See original summary.

larowlan’s picture

Priority: Normal » Minor
Issue tags: +Bug Smash Initiative

Thanks for reporting

beatrizrodrigues’s picture

Assigned: Unassigned » beatrizrodrigues
beatrizrodrigues’s picture

@FiNeX Could you provide me more information about the problem? I created a scenario but I'm not being able to understand when this happens, this was what I did:

  • Created a view
  • Added some fields like : Title, Topics and Date
  • I created some contents and added the same topics for two of them
  • I clicked on edit at my view and after I clicked on FORMAT > Settings
  • And I chose my "topics" field as Group Field Nr.1

I'm not sure if I follow the right steps...'Cause as I said I couldn't reproduce the problem you talked about. So if you could give me the steps it would help me a lot. thank you!!

FiNeX’s picture

Hi,

the steps to reproduce the bug on a clean D9 installation are:

0) create at least one article
1) create a view with article nodes. Page or block it's the same.
2) select to display fields: title and something which can be grouped, like author.
3) on the "author" field settings select a custom label and be sure that the ":" option is turned off. Also disable to print the author as link to keep the output clean.
4) select unformatted list (or html list, it does not matter)
5) select the "author" field as a grouping field.
6) save the view and watch the result:

The ":" is hidden from the rendered field, but on the grouping field title is still visible.

Thanks for your attention.

beatrizrodrigues’s picture

Thank you for the steps, @FiNeX. I was able to reproduce so I'll be working working on this.

FiNeX’s picture

Thank you very much @beatrizrodrigues !

beatrizrodrigues’s picture

Assigned: beatrizrodrigues » Unassigned

I unassigned me from the issue because I'm not being able to resolve it. I found the point of the code that I could remove the colon
( template_preprocess_views_view_unformatted(&variables)), and it stayed just it had to be, but I'm having some problems with find the property that tells me that the label colon it is not requested. Besides, I think the changes must be not only the template_preprocess_views_view_unformattedbut at all formats that includes the "place a colon" option. So, as I'm very stuck, I will unassigned me. Thanks.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Lendude’s picture

Priority: Minor » Normal
Status: Active » Needs review
FileSize
2.39 KB
3.37 KB

This is handled in the StylePluginBase class and it does indeed not take this setting into consideration.

Here is a test and a fix for this.

The last submitted patch, 10: 3247619-10-TEST_ONLY.patch, failed testing. View results

danflanagan8’s picture

Status: Needs review » Reviewed & tested by the community
FileSize
7.61 KB
7.75 KB
7.97 KB
7.85 KB

I made a little view to test and it looks like the patch works.

  1. Colons without patch:
  2. "No-colons" without patch:
  3. Colons with patch:
  4. No-colons with patch

And the new test coverage looks good. It fails perfectly.

I thought that the changes below were out of scope, just some nearby cosmetic changes. Then I realized that we need to keep $expected from being altered because we use it in the new coverage further down.

+++ b/core/modules/views/tests/src/Kernel/Plugin/StyleTest.php
@@ -227,15 +227,49 @@ protected function doTestGrouping($stripped = FALSE) {
-
+    $no_label_expected = $expected;
     // Remove labels from expected results.
-    foreach ($expected as $job => $data) {
-      unset($expected[$job]);
+    foreach ($no_label_expected as $job => $data) {
+      unset($no_label_expected[$job]);
       $job = str_replace('Job: ', '', $job);
       $data['group'] = $job;
-      $expected[$job] = $data;
+      $no_label_expected[$job] = $data;
     }
-    $this->assertEquals($expected, $sets_new_rendered);
+    $this->assertEquals($no_label_expected, $sets_new_rendered);

But now this all makes sense. RTBC. Cheers!

FiNeX’s picture

Hi, thank you both for the fix!

  • catch committed 8afba83 on 10.0.x
    Issue #3247619 by Lendude, danflanagan8, FiNeX, beatrizrodrigues: "Place...
  • catch committed 77d5784 on 9.3.x
    Issue #3247619 by Lendude, danflanagan8, FiNeX, beatrizrodrigues: "Place...
  • catch committed d78321e on 9.4.x
    Issue #3247619 by Lendude, danflanagan8, FiNeX, beatrizrodrigues: "Place...
catch’s picture

Version: 9.4.x-dev » 9.3.x-dev
Status: Reviewed & tested by the community » Fixed

Looked at the test to see if it was worth trying to redefine $expected into multiple arrays in the first place, but that'd be tonnes of boilerplate so the bits of manipulation seems OK.

Committed/pushed to 10.0.x and cherry-picked to 9.4.x and 9.3.x, thanks!

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.