Undefined index: #parents FormState.php

I've also run into this error when using inline_form_errors with elements such as html_tag or container. This patch fixed the issue for me as well.

also works for me!

hopefully tag will help gain attention.

This could use some automated tests.

Curious about the steps to reproduce this one, could you expand on that in the issue summary?

For my case: error has appeared after #after_build using in a custom module.

True MODULE name starts with 'b' --> after_build is being used instead of alter module weights in order to change form labels..

other active contrib modules (with related form alters)

• email_registration -- this mod also alter labels, thus using afterbuild
• force_password_change
• password_toggle
• simple_pass_reset

/**
 * Implements hook_form_FORM_ID_alter().
 */
function MODULE_form_user_login_form_alter(&$form, FormStateInterface $form_state, $form_id) {
  $form['#after_build'][] = '_MODULE_user_login_form_setup';
}


function _MODULE_user_login_form_setup($form, FormStateInterface $form_state) {
  $form['#attributes']['class'][] = 'auth-form';
  $form['name']['#title'] = t('Enter your email address');
  $form['name']['#description'] = NULL;
  $form['actions']['submit']['#value'] = t('Reset password');
  $form['#attached']['library'] = [];
  $form['#attached']['library'][] = 'MODULE/reset_pwd_auth';
  $form['form_title'] = [
    '#type' => 'html_tag',
    '#tag' => 'h1',
    '#value' => t('Reset your password'),
    '#weight' => -1000,
    '#attributes' => [
      'class' => [ 'form-title' ]
    ]
  ];

  return $form;
}

The patch in #2 worked fine. About the #10, I confirm it appears using #after_build in a custom module, in my case I used for user registration.

Done this patch on Drupal 8.8.x-dev

Setting back to needs work as this still needs test coverage, but I may have something that will help move that along.

The patch I added to #3076171: Provide a new library to replace jQuery UI autocomplete will fail \Drupal\Tests\comment\Functional\CommentAnonymousTest::testAnonymous unless I also apply the patch from #13

The attached patch does not have #13 applied, so it can be used as a reference to help create a failing scenario in a test.

"without yalls"? :D

patch in #14 has nothing to do with this issue. look like it's from the switch JQ autocomplete to awesomplete.

#16

patch in #14 has nothing to do with this issue. look like it's from the switch JQ autocomplete to awesomplete.

The patch provided in #14 creates a condition that fails unless the patch from #12 in this issue is applied. Since this issue doesn't currently have steps to reproduce or tests (which it needs before it can be committed), I thought that it may be helpful to have that as a reference. Perhaps there are already tests and steps to reproduce on on the way and this is not helpful.

i do hear what you mean to provide but that.. but, if you comfortable with the test framework could you provide the test for that instead?

i know: starting with a test -- it's crazy (:

patch 12 resolves my issue, developing safedelete module to check for references (linkit links) before deleting or archiving content, adding an error to the node form by using setError , the form is modified by another module called entity_translation_unified_form

patch 12 takes care of the noise about "#parent"

Patch #12 makes the warning disappear properly

I'm getting this issue with Drupal Commerce/Address and the patch in #12 does not fix the issue.

Steps to reproduce

1. Install a basic Commerce setup. Use Commerce Stripe as the payment module.
2. Configure the billing Profile to only take a postal code.
3. Put a product in the card and go to checkout.
4. On the checkout form, enter an incorrect zip code and press to confirm the order.

The page will be flooded with errors like this:

Warning: Invalid argument supplied for foreach() in Drupal\Core\Form\FormState->getError() (line 1112 of core/lib/Drupal/Core/Form/FormState.php).

!empty() does not prevent the notice for me. This patch uses isset() instead.

The patch at #12 fixes the issue for me on an install of D9.1.2 when validating commerce address fields, which have been modified via an #after_build callback.

However it does not fix what appears to be the same issue when validating commerce_stripe card fields. The patch at #25 does not fix that either.

The patch in #12 is the same as in #2.

Though only the patch from #25 with the isset() fixed it for me.

The same warning when using Multiple Registration module but patch from #12 works. Thx.

Per the tag this still needs test coverage.

Hey Everyone,

It looks like this happens when a form alter adds elements to the form during #after_build hooks as mentioned above. Manipulating existing elements does not cause any issues because `#parents` are already set for elements defined during the initial build. Here are 2 patches (fail/pass) to hopefully move this issue along. I'm happy to make adjustments to these as necessary since I don't have any core commits yet ;)

PHPCS!

I'll investigate the 17 failures above :(

In the meantime, it looks like anywhere the following code is executed could be problematic (7 core instances). We need to determine if `#parents` should always exist, or if we should check the existence of it before performing array operations on it.

implode('][', $element['#parents'])

Related. #3150967

Here's an updated patch that should pass. I'm not sure why my approach (isset or !empty at beginning of function) fails test because I can't tell the difference. Anyway, the approach in #25 passes, so we'll stick with that!

Tested patch #38 on Core 9.2.6 in a Form API with Address module and it's working fine.

Nicely done @andyg5000

might be helpful to provide a tests-only patch to confirm that core fails without the fix.

Confirming patch #38 is working on Core 9.2.6 with Address module enabled.

weird I don't see the RTBC status after NR status, just going to set it to NR, then RTBC.

RTBC patch 38

Comment #40 was unpublished for some reason.

Had a couple tweaks to make, so I did it in an MR.

This fix feels odd. Elements added in after build not only lack #parents they also lack #array_parents, #tree, #weight and lots of other stuff added by \Drupal\Core\Form\FormBuilder::doBuildForm(). Do we need to improve the documentation in \Drupal\Core\Form\FormBuilderInterface::doBuildForm() about added new elements there as I can imagine it is quite easy to break things?

Also going to comment on the MR.

This branch from the merge request 1300 still applies cleanly to 9.3.x and 9.4.x

https://git.drupalcode.org/project/drupal/-/merge_requests/1300.diff

Confirming patch #38 is working on Core 9.4.2 with Address module enabled.

The current patch fixes FormState::getError(), but I think a similar problem exists for FormState::setError(). This can be triggered by address field in the same way. Keep ajax-switching the country to/from something that doesn't have one of the displayed address fields and you'll get there.

A simple $element['#parents'] guard condition in setError() also fixes this, but makes me nervous as per #50 and #37.

I have the same issue also when trying to upload media through the media library pop up and with empty Alternative text

I have the same issue also when trying to upload media through the media library pop up and with empty Alternative text

This issue surfaced for me after updating a site to PHP8. I think the issue pre-existed but was harmless in php7.4

The patch in #57 applies cleanly and solves the issue. It also triggers what would be the error state in tests.

So long as the tests pass, I can't see a reason why this is not good to go.

The test coverage from the MR has been removed from the latest patches. #57 claims the patch will trigger an error in tests but I can't see how. Happy to be wrong.

FWIW the MR still applies to 10.1.x and can be rebased on 9.5.x so we really should be using the MR and not adding new patches to an issue.

We also encountered this error after updating core to 9.5.10 and PHP 8.1. I don't remember seeing the error with PHP 8.0.

In our case we seem to get two different warnings:

Warning: Undefined array key "#parents" in Drupal\Core\Form\FormState->getError() (line 1137 of /var/www/html/builds/2023-09-19.10-55-49.tag--0.0.47__db59b9ce6/web/core/lib/Drupal/Core/Form/FormState.php)
 
Warning: foreach() argument must be of type array|object, null given in Drupal\Core\Form\FormState->getError() (line 1137 of /var/www/html/builds/2023-09-19.10-55-49.tag--0.0.47__db59b9ce6/web/core/lib/Drupal/Core/Form/FormState.php) 

I created a new branch and MR 5230 for 11.x. This branch also addresses the 2 threads on the original MR 1300:

1. "The point of the test is to prove there is no notice - so this name is a bit odd." by @alexpott
   • The class was renamed to "FormAfterBuildTest".
2. "It doesn't trigger a notice any more - right? Is the error handler approach necessary here? I think it's not - we'd error if there was a notice as far as I know." by @alexpott
   • The test was updated to catch any errors when the form is submitted instead of using an error handler.

hiding outdated patches

Attached is a static patch of the MR 5230 at commit 2c405b97. This can be used for consistent composer builds.

Rebased and ran test-only feature for MR 5230. https://git.drupalcode.org/issue/drupal-3027240/-/jobs/272556

They passed when they should have failed.

@smutsgrave I suspect it is how you are testing the "test only". The changes in core/modules/system/tests/modules/form_test/form_test.module are needed for the test but the job https://git.drupalcode.org/issue/drupal-3027240/-/jobs/272556 is reverting that change (see screenshot attached).

attached is a tests only patch of MR5230 at commit 2c405b97. This should fail.

Thanks for the test-only patch. It indeed does show the failure so removing the tests tag.

Change seems fine and hate to do it but could the issue summary be updated also. Solution "Apply patch" isn't a real solution description and could be kicked back just for that. Issue summary is to help the committer understand the issue and what the fix is.

Thanks!

Thanks!

I'm triaging RTBC issues. I read the IS and the comments.

I think the following still need to be answered
#50
#37
and are mentioned in #55 as a point of concern.

I am setting to needs work for those items.

FWIW - I managed to stumble in here while trying to add an error to an #type => 'item' FAPI element. My particular case (heavy in custom code territory) is that I have a third party javascripty thing (reCAPTCHA) that needs to block form submit in certain cases.

$element['error'] = [
  '#type' => 'container',
  'recaptcha_error_message' => [
    '#type' => 'item',
    '#markup' => ''
  ]
];

// Sometime later...

$form_state->setError($element['error']['recaptcha_error_message'], $error);

I wonder -- are there certain FAPI element types that simply weren't intended to support error messages associated with them?