Text format wrapper does not honor description_display

In the meantime, some template hackery can get this achieved, editing text-format-wrapper.html.twig to:

<div class="js-text-format-wrapper js-form-item form-item">

    {% set parts = children |split('</label>') %}

    {{ parts.0 |raw }}</label>

    {% if description %}
        <div{{ attributes.addClass('form-item__description') }}>{{ description }}</div>
    {% endif %}

    {{ parts.1 |raw }}
</div>

If used in a module, you'll need hook_theme_registry_alter() to set the path to it.

Bgilhome's hack is a nice trick.
But as I have multiple tags among the {{ children }}, I had to tweak it a bit to target only the first one:

<div class="js-text-format-wrapper js-form-item form-item">

    {% set parts = children |split('</label>', 2) %}

    {{ parts.0 |raw }}</label>

    {% if description %}
        <div{{ attributes.addClass('form-item__description') }}>{{ description }}</div>
    {% endif %}

    {{ parts.1 |raw }}
</div>

Otherwise, it does exactly what I need: it allows me to insert the description right after the first label.
Thanks a lot!

Bgilhome's hack, and christian's tweak, helped me make my node edit forms collapsible with the details tag.

I remove the first <label> and use it for the summary tag. (I should also check if the label exists.)

BUT, I'm sure there should be an easier, drupal friendly, way to do this. I notice, the image field type already uses a details tag with details.html.twig. (Maybe that's because it's the only field in my site with multiple values.) Any suggestions?

<details class="js-text-format-wrapper text-format-wrapper js-form-item form-item">
  {% set parts1 = children |split('<label', 2) %}
  {% set parts2 = parts1.1 |split('>', 2) %}
  {% set parts3 = parts2.1 |split('</label>', 2) %}

  <summary>{{ parts3.0|raw }}</summary>
  {{ parts1.0|raw }}
  {{ parts3.1|raw }}
</details>

Tagging for DrupalCamp Colorado's upcoming contrib day.

Ran into this. It's sort of a mess. Even if the text-format-wrapper.html.twig wanted to deal with this properly itself, it couldn't. By the time we hit that wrapper, the children elements have been rendered and glued together.

I believe the safest way to handle #description_display = 'before' is to *move* those attributes into the 'value' sub element. This seems to work well in local testing.

Before we can commit this, it needs tests. Also curious about the BC implications of this, and if this approach will fly. But uploading something to get us started. ;)

Thoughts?

Thanks!
-Derek

@dww any chance you could share what other steps were required to make this patch work? Did you have to override any preprocess functions?

I can't get this patch to work and I feel like I'm missing some important step. Thanks!

@sagannotcarl - Shouldn't need much. Apply patch, clear caches. However, the initial patch still doesn't support the 'invisible' case. It's only fixing 'before'. If you're trying to use 'invisible', it'll still be appearing. To fix that, we'd also need to start changing the core Twig templates, which is more of a mess. ;)

@dww Awesome got it working. It is the 'before' I'm after so this was perfect.

So now between this patch and #2396145: Option #description_display for form element fieldset is not changing anything I can pull my hair out a little less trying to get descriptions in the right place.

Created this patch with a slightly different approach than #13. Removing description from the excluded keys list lets it be handled by the child form-element template where description_display logic lives. This was tested with 'before' and 'invisible' values and seemed to work okay.

Forgot to attach the patch with last comment, sorry

The approach in #19 seems to work for me. Nice!
Should we update all the text-format-wrapper.html.twig templates to the new approach?

Moving back to needs work based on missing tests and some open questions.

+1 it is very hard to be able to display the description between the label and textarea for formatted text fields when description is removed in TextFormat.php processFormat() $keys_not_to_copy
This new approach seems better

Sorry to do this, but I've fixed a warning/notice coming from #13.

The other approach in #19 is probably better, but I don't have time to progress that solution, sorry!

Issues need to target 11.x. Also, I'm pretty sure 11.x requires merge requests. So creating new patches won't get us anywhere.

Ran into this again on another project. 😅 I agree #19 is better, all it does is remove code! Local testing and it's working fine.

We probably still want tests, so leaving NW and tagged, but I converted #19 into MR !7218 to move this along.

Also, this summary needs the real template and to be filled in.

#20 makes sense. I started removing description and related variables from most of these:

% find . -name text-format-wrapper.html.twig
./core/profiles/demo_umami/themes/umami/templates/classy/content-edit/text-format-wrapper.html.twig
./core/modules/filter/templates/text-format-wrapper.html.twig
./core/themes/stable9/templates/content-edit/text-format-wrapper.html.twig
./core/themes/claro/templates/text-format-wrapper.html.twig
./core/themes/starterkit_theme/templates/content-edit/text-format-wrapper.html.twig
./core/themes/olivero/templates/text-format-wrapper.html.twig

I ran into comments with @see pointing to #3016343: Fix inconsistencies of TextareaWidget and TextareaWithSummaryWidget form elements, so adding that as related.

I'm not sure what scope of a fix is appropriate. Currently, the MR only fixes Claro. I know we never touch stable9.

We can fix Olivero, starterkit_theme and demo_umami. But I'm worried about losing functionality if we completely remove all these lines:

-  {% if description %}
-    {%
-      set description_classes = [
-        aria_description ? 'form-item__description',
-        disabled ? 'is-disabled',
-      ]
-    %}
-    <div{{ description_attributes.addClass(description_classes) }}>{{ description }}</div>
-  {% endif %}

form-element.html.twig itself doesn't add a separate is-disabled class to the description classes, it adds form-item--disabled to the whole wrapper.

1. Do we care? Can/should we move this is-disabled class on description_classes to form-element.html.twig?
2. Can we fix modules/filter/templates/text-format-wrapper.html.twig itself?
3. Should we be removing all mention of aria_description from these templates, since we're not using that anymore?
4. While we're at it, the module template and most of the themes have a comment about * - attributes: HTML attributes for the containing element. yet they all do something like this this for the containing element:
   

   <div class="js-text-format-wrapper text-format-wrapper js-form-item form-item">
   

   In practice, attributes is only used for the description:

     {% if description %}
       <div{{ attributes }}>{{ description }}</div>
     {% endif %}
   

   That seems like a separate bug. Sound familiar? Needs follow-up?

For now, I pushed separate commits for:

• Olivero
• starterkit_theme
• demo_umami
• modules/filter/templates/text-format-wrapper.html.twig
• Removing aria_description from all of them

We can easily revert anything if needed. Curious to see what the bot thinks of all this. Probably some classy test is going to fail about template file hashes changing. 😅

Re: #30.4: Reading more closely, that's a big part of what #3016343: Fix inconsistencies of TextareaWidget and TextareaWithSummaryWidget form elements proposes to fix. So that doesn't need another issue. Hopefully this helps reviewers understand why we're leaving the templates alone in this regard. Perhaps we should preserve the @see comments pointing to #3016343?

Meanwhile, gave this a real summary.

A few more edits to make the summary more accurate

For tests, we could mostly copy modules/system/tests/src/Kernel/Form/ElementsFieldsetTest.php into ElementsProcessedTextTest.php or something (perhaps broaden it to also include textarea?). It feels a little gross to copy/pasta, but for now we're still at N=2 and haven't necessarily hit the Rule of 3. At least not that I'm seeing trying to grep the core code. 😅

Came here while triaging my queue on #3016343: Fix inconsistencies of TextareaWidget and TextareaWithSummaryWidget form elements

Readying the summary and something isn't clicking why we need to remove all the description? Maybe #18 can be captured in summary?