Regression on entity reference field states

Are there console errors? Be sure to test with the 10.2.x branch as there are JavaScript fixes on it.

There are no console errors and I have tested this with a clean 10.2.3-dev setup as well and the issue is present there too

+1. In my case, it's:

$form["submit"]['#states'] = [
        'disabled' => [
          ':input[name="file_upload[fids]"]' => ['empty' => TRUE],
        ],
      ];

it stopped working after upgrading to 10.2.2.

We're running into this issue ourselves.

Narrowed it down to the following line in core/misc/states.js changing from
const $states = $(context).find('[data-drupal-states]');
to
const elements = once('states', '[data-drupal-states]', context);
due to the the fix in
https://www.drupal.org/project/drupal/issues/3347144 🐛 Form API #states property/states should use .once() to apply its rules (Can cause failures with BigPipe and possibly other situations) Needs work

We have a temporary fix at the moment with a custom patch that changes
const elements = once('states', '[data-drupal-states]', context);
back to
const elements = $(context).find('[data-drupal-states]');

We're using this until someone comes up with a better patch.

This is one of those things where it would be nice for Drupal core maintainers to come up with JS contracts similar to the way they have developed Interface contracts for swappable Symfony services and public data members and functions.

We ran into a similar issue where we are dependent on Facets checkbox list selections to determine state of a form element on the page. The state logic lives on the form element, so every time Facets re-creates its blocks via AJAX we need to rerun the States API behaviors on the form element. This stopped working after the previously mentioned Core update to the States API.

Before

1. Page loads.
2. Form button is default disabled (becomes enabled if one of three Facets checkbox list blocks contains any checked elements).
3. Facets blocks initially loaded with list of links (Facets later transforms these to checkboxes in custom JavaScript https://git.drupalcode.org/project/facets/-/blob/2.0.x/js/checkbox-widge...).
4. Facet behavior checkbox JS runs and converts links into checkboxes for each checkbox widget block on page. Part off this behavior invokes Drupal.attachBehaviors for each instance of the converted Facet block, passing the Facets checkbox list block as the context, along with Drupal.settings.
5. In our custom JS, we have a behavior whose attach function looks at the context and determines if it was a facet checkbox list, and if it is then it re-runs Drupal.attachBehaviors() to ensure that the States API re-applies state information on the form element who has these checkbox value depenencies.

Workaround to account for new once usage in States API

Our workaround was to remove the added once attribute on the pertinent form element, which might be how this needs to be handled going forward.

1. Page loads.
2. Form button is default disabled (becomes enabled if one of three Facets checkbox list blocks contains any checked elements).
3. Facets blocks initially loaded with list of links (Facets later transforms these to checkboxes in custom JavaScript https://git.drupalcode.org/project/facets/-/blob/2.0.x/js/checkbox-widge...).
4. Facet behavior checkbox JS runs and converts links into checkboxes for each checkbox widget block on page. Part off this behavior invokes Drupal.attachBehaviors for each instance of the converted Facet block, passing the Facets checkbox list block as the context, along with Drupal.settings.
5. In our custom JS, we have a behavior whose attach function looks at the context and determines if it was a facet checkbox list, and if it is then it first removes the data-once value that was added to the form element, then it re-runs Drupal.attachBehaviors() to ensure that the States API re-applies state information on the form element who has these checkbox value dependencies.

I couldn't find a better, documented way to handle this situation. I feel at the very least the bugfix issue ( https://www.drupal.org/project/drupal/issues/3347144 🐛 Form API #states property/states should use .once() to apply its rules (Can cause failures with BigPipe and possibly other situations) Needs work ) could use a change record to indicate what changed and why it changed, and perhaps also document workarounds to account for the changes given the use-cases presented in this issue.

+1 for patch in #5.

Our form states were broken as well after upgrading to 10.2.2 today.

I've re-opened 🐛 Form API #states property/states should use .once() to apply its rules (Can cause failures with BigPipe and possibly other situations) Needs work to potentially roll it back.

Thanks for the reports. I've reverted 🐛 Form API #states property/states should use .once() to apply its rules (Can cause failures with BigPipe and possibly other situations) Needs work and re-opened that issue, closing this issue as fixed - we can continue on the bug found here over there. The revert will be included in the next 10.2.x patch release.

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

alexander tallqvist → made their first commit to this issue’s fork.

Still experiencing the same problem @thatguy described when running Drupal 10.3.2. The patch provided in #5 seems to fix the issue. Re-rolling the same patch for 10.3.2.