password and password_confirm children do not pick up #states or #attributes

Can we add steps to the issue summary (part of standard issue template) since this is a bug report.

IS updated.

The Needs Review Queue Bot → tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

1) Drupal\FunctionalJavascriptTests\Core\Form\JavascriptStatesTest::testJavascriptStates
Behat\Mink\Exception\ResponseTextException: The text "Enter password" appears in the text of this page, but it should not.
/builds/issue/drupal-1427838/vendor/behat/mink/src/WebAssert.php:907
/builds/issue/drupal-1427838/vendor/behat/mink/src/WebAssert.php:312
/builds/issue/drupal-1427838/core/tests/Drupal/FunctionalJavascriptTests/Core/Form/JavascriptStatesTest.php:234
/builds/issue/drupal-1427838/core/tests/Drupal/FunctionalJavascriptTests/Core/Form/JavascriptStatesTest.php:67
FAILURES!
Tests: 1, Assertions: 92, Failures: 1.

Ran the test-only feature which generated the above, showing the test coverage

Summary appears to be complete.

Code review solution seems simple and accomplishes the issue.

LGTM

@sukr_s, thanks for working on an older issue!

I read the issue summary, comments and the MR. There are no unanswered questions.

I left a comment in the MR asking for a comment to be changed. The title here needs to be updated because it refers to 'password' but the MR makes no changes to password, only to password_confirm. Both of those should be simple to complete.

- Changed the title.
- Couldn't locate the MR comment. Nevertheless added a comment at the place of change.

Going to RTBC because title has been updated.

@quietone I'm not seeing the comment either did it not save?

No, I did not submit my earlier comment. I have done so now.

@sukr_s, thanks for figuring out what I meant.

I discussed this with @tim.plunkett and we agreed that adding another check on render element ID is probably not the best way forward. Instead we could do what the comment says and check if the element accepts input but has no markup. So something like

$key = (isset($elements['#markup']) && $elements['#markup'] === '' && isset($elements['#input']) && $elements['#input'] === TRUE) ? '#wrapper_attributes' : '#attributes';

This way anything in contrib will be fixed as well. We will need update the docs here to...

updated as per #32

Verified test coverage is still there https://git.drupalcode.org/issue/drupal-1427838/-/jobs/2949098

Appears feedback from @alexpott and @tim.plunkett has been addressed I believe.

Committed and pushed 36b2bfae686 to 11.x and a63415bb33f to 11.0.x and 4ba08a0254e to 10.4.x and 4951a71170f to 10.3.x. Thanks!

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

Hi! I have the following code that used to work fine but now it breaks after this has been deployed. Basically I have a form with a list of items that look something like this:

<?php
$address_list = [];
foreach($address as $id) {
  $address_list[$id] = [
    '#type' => 'item',
    '#markup' => '...',
    '#states' => [
      'visible' => [
        ':input[id="some_select"]' => ['value' => $id],
      ]
    ]
  ];
}
$form['addresses'] = $address_list;
?>

This used to work fine before this patch. When you selected an option in the select it would display one of these items which have information related to the selection. I've identified the issue and have verified that this fix is breaking the previous code but I have no clue why when the data-drupal-states is set in the #attributes it works but not in the `#wrapper_attribtues`. Any help? Is there something wrong with the way I'm using the #states? Heelp🙏

@cesarmiquel yeah, I have that exact issue. The logic that was changed in this issue is incorrect. I've raised 🐛 States are processed and added to the wrong attribute since #1427838 Active to discuss and fix that.

Thanks @steven-jones for your feedback. I will follow this new issue then. Do you know of a workaround for this to work in the meantime?

@cesarmiquel you can apply the changes from the MR in 🐛 States are processed and added to the wrong attribute since #1427838 Active :)

@steven-jones unfortunately not easily because the site is a multi-site Drupal and I don't have the ability to patch the Drupal Core. I might be able to request a patch but it will take a while (probably a week or maye more **if** they approve it) for them to patch it so I need to find a work around.