Notice: Undefined index: #type in Drupal\Core\Form\FormHelper::processStates()

In my case this warning shows when in hook_form_alter I do something like:

$form['field_texto_cabecera']['#states'] = [
			    	'visible' => [
						'select[name="field_tipo_de_cabecera"]' => array(['value' => 'texto'], ['value' => 'image'], ['value' => 'video'], ['value' => 'slider'])
					]
				];

The patch works, but I need to patch the core everytime I update it. Is there another way to fix this without patching the core?

Recreation steps with contrib module smart_trim → :

1. Install standard profile, enable smart_trim module.
2. Create a test view showing page content.
3. Add the body field and in its formatter select Smart Trimmed.

The Browse available tokens link in newly generated More link section is generated based off the contrib token's token_tree_link theme. Because #themes do not require #type properties, this throws the undefined array key warning.

(This is also most likely reproduceable everywhere that formatter is placed, I just ran into it here.)

I just marked 🐛 FormHelper::processStates causes notices on type-less elements. Closed: duplicate as a duplicate of this issue.

I can confirm #147: with smart_trim module enabled, try to format a body field in views using smart_trim formatter and you get the error.
The error also occurs with several other modules. I'm not using them but I landed on their issues while seeking a solution to this error message. I set some of them for reference in "relationships".

Created a MR for smart_trim to resolve this by adding a '#type' key to the build. However it seems we should make it so if '#theme' is defined, '#type' should not be required.

https://www.drupal.org/project/smart_trim/issues/3451530#comment-15625318 🐛 Warning: Undefined array key "#type" in Drupal\Core\Form\FormHelper::processStates() Needs review

Re-rolled Patch from #133 against 11.x branch.

But there seems a test failure. Might not be related to this change. Test failure in https://git.drupalcode.org/issue/drupal-2700667/-/blob/2700667-notice-undefined-index/core/modules/file/tests/src/Functional/DownloadTest.php#L138

    1)
    Drupal\Tests\file\Functional\DownloadTest::testPrivateFileTransferWithoutPageCache
    Correctly denied access to a file when file_test sets the header to -1.
    Failed asserting that 200 is identical to 403.
    
    /builds/issue/drupal-2700667/core/modules/file/tests/src/Functional/DownloadTest.php:138
    /builds/issue/drupal-2700667/core/modules/file/tests/src/Functional/DownloadTest.php:76

  Error message
  Warning: Undefined array key "#type" in Drupal\Core\Form\FormHelper::processStates() (line 211 of core/lib/Drupal/Core/Form/FormHelper.php).
  Drupal\Core\Form\FormHelper::processStates(Array) (Line: 412)
  Drupal\Core\Render\Renderer->doRender(Array) (Line: 458)
  Drupal\Core\Render\Renderer->doRender(Array, ) (Line: 204)
  Drupal\Core\Render\Renderer->render(Array) (Line: 474)
  Drupal\Core\Template\TwigExtension->escapeFilter(Object, Array, 'html', NULL, 1) (Line: 44)
  __TwigTemplate_335c6caddc004ce5ce1cc6eb323c5a5a->doDisplay(Array, Array) (Line: 394)
  Twig\Template->displayWithErrorHandling(Array, Array) (Line: 367)
  Twig\Template->display(Array) (Line: 379)
  Twig\Template->render(Array, Array) (Line: 40)
  Twig\TemplateWrapper->render(Array) (Line: 53)
  twig_render_template('core/themes/claro/templates/node-edit-form.html.twig', Array) (Line: 372)
  Drupal\Core\Theme\ThemeManager->render('node_edit_form', Array) (Line: 445)
  Drupal\Core\Render\Renderer->doRender(Array, ) (Line: 204)
  Drupal\Core\Render\Renderer->render(Array, ) (Line: 238)
  Drupal\Core\Render\MainContent\HtmlRenderer->Drupal\Core\Render\MainContent\{closure}() (Line: 592)
  Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 231)
  Drupal\Core\Render\MainContent\HtmlRenderer->prepare(Array, Object, Object) (Line: 128)
  Drupal\Core\Render\MainContent\HtmlRenderer->renderResponse(Array, Object, Object) (Line: 90)
  Drupal\Core\EventSubscriber\MainContentViewSubscriber->onViewRenderArray(Object, 'kernel.view', Object)
  call_user_func(Array, Object, 'kernel.view', Object) (Line: 111)
  Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch(Object, 'kernel.view') (Line: 187)
  Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 76)
  Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 58)
  Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 48)
  Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 106)
  Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 85)
  Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 48)
  Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 51)
  Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 51)
  Drupal\Core\StackMiddleware\StackedHttpKernel->handle(Object, 1, 1) (Line: 704)
  Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

Steps to Reproduce :

Added a field visibility condition using `#states` API

  $form['body']['#states'] = [
      'visible' => [
        ':input[name="field_article_type"]' => ['value' => 14833],
      ],
    ];

    $form['field_local_video']['#states'] = [
      'visible' => [
        ':input[name="field_article_type"]' => ['value' => 14832],
      ],
    ];
   
 

Among the above fields

body --> Default Body Field

field_local_video --> Media Entity Reference Field

field_article_type --> Taxonomy term field.

Seems the test failure from #153 🐛 Notice: Undefined index: #type in Drupal\Core\Form\FormHelper::processStates() Needs work is a random error. Re-running test did not re-produce it.

Patch 2700667-133.test-only.patch works for me with a drupal 10.2.7 & php 8.2.x

We should be fixing the affected modules and not hiding the error - as explained quite a few times this message is the sign of something expected to work that's not going to work. "Fixing" the code in core results in less information not more and it being harder and not easier to fix.

So curious if you feel this should be closed WAD? Or the documentation should be updated to state that "#type" is required at all times even if you are using "#theme" which seems to be the main disconnect. (at least for me in smart_trim)

@markie note that it's not only for theme functions. You can also trigger this by creating a markup field (see test in the MR).

It just seems very redundant needing to specify an element like this

$form_element = [
      '#type' => 'markup',
      '#markup' => 'Custom markup',
      '#states' => [
        'visible' => [
          ':select[name="method"]' => ['value' => 'email'],
        ],
      ],
    ];

Over just leaving off the #type part. If we should be fixing that, this issue would need to update the documentation to properly specify that #type is always required.

@BramDriesen but that code does NOT actually work!

For the given form array

    $form['test'] = [
      '#type' => 'checkbox',
      '#title' => 'test',
    ];
    $form['blah'] = [
      '#type' => 'markup',
      '#markup' => 'Custom markup',
      '#states' => [
        'visible' => [
          ':input[name="test"]' => ['checked' => TRUE],
        ],
      ],
    ];
    $form['blah2'] = [
      '#type' => 'checkbox',
      '#title' => 'Blah 2',
      '#states' => [
        'visible' => [
          ':input[name="test"]' => ['checked' => TRUE],
        ],
      ],
    ];

only the Blah 2 checkbox with appear if the test checkbox is checked. The markup will always be present. As I've said before the system is trying to tell you that your expectations about what will work or not is incorrect and you need to fix the form array not this code.

moving to PNMI for answer to #158, if this should be rescoped to update documentation or closed as WAD.

This issue might already be fixed since the code has changed in 🐛 password and password_confirm children do not pick up #states or #attributes Active

#162 🐛 Notice: Undefined index: #type in Drupal\Core\Form\FormHelper::processStates() Needs work : +1

It looks that it was fixed here, indeed: https://git.drupalcode.org/project/drupal/-/commit/4951a71170fa78b46ca96...

It looks like the fix for issue #1427838 🐛 password and password_confirm children do not pick up #states or #attributes Active has been applied to the following branches: 10.3.x, 10.4.x, 11.0.x, and 11.x.

Can we confirm the resolution of this issue on those versions?

Yep looks fixed

Cross-referencing to fix.