Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Problem/Motivation
PHP Notice logged when switching "Configuration type" with already selected "Configuration name" in single configuration export screen at /admin/config/development/configuration/single/export.
The PHP Notice in all its "glory":
Notice: Undefined index: #value in template_preprocess_textarea() (line 389 of /web/core/includes/form.inc)
#0 /web/core/includes/bootstrap.inc(312): _drupal_error_handler_real()
#1 /web/core/includes/form.inc(389): _drupal_error_handler()
#2 /web/core/lib/Drupal/Core/Theme/ThemeManager.php(287): template_preprocess_textarea()
#3 /web/core/lib/Drupal/Core/Render/Renderer.php(436): Drupal\Core\Theme\ThemeManager->render()
#4 /web/core/lib/Drupal/Core/Render/Renderer.php(449): Drupal\Core\Render\Renderer->doRender()
#5 /web/core/lib/Drupal/Core/Render/Renderer.php(201): Drupal\Core\Render\Renderer->doRender()
#6 /web/core/lib/Drupal/Core/Render/Renderer.php(145): Drupal\Core\Render\Renderer->render()
#7 /web/core/lib/Drupal/Core/Render/Renderer.php(578): Drupal\Core\Render\Renderer->Drupal\Core\Render\{closure}()
#8 /web/core/lib/Drupal/Core/Render/Renderer.php(146): Drupal\Core\Render\Renderer->executeInRenderContext()
#9 /web/core/lib/Drupal/Core/Render/MainContent/AjaxRenderer.php(66): Drupal\Core\Render\Renderer->renderRoot()
#10 /web/core/lib/Drupal/Core/Form/FormAjaxResponseBuilder.php(89): Drupal\Core\Render\MainContent\AjaxRenderer->renderResponse()
#11 /web/core/lib/Drupal/Core/Form/EventSubscriber/FormAjaxSubscriber.php(109): Drupal\Core\Form\FormAjaxResponseBuilder->buildResponse()
#12 [internal function]: Drupal\Core\Form\EventSubscriber\FormAjaxSubscriber->onException()
#13 /web/core/lib/Drupal/Component/EventDispatcher/ContainerAwareEventDispatcher.php(142): call_user_func()
#14 /vendor/symfony/http-kernel/HttpKernel.php(219): Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch()
#15 /vendor/symfony/http-kernel/HttpKernel.php(91): Symfony\Component\HttpKernel\HttpKernel->handleThrowable()
#16 /web/core/lib/Drupal/Core/StackMiddleware/Session.php(57): Symfony\Component\HttpKernel\HttpKernel->handle()
#17 /web/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(47): Drupal\Core\StackMiddleware\Session->handle()
#18 /web/core/modules/page_cache/src/StackMiddleware/PageCache.php(106): Drupal\Core\StackMiddleware\KernelPreHandle->handle()
#19 /web/core/modules/page_cache/src/StackMiddleware/PageCache.php(85): Drupal\page_cache\StackMiddleware\PageCache->pass()
#20 /vendor/asm89/stack-cors/src/Asm89/Stack/Cors.php(49): Drupal\page_cache\StackMiddleware\PageCache->handle()
#21 /web/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(47): Asm89\Stack\Cors->handle()
#22 /web/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(52): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle()
#23 /vendor/stack/builder/src/Stack/StackedHttpKernel.php(23): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle()
#24 /web/core/lib/Drupal/Core/DrupalKernel.php(716): Stack\StackedHttpKernel->handle()
#25 /web/index.php(19): Drupal\Core\DrupalKernel->handle()
#26 {main}
Steps to reproduce
- Go to
/admin/config/development/configuration/single/export - Select some value in the select dropdown "Configuration type"
- Select some value in the select dropdown "Configuration name"
- Select some other value in the select dropdown "Configuration type"
- PHP Notice happens
- Optional start of The Apocalypse
Proposed resolution
I think this is all caused by the select dropdown "Configuration name" not being "reset" to a "neutral/none" value when switching "Configuration type"
Remaining tasks
The regular ol' 4 P's:
Patch/create MR
Poke at patch (aka Review)
Push to latest dev-branch (aka Commit)
Party
User interface changes
API changes
Data model changes
Release notes snippet
| Comment | File | Size | Author |
|---|---|---|---|
| #30 | interdiff.3225381.24-30.txt | 696 bytes | mikelutz |
| #30 | 3225381-30.drupal.patch | 3.36 KB | mikelutz |
| #30 | 3225381-30-TEST-ONLY.drupal.patch | 2.69 KB | mikelutz |
Comments
Comment #2
SpokjeComment #3
SpokjeComment #4
SpokjeComment #5
SpokjeComment #6
larowlanI vaguely recall a similar issue from the early days of bugsmash
This may be a duplicate
Comment #7
larowlanAh that was #2577219: Single item configuration export form config_name does not have "- Select -" as it's first option
Comment #8
yivanov CreditAttribution: yivanov commentedHere's a patch for it https://www.drupal.org/project/drupal/issues/3226267
Comment #9
cilefen CreditAttribution: cilefen at Institute for Advanced Study commentedLee, is this then a duplicate of #2577219: Single item configuration export form config_name does not have "- Select -" as it's first option?
Comment #10
yivanov CreditAttribution: yivanov commented@cilefen, I don't think it's related, because right now the UI is not usable at all, whilst the change in the other issue thread is about having - Select - as first option for the Simple configuration option. The issue is 6 years old and marked as "Postponed", which clearly doesn't seem to solve the issue we have here soon.
I am attaching the small patch I made here as well in case you struggle like me to use the UI for config exports.
Comment #11
jrockowitz CreditAttribution: jrockowitz as a volunteer and at Webform module Open Collective, The Big Blue House commentedI think the notice that we are trying to fix is a regression triggered by #3084436: Config export field should be cleared when config type changes
I think we should address the regression and not change template_preprocess_textarea().
The attached patch fixes the regression.
Also the patch from #10 uses
!empty($element['#value'])which means a '0' won't be rendered because it is considered an empty string.@see https://stackoverflow.com/questions/4139301/0-as-a-string-with-empty-in-php
Comment #12
jrockowitz CreditAttribution: jrockowitz as a volunteer and at Webform module Open Collective, The Big Blue House commentedComment #13
longwaveLooks good to me.
Comment #14
larowlanIs there a way we can add a test for this to prevent it re-occurring?
Comment #15
jrockowitz CreditAttribution: jrockowitz as a volunteer and at Webform module Open Collective, The Big Blue House commentedI don't have the bandwidth to add the needed test coverage. Hopefully, someone can step in and help.
Comment #17
larowlanComment #18
larowlanClosed #3248747: Undefined index: #value in template_preprocess_textarea() as a duplicate
Comment #21
larowlanCrediting gcb who filed a duplicate with a patch
Comment #22
longwaveNW for a test.
Comment #23
SpokjeI don't see any way to get a failing test without #3228956: PHP notices are not detected for headless browser-triggered requests in FunctionalJavascript tests being committed.
Comment #24
mikelutzRan into this this week. It becomes a problem if you install devel and disable the standard drupal error handler by setting the error handler to none in the devel settings. PHP's handler prints the notice at the top of the ajax response, making the form unable to switch between configuration types at all, until I re-enabled drupal's error handler.
Which does lead to a possibly effective, if not ugly test for this. It still would be better to address ajax error handling in a JS test in a more global way though.
Comment #25
mikelutzwell pbbft.. must need to set display_errors and error_reporting to E_ALL too. It worked locally :-(
Comment #26
bensti CreditAttribution: bensti commentedi just get into this problem and i just uninstall devel and re enable after exporting my config view...
Comment #28
AdamPS CreditAttribution: AdamPS at AlbanyWeb commentedI confirm that if the error handler is set to None in devel settings, the single export page becomes unusable.
Nice try @mikelutz, but perhaps @Spokje is correct and it's impossible to create a test? In which case, should we create a patch with the single line change, excluding the tests? The patch is just a single line and seems safe, so hopefully the committers could commit it in these circumstances.
Comment #29
longwaveAgree that this is a one line trivial fix that is difficult to write a test for without adding a ton of additional code, hopefully core committers will let this one slide? Back to RTBC for #11.
Comment #30
mikelutzI want to try one more thing, probably won't work. If it doesn't work, I'll reupload #11 and put this back to RTBC. I think the change here is obviously correct, and if we can solve #3228956: PHP notices are not detected for headless browser-triggered requests in FunctionalJavascript tests then this and a few others like it will automatically be tested for, I'm mostly just curious at this point.
Comment #31
alexpottIdeally we could use WebDriverTestBase's ability to record JS errors but there is not one here - it's a PHP warning. We need to extend the ability of the js_testing_log_test to monitor the headers of AJAX responses and log any headers that start with
X-Drupal-Assertion-but that's for a different issue. Let's do #11. There is an existing issue - see #3228956: PHP notices are not detected for headless browser-triggered requests in FunctionalJavascript tests.Committed and pushed ddd29c4ca2 to 10.1.x and bc2efd7306 to 10.0.x and 03e037d86f to 9.5.x and b9532e75b0 to 9.4.x. Thanks!
Xpost with @mikelutz - I don't think doing something specific for this issue is the correct thing. Whilst #30 will work it doesn't tell you what the problem with the ajax request was so it's not a good test.
Comment #36
mikelutzNo argument from me, @alexpott. I don't think the test for this specific case is worth it, and mine was not ideal. It would be much better to do #3228956: PHP notices are not detected for headless browser-triggered requests in FunctionalJavascript tests for the general case, and I see no reason to wait on this fix for that issue, which would need to fix this error and half a dozen others to pass anyway. Glad to see the fix committed. Thanks!