Contrib.social

Exposed filter template does not match drupal core

Open on Drupal.org →
Created on 17 January 2024, over 1 year ago

Problem/Motivation

After enabling this module, all date relevant views filter plugins are replaced as described but with a completly new visual output as core does. I think this has user acceptance difficulties because there is no dedicated template to override. Just re-alter the plugin via hooks.
The exposed filter is replaced with a fieldset.

Core view filter markup

<div class="form-group js-form-item form-item js-form-type-textfield form-item-date-end js-form-item-date-end">
  <!-- THEME DEBUG -->
  <!-- THEME HOOK: 'form_element_label' -->
  <!-- BEGIN OUTPUT from 'core/themes/stable9/templates/form/form-element-label.html.twig' -->
  <label for="edit-date-end">Enddatum</label>
  <!-- END OUTPUT from 'core/themes/stable9/templates/form/form-element-label.html.twig' -->

  <!-- THEME DEBUG -->
  <!-- THEME HOOK: 'input__textfield' -->
  <!-- FILE NAME SUGGESTIONS:
     * input--textfield.html.twig
     x input.html.twig
  -->
  <!-- BEGIN OUTPUT from 'core/themes/stable9/templates/form/input.html.twig' -->
  <input data-drupal-selector="edit-date-end" type="text" id="edit-date-end" name="date_end" value="" size="30" maxlength="128" class="form-text form-control">
  <!-- END OUTPUT from 'core/themes/stable9/templates/form/input.html.twig' -->
</div>

date_filter view filter output.

<fieldset data-drupal-selector="edit-date-end-wrapper" id="edit-date-end-wrapper" class="js-form-item form-item js-form-wrapper form-wrapper">
  <legend>Enddatum</legend>

  <!-- THEME DEBUG -->
  <!-- THEME HOOK: 'form_element' -->
  <!-- BEGIN OUTPUT from 'core/themes/stable9/templates/form/form-element.html.twig' -->
  <div class="form-group form-flying-label js-form-item form-item js-form-type-date form-item-date-end-date js-form-item-date-end-date form-no-label">
    <!-- THEME DEBUG -->
    <!-- THEME HOOK: 'form_element_label' -->
    <!-- BEGIN OUTPUT from 'core/themes/stable9/templates/form/form-element-label.html.twig' -->
    <label for="edit-date-end-date" class="visually-hidden">Datum</label>
    <!-- END OUTPUT from 'core/themes/stable9/templates/form/form-element-label.html.twig' -->

    <!-- THEME DEBUG -->
    <!-- THEME HOOK: 'input__date' -->
    <!-- FILE NAME SUGGESTIONS:
    * input--date.html.twig
    x input.html.twig
    -->
    <!-- BEGIN OUTPUT from 'core/themes/stable9/templates/form/input.html.twig' -->
    <input type="date" data-drupal-selector="edit-date-end-date" data-drupal-date-format="Y-m-d" id="edit-date-end-date" name="date_end[date]" value="" class="form-date form-control">
    <!-- END OUTPUT from 'core/themes/stable9/templates/form/input.html.twig' -->
  </div>
  <!-- END OUTPUT from 'core/themes/stable9/templates/form/form-element.html.twig' -->
</fieldset>

If you want to support date and datetime exposed filter this module can alter the type attribute with date or datetime-local.
Browser then displays a widget for dates and dates with time inputs.

Support is here.
https://caniuse.com/input-datetime

What dou you think?

Steps to reproduce

  1. Install & enable the module
  2. Configure a view with a date exposed filter
  3. Compare the output between core and date_filter

Proposed resolution

Improve the filter plugins, that the HTML markup is a default form-element and just alter the type attribute of the input.

User interface changes

Change from fieldset to the core default field-element.

🐛 Bug report
Status

Active

Version

1.0

Component

Code

Created by

🇩🇪Germany sunlix Wesel

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @sunlix
  • Status changed to Postponed: needs info about 1 month ago
  • Comment about 1 month ago →
    🇨🇦Canada joelpittet Vancouver

    Thanks for reporting this. Could you clarify the underlying problem you’re trying to solve?

    The issue summary explains that the markup changes and that a fieldset is used instead of the core’s default form-element, but it’s not clear what the impact of that change is. For example:

    1. Is the concern mainly visual consistency?
    2. Does the current structure break theming or accessibility?
    3. Are there usability issues with the new layout or behavior?

    It would also help to explain how your proposed solution—using type="date" or datetime-local" while keeping the core markup—addresses that problem.

    If possible, screenshots of the current vs. expected output or examples of where the new markup causes issues would make the case stronger.

    Thanks!

    Also note this issue may change the markup, depending on the outcome 🐛 Undefined array key "#type" in Drupal\Core\Form\FormHelper Active

  • Comment 12 days ago →
    🇩🇪Germany sunlix Wesel

    Hey Joel,

    thank you for your questions.
    My personal feeling was only about the visual consistency. In the moment I tried this module my expectation was to get date / datetime filter with the usage of the webstandards type attribute.
    As I saw that the module adds a additional fieldset element my theme broke, because it did not expect a fieldset in the views filter section.

    In the direct comparision above, the fieldset looks unnecessary. I didn't digged in to get a "why" the fieldset is there but maybe you have a clarification? :)

  • Comment 11 days ago →
    🇨🇦Canada joelpittet Vancouver

    It shouldn't add a fieldset actually, I see you have twig debug turned on in your issue summary comments, could you add the comments for which template is loaded for the wrapper that includes the fieldset?

    My guess is a theme is overriding datetime_wrapper, but not totally sure without that context. Thanks for following up.

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024