Using #type => date_format more than once per page causes all elements to be updated instead of each individually

Created on 16 January 2019, over 5 years ago
Updated 6 October 2023, 8 months ago

Problem/Motivation

If you ever have an entity form that has multiple date formats on it, the slick JS from system.date.js assumes there's only ever a single format string on the page, and as you change any of the formats, the preview for all of them is updated immediately.

Posting this as a follow-up from #2429443: Date format form is unusable β†’ since git blame points there. Calling it a "config_translation" bug, since that's where it's most visible, but maybe it's more accurately a bug in system.module since I think the real problem is in system.date.js.

Over at #3023808: Allow date range formats to be translatable β†’ I'm trying to make a config entity translatable. These entities include multiple date format strings within each config entity. I changed the config schema like so:

         default_pattern:
-          type: string
+          type: date_format
           label: 'Default pattern'
...

So far, so good! Miraculously, it basically all just works, and now the date formats for these things are translatable. Yay!

However, the JS added at #2429443 assumes there's only ever a single format on the page. So when you change any of the formats, all of their "Displayed as" sample text is immediately updated to the same thing. This is really confusing and weird. ;)

I then tried to extend the default entity form for this config entity, so I could see the JS slickness on the original config entity. I added this to each of my format fields:

    $form['date']['basic']['default_pattern'] = [
      '#type' => 'textfield',
      '#title' => $this->t('End date pattern'),
      '#default_value' => $date_settings['same_month_end_pattern'] ?: '',
      ...
      '#attributes' => [
        'data-drupal-date-formatter' => 'source',
      ],
      '#field_suffix' => ' <small class="js-hide" data-drupal-date-formatter="preview">' . $this->t('Displayed as %date_format', ['%date_format' => '']) . '</small>',
    ];

I added this to the form itself:

    $form['#attached']['library'][] = 'system/drupal.system.date';
    $form['#attached']['drupalSettings']['dateFormats'] = $this->dateFormatter->getSampleDateFormats();

Although it sort of works, the JS still can't untangle this, and any change to any field updates the preview on all the others.

Looking at system.date.js, it doesn't seem to have any provision for only operating on a single pair of fields at a time. It seems to attach itself to anything using the magic data-drupal-date-formatter attribute. Maybe I'm being dumb, but I don't see a way to get that function to do anything without using these attributes.

Proposed resolution

Not entirely sure. Fix the JS so that it's using a unique ID of some sort so changing the value in one field only updates the sample output for that particular field.

Remaining tasks

  1. Actually debug the problem.
  2. Write JS tests to show it?
  3. Write a patch that fixes it.
  4. Review.
  5. Commit.

User interface changes

Fix UI bug when you happen to be translating a config entity with multiple date_format fields.
Actually, the config_translation piece just seems to make it worse. It's still visible on the untranslated entity form if you try to re-use system.date.js.

API changes

Hopefully none. TBD.

Data model changes

Probably none. TBD.

πŸ› Bug report
Status

Postponed: needs info

Version

11.0 πŸ”₯

Component
SystemΒ  β†’

Last updated 1 day ago

No maintainer
Created by

πŸ‡ΊπŸ‡ΈUnited States dww

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

Comments & Activities

Not all content is available!

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

  • πŸ‡¦πŸ‡ΊAustralia acbramley

    I tried to follow the steps in #3 to reproduce this but couldn't the translate screens for date formats only ever display a single field.

    The JS has changed quite a bit as well since #4 but it sort of looks like the bug may still exist.

    Postponed on getting functional steps to reproduce from a fresh install.

Production build 0.69.0 2024