Contrib.social

[PP-1] #states attribute does not work on #type datetime

Open on Drupal.org →
Created on 3 February 2015, about 10 years ago
Updated 10 June 2024, 8 months ago

Problem/Motivation

#states do not work with 'datetime' form elements:

  • Toggling visibility of the form element fails since there's no wrapper container to target.
  • Trying to toggle disabled fails since we can't find the nested form elements to disable.
  • Trying to toggle "required" fails since we can't find the label to add the right class(es) to.
  • ...

Proposed resolution

Remaining tasks

  1. Land 🐛 Datetime and Datelist elements should render as fieldsets Needs work
  2. Complete. See comments #91-102
  3. Update code and tests once #3078334 is in
  4. Markup review of all the changes to the datetime-wrapper twig templates:
    • System module's default temple - Fixed, but needs final approval.
    • Classy - Decided to leave broken. See #122.
    • Stable - Decided to leave broken. See #122.
    • Bartik - Fixed in #136 - can we do this?
    • Seven - Fixed in #136 - can we do this?
    • Claro - Fixed in #136 Yes. From #admin-ui Slack meeting 2019-11-06: @lauriii "We can make changes to Claro 🎉"
  5. JavaScript review of the changes to core/misc/states.es6.js.
  6. Other reviews + manual testing (optional).
  7. Decide if we can backport to 8.7.x (if so, working patch in #139).
  8. RTBC
  9. Commit.
  10. Unblock child issues.

User interface changes

#states actually works on datetime form elements.

Changes to the datetime-wrapper.html.twig templates (default templates from system and both the classy and stable themes) to:

  • Actually include a wrapper div (!)
  • (Now the responsibility of #3078334.

API changes

None.

Data model changes

None.

Original Report

While trying to create a custom field widget containing a "datetime" form element, I discovered that the #states attribute does not work on it.

Some states can be achieved with a workaround: put the datetime element in a container, and put the #states on the container. But this is obviously no clean fix, and it doesn't work for all states. (Works for "visible" for example, but not for "required".)

I was not able to figure out why this is not working, but I noticed that there have been a lot of issues regarding the #states attribute in the issue tracker. Most of them for were for specific elements like submit buttons, select elements with multiple values, ...

🐛 Bug report
Status

Postponed

Version

11.0 🔥

Component
Theme  →

Last updated 1 day ago

Created by

🇧🇪Belgium bertramakers

Live updates comments and jobs are added and updated live.
  • Contributed project blocker

    It denotes an issue that prevents porting of a contributed project to the stable version of Drupal due to missing APIs, regressions, and so on.

  • Needs frontend framework manager review

    Used to alert the fron-tend framework manager core committer(s) that a front-end focused issue significantly impacts (or has the potential to impact) multiple subsystems or represents a significant change or addition in architecture or public APIs, and their signoff is needed (see the governance policy for more information). If an issue significantly impacts only one subsystem, use Needs subsystem maintainer review instead, and make sure the issue component is set to the correct subsystem.

Sign in to follow issues

Merge Requests

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024