Regression: Deprecation of `yaml_parser_class` setting in 10.3 breaks sites < 11.0

For the reasoning behind forcing the Symfony YAML parser see #3108309-36: Support Yaml::PARSE_CUSTOM_TAGS in \Drupal\Component\Serialization\YamlSymfony::decode → which let us implement e.g. 📌 Add support for tagged_iterator to YamlFileLoader Active in 10.3.x. PECL YAML does not allow arbitrary custom tags at parse time, they must be specified up front.

I appreciate the pointers to these issues re: the Symfony Yaml parser, however I don't see how this is pertinent to the issue of not being able to provide your own overridden config. This isn't a function of the PECL parser.

Are you saying that a "proper" deprecation dance isn't possible here?

The problem is if someone was using the PECL parser then it would error out when building the container if those new tags are used.

Are you using a custom extension of the Symfony parser? I guess we could enforce that the parent class is the Symfony base class, but allow the class to be overridden?

If you're using the PECL parser AND the extensions aren't supported, that's on you IMO.

I am only extending the Symfony parser to allow for functionality that is forthcoming in 📌 Allow parsing and writing PHP constants and enums in YAML files Needs work but I'd rather just keep my predictable code path and upgrade with 11.x than add another patch to core on my project. I think there's a case to be made also to maintain some sort of hook point for a custom parser for the reason that core might not always have the specific parser config (e.g., flags) you want.

It seems to me that this was removed, not deprecated, and this is a BC break in violation of our usual way of doing things. Seems to me that a deprecation should mean the existing functionality works in 10.x as much as possible. At the very least the deprecation should be re-cast as a breaking-change removal of functionality and not a deprecation, which it isn't right now.

Wondering if we can do something like MR!10048?

Just moving to NW as that MR seems to break all the tests.

I think this is okay to re-introduce. I'm not convinced this should be functionality we should support forever but breaking it in 10.3 was indeed a break so we could re-introduce in the way that @longwave is suggesting. OTOH @bradjones1 could maintain and apply the patch in 📌 Allow parsing and writing PHP constants and enums in YAML files Needs work using composer patches. It'd be great to land that.

I had never thought of overriding the yaml parser to provide actual functionality as opposed to just switching between symfony and pecl, looks harmless to bring it back like this.

OK, so the MR is updated for 10.5.x, it keeps the deprecation but allows this to honor BC.

I went back and forth on whether to propose "keeping" this functionality in D11, as some have noted here and elsewhere there are legitimate use cases for swapping in your own Yaml parser. I am only doing so to get functionality that will come in 📌 Allow parsing and writing PHP constants and enums in YAML files Needs work ... BUT this shouldn't have broken D10 sites to begin with and we need to fix that.

This looks good to go and should be merged back to 10.3.x

Committed and pushed 4a8aaa4a9ca to 10.5.x and ebba8e798f6 to 10.4.x and eb382d27768 to 10.3.x. Thanks!

There will be an out of band patch release in 10.3 this week to fix critical issues, so might as well squeeze this one in too.

longwave → closed merge request !10048

Yeah um.
Just updated the site core to 10.3.8 and BOOM.
Even commenting out the yaml settings all of my builds now white screen with errors via drush.

drush cr
PHP Fatal error:  Uncaught Error: Class name must be a valid object or a string in //drupal-root/docroot/core/lib/Drupal/Core/Serialization/Yaml.php:17
Stack trace:
#0 //drupal-root/docroot/core/lib/Drupal/Core/DependencyInjection/YamlFileLoader.php(427): Drupal\Core\Serialization\Yaml::decode()
#1 //drupal-root/docroot/core/lib/Drupal/Core/DependencyInjection/YamlFileLoader.php(75): Drupal\Core\DependencyInjection\YamlFileLoader->loadFile()
#2 //drupal-root/docroot/core/lib/Drupal/Core/DrupalKernel.php(1413): Drupal\Core\DependencyInjection\YamlFileLoader->load()
#3 //drupal-root/docroot/core/lib/Drupal/Core/DrupalKernel.php(971): Drupal\Core\DrupalKernel->compileContainer()
#4 //drupal-root/docroot/core/lib/Drupal/Core/DrupalKernel.php(515): Drupal\Core\DrupalKernel->initializeContainer()
#5 //drupal-root/docroot/core/includes/utility.inc(34): Drupal\Core\DrupalKernel->boot()
#6 //drupal-root/vendor/drush/drush/src/Commands/core/CacheRebuildCommands.php(70): drupal_rebuild()
#7 [internal function]: Drush\Commands\core\CacheRebuildCommands->rebuild()
#8 //drupal-root/vendor/consolidation/annotated-command/src/CommandProcessor.php(276): call_user_func_array()
#9 //drupal-root/vendor/consolidation/annotated-command/src/CommandProcessor.php(212): Consolidation\AnnotatedCommand\CommandProcessor->runCommandCallback()
#10 //drupal-root/vendor/consolidation/annotated-command/src/CommandProcessor.php(175): Consolidation\AnnotatedCommand\CommandProcessor->validateRunAndAlter()
#11 //drupal-root/vendor/consolidation/annotated-command/src/AnnotatedCommand.php(387): Consolidation\AnnotatedCommand\CommandProcessor->process()
#12 //drupal-root/vendor/symfony/console/Command/Command.php(326): Consolidation\AnnotatedCommand\AnnotatedCommand->execute()
#13 //drupal-root/vendor/symfony/console/Application.php(1096): Symfony\Component\Console\Command\Command->run()
#14 //drupal-root/vendor/symfony/console/Application.php(324): Symfony\Component\Console\Application->doRunCommand()
#15 //drupal-root/vendor/symfony/console/Application.php(175): Symfony\Component\Console\Application->doRun()
#16 //drupal-root/vendor/drush/drush/src/Runtime/Runtime.php(110): Symfony\Component\Console\Application->run()
#17 //drupal-root/vendor/drush/drush/src/Runtime/Runtime.php(40): Drush\Runtime\Runtime->doRun()
#18 //drupal-root/vendor/drush/drush/drush.php(139): Drush\Runtime\Runtime->run()
#19 //drupal-root/vendor/drush/drush/drush(4): require('...')
#20 {main}
  thrown in //drupal-root/docroot/core/lib/Drupal/Core/Serialization/Yaml.php on line 17
 [warning] Drush command terminated abnormally.

Fatal error: Uncaught Error: Class name must be a valid object or a string in //drupal-root/docroot/core/lib/Drupal/Core/Serialization/Yaml.php:17
Stack trace:
#0 //drupal-root/docroot/core/lib/Drupal/Core/DependencyInjection/YamlFileLoader.php(427): Drupal\Core\Serialization\Yaml::decode()
#1 //drupal-root/docroot/core/lib/Drupal/Core/DependencyInjection/YamlFileLoader.php(75): Drupal\Core\DependencyInjection\YamlFileLoader->loadFile()
#2 //drupal-root/docroot/core/lib/Drupal/Core/DrupalKernel.php(1413): Drupal\Core\DependencyInjection\YamlFileLoader->load()
#3 //drupal-root/docroot/core/lib/Drupal/Core/DrupalKernel.php(971): Drupal\Core\DrupalKernel->compileContainer()
#4 //drupal-root/docroot/core/lib/Drupal/Core/DrupalKernel.php(515): Drupal\Core\DrupalKernel->initializeContainer()
#5 //drupal-root/docroot/core/includes/utility.inc(34): Drupal\Core\DrupalKernel->boot()
#6 //drupal-root/vendor/drush/drush/src/Commands/core/CacheRebuildCommands.php(70): drupal_rebuild()
#7 [internal function]: Drush\Commands\core\CacheRebuildCommands->rebuild()
#8 //drupal-root/vendor/consolidation/annotated-command/src/CommandProcessor.php(276): call_user_func_array()
#9 //drupal-root/vendor/consolidation/annotated-command/src/CommandProcessor.php(212): Consolidation\AnnotatedCommand\CommandProcessor->runCommandCallback()
#10 //drupal-root/vendor/consolidation/annotated-command/src/CommandProcessor.php(175): Consolidation\AnnotatedCommand\CommandProcessor->validateRunAndAlter()
#11 //drupal-root/vendor/consolidation/annotated-command/src/AnnotatedCommand.php(387): Consolidation\AnnotatedCommand\CommandProcessor->process()
#12 //drupal-root/vendor/symfony/console/Command/Command.php(326): Consolidation\AnnotatedCommand\AnnotatedCommand->execute()
#13 //drupal-root/vendor/symfony/console/Application.php(1096): Symfony\Component\Console\Command\Command->run()
#14 //drupal-root/vendor/symfony/console/Application.php(324): Symfony\Component\Console\Application->doRunCommand()
#15 //drupal-root/vendor/symfony/console/Application.php(175): Symfony\Component\Console\Application->doRun()
#16 //drupal-root/vendor/drush/drush/src/Runtime/Runtime.php(110): Symfony\Component\Console\Application->run()
#17 //drupal-root/vendor/drush/drush/src/Runtime/Runtime.php(40): Drush\Runtime\Runtime->doRun()
#18 //drupal-root/vendor/drush/drush/drush.php(139): Drush\Runtime\Runtime->run()
#19 //drupal-root/vendor/drush/drush/drush(4): require('...')
#20 {main}
  thrown in //drupal-root/docroot/core/lib/Drupal/Core/Serialization/Yaml.php on line 17

How do I fix this?
I'll have to downgrade all my projects at this point to keep it stable.

What is yaml_parser_class set to?

This properly validates if the class even exists and loads correctly.

Even with this patch, disabling the yaml settings in both settings.php and or settings.local.php borks all of the 10.3.8 sites I manage.
White screens, apache errors.. Drush failure.. the works!

drush cr

In Container.php line 159:
                                                                                                                                                               
  You have requested a non-existent service "cache.backend.null". Did you mean one of these: "cache.backend.memory", "cache.backend.apcu", "cache.backend.php  
  "?                                                                                                                                                           
                                                                                       

Keeping the settings with this patch allows normal operation.

Here is the settings prior to the update:

settings.php

/**
 * Load services definition file.
 */
$settings['container_yamls'][] = $app_root . '/' . $site_path . '/services.yml';

/**
 * Override the default service container class.
 *
 * This is useful for example to trace the service container for performance
 * tracking purposes, for testing a service container with an error condition or
 * to test a service container that throws an exception.
 */
# $settings['container_base_class'] = '\Drupal\Core\DependencyInjection\Container';

/**
 * Override the default yaml parser class.
 *
 * Provide a fully qualified class name here if you would like to provide an
 * alternate implementation YAML parser. The class must implement the
 * \Drupal\Component\Serialization\SerializationInterface interface.
 */
# $settings['yaml_parser_class'] = NULL;

and local settings for my dev instance:

settings.local.php

/**
 * Enable local development services.
 */
$settings['container_yamls'][] = DRUPAL_ROOT . '/sites/development.services.yml';

If I comment out one or all the caching error appears.

@emptyvoid thank you patched from #21 worked

Had same issue WSOD with pretty much identical stack trace.

Opps sorry, the previous patch caught all of the core patches I maintain..
Rerolled with just the yaml snippet patch.

Are you sure there is nothing setting yaml_parser_class?

The only way I can reproduce this is by setting yaml_parser_class to an entirely invalid value, such as a non-empty array.

If I set it to an invalid class name then I get a useful error:

Fatal error: Uncaught Error: Class "Bad\Class" not found in /var/www/html/drupal/core/lib/Drupal/Core/Serialization/Yaml.php:17

I don't think we should fail silently if the setting is incorrect.

@longwave I tried completely removing line: # $settings['yaml_parser_class'] = NULL; from settings.php and it still WSOD, only until applying patch now from #24 do any of my sites work with 10.3.8, otherwise I have to pin to 10.3.7 or use the patch

I'm also a little confused? If # comments the option out, I would assume that meant it was inactive (as I have never changed or used this setting) I think it's finding the class from somewhere else as of 10.3.8 since 10.3.7? I also note that in the latest default has a message regarding it being deprecated in 10.3 and removed in 11. So if I wasn't using and also removed it after updating to 10.3.8 and still get the WSOD for the class. Shouldn't whatever the change was (from 10.3.7 to 10.3.8) account for that? I see this being a big problem for a lot of installs out there. If not what should that be set to to prevent a WSOD; yaml_parser_class = ?

The patch in #24 is the only thing that worked for me.

I also ran into this on 1 of 2 sites: (also shown above in comment #21) You have requested a non-existent service "cache.backend.null". Did you mean one of these: "cache.backend.memory", "cache.backend.apcu", "cache.backend.php
- Which was fixed after removing a $settings[] in the settings.php

$settings['cache']['bins']['render'] = 'cache.backend.null';
$settings['cache']['bins']['dynamic_page_cache'] = 'cache.backend.null';

- should anyone wonder where they originate; likely any cache setting configured that used cache.backend.null service (which I'm guessing that service was removed in 10.3.7 as I had that issue when I initial pinned to 10.3.7 when initially getting WSOD's) not 100% sure on that, just appears that way.

I'm unable to reproduce this on a fresh install without deliberately setting yaml_parser_class as per #25, so steps to reproduce this would be really helpful.

If people could apply the patch and clear caches and restart the webserver this would let us know what is in yaml_parser_class setting - there must be something otherwise it would not be failing.

This may be anecdotal, but I've noticed that only sites running on Acquia Cloud appears affected for me.
I'd have to do a full source code compare to determine how a vanilla source tree and one built on Acquia Cloud differ.
But source trees built and running on other platforms like Pantheon or a vanilla AWS stack seem fine.

A full source tree search on vanilla 10.3.8 shows:

/drupal-root/docroot/core/.deprecation-ignore.txt
# In Drupal 10, skip deprecations for the "yaml_parser_class" setting.      [position 52:44]
%The "yaml_parser_class" setting is deprecated in drupal:10.3.0. This setting should be removed from the settings file, since its usage has been removed. See https://www.drupal.org/node/3415489.%      [position 54:7]	

/drupal-root/docroot/core/assets/scaffold/files/default.settings.php	
# $settings['yaml_parser_class'] = NULL;      [position 736:14]	

/drupal-root/docroot/core/lib/Drupal/Core/Serialization/Yaml.php
    if ($class = Settings::get('yaml_parser_class')) {      [position 16:33]	

/drupal-root/docroot/core/lib/Drupal/Core/Site/Settings.php
    'yaml_parser_class' => [      [position 45:6]	
      'message' => 'The "yaml_parser_class" setting is deprecated in drupal:10.3.0. This setting should be removed from the settings file, since its usage has been removed. See https://www.drupal.org/node/3415489.',      [position 47:26]	

/drupal-root/docroot/sites/default/default.settings.php
# $settings['yaml_parser_class'] = NULL;      [position 736:14]	

On both 10.2 and 10.3.8 I can still only reproduce this by setting yaml_parser_class to something that isn't a string. In both cases if I set it to a string but for a class that doesn't exist I get a different "Class not found" error.

@sidgrafix are you on Acquia Cloud too? I am still curious what Settings::get('yaml_parser_class') returns on this platform, and why it has started failing here but doesn't on 10.2.

@longwave No none of my installs are on Acquia Cloud.

@sidgrafix, @emptyvoid: Can someone please run vendor/bin/drush ev "var_dump(\Drupal\Core\Site\Settings::get('yaml_parser_class'));" from the command line. We need to see what you have in that setting in order to understand why this is breaking.

@alexpott running drush ev "var_dump(\Drupal\Core\Site\Settings::get('yaml_parser_class'));" returns: bool(true)

Thought - could it be that at least in some cases this value was set to a PECL parser, which would be incompatible with 📌 Drop PECL YAML library support in favor of only Symfony YAML Fixed ? We would perhaps need a test/conditional to validate the provided class is a Symfony parser? That is the part of the BC layer here that we really can't provide without backing out the whole of the change that got us here, in the first place.

@alexpott and @bradjones1

With the patch from #29 I now get an error when navigating admin pages.

User warning: Class "1" does not exist. in Drupal\Core\Serialization\Yaml::decode() (line 20 of /var/www/html/web/core/lib/Drupal/Core/Serialization/Yaml.php)
#0 /var/www/html/web/core/includes/bootstrap.inc(166): _drupal_error_handler_real(512, 'Class "1" does ...', '/var/www/html/w...', 20)
#1 [internal function]: _drupal_error_handler(512, 'Class "1" does ...', '/var/www/html/w...', 20)
#2 /var/www/html/web/core/lib/Drupal/Core/Serialization/Yaml.php(20): trigger_error('Class "1" does ...', 512)
#3 /var/www/html/web/core/lib/Drupal/Core/Asset/LibraryDiscoveryParser.php(396): Drupal\Core\Serialization\Yaml::decode('drupal.dblog:\n ...')
#4 /var/www/html/web/core/lib/Drupal/Core/Asset/LibraryDiscoveryParser.php(157): Drupal\Core\Asset\LibraryDiscoveryParser->parseLibraryInfo('dblog', 'core/modules/db...')
#5 /var/www/html/web/core/lib/Drupal/Core/Asset/LibraryDiscoveryCollector.php(87): Drupal\Core\Asset\LibraryDiscoveryParser->buildByExtension('dblog')
#6 /var/www/html/web/core/lib/Drupal/Core/Asset/LibraryDiscoveryCollector.php(66): Drupal\Core\Asset\LibraryDiscoveryCollector->getLibraryDefinitions('dblog')
#7 /var/www/html/web/core/lib/Drupal/Core/Cache/CacheCollector.php(149): Drupal\Core\Asset\LibraryDiscoveryCollector->resolveCacheMiss('dblog')
#8 /var/www/html/web/core/lib/Drupal/Core/Asset/LibraryDiscovery.php(44): Drupal\Core\Cache\CacheCollector->get('dblog')
#9 /var/www/html/web/core/lib/Drupal/Core/Asset/LibraryDiscovery.php(58): Drupal\Core\Asset\LibraryDiscovery->getLibrariesByExtension('dblog')
#10 /var/www/html/web/core/lib/Drupal/Core/Asset/LibraryDependencyResolver.php(68): Drupal\Core\Asset\LibraryDiscovery->getLibraryByName('dblog', 'drupal.dblog')
#11 /var/www/html/web/core/lib/Drupal/Core/Asset/LibraryDependencyResolver.php(41): Drupal\Core\Asset\LibraryDependencyResolver->doGetDependencies(Array)
#12 /var/www/html/web/core/lib/Drupal/Core/Asset/LibraryDependencyResolver.php(87): Drupal\Core\Asset\LibraryDependencyResolver->getLibrariesWithDependencies(Array)
#13 /var/www/html/web/core/lib/Drupal/Core/Asset/AssetResolver.php(113): Drupal\Core\Asset\LibraryDependencyResolver->getMinimalRepresentativeSubset(Array)
#14 /var/www/html/web/core/lib/Drupal/Core/Asset/AssetResolver.php(128): Drupal\Core\Asset\AssetResolver->getLibrariesToLoad(Object(Drupal\Core\Asset\AttachedAssets))
#15 /var/www/html/web/core/lib/Drupal/Core/Render/HtmlResponseAttachmentsProcessor.php(323): Drupal\Core\Asset\AssetResolver->getCssAssets(Object(Drupal\Core\Asset\AttachedAssets), false, Object(Drupal\Core\Language\Language))
#16 /var/www/html/web/core/lib/Drupal/Core/Render/HtmlResponseAttachmentsProcessor.php(167): Drupal\Core\Render\HtmlResponseAttachmentsProcessor->processAssetLibraries(Object(Drupal\Core\Asset\AttachedAssets), Array)
#17 /var/www/html/web/core/lib/Drupal/Core/EventSubscriber/HtmlResponseSubscriber.php(45): Drupal\Core\Render\HtmlResponseAttachmentsProcessor->processAttachments(Object(Drupal\Core\Render\HtmlResponse))
#18 [internal function]: Drupal\Core\EventSubscriber\HtmlResponseSubscriber->onRespond(Object(Symfony\Component\HttpKernel\Event\ResponseEvent), 'kernel.response', Object(Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher))
#19 /var/www/html/web/core/lib/Drupal/Component/EventDispatcher/ContainerAwareEventDispatcher.php(111): call_user_func(Array, Object(Symfony\Component\HttpKernel\Event\ResponseEvent), 'kernel.response', Object(Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher))
#20 /var/www/html/vendor/symfony/http-kernel/HttpKernel.php(214): Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch(Object(Symfony\Component\HttpKernel\Event\ResponseEvent), 'kernel.response')
#21 /var/www/html/vendor/symfony/http-kernel/HttpKernel.php(202): Symfony\Component\HttpKernel\HttpKernel->filterResponse(Object(Drupal\Core\Render\HtmlResponse), Object(Symfony\Component\HttpFoundation\Request), 1)
#22 /var/www/html/vendor/symfony/http-kernel/HttpKernel.php(76): Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object(Symfony\Component\HttpFoundation\Request), 1)
#23 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/Session.php(53): Symfony\Component\HttpKernel\HttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#24 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(48): Drupal\Core\StackMiddleware\Session->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#25 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/ContentLength.php(28): Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#26 /var/www/html/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(106): Drupal\Core\StackMiddleware\ContentLength->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#27 /var/www/html/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(85): Drupal\page_cache\StackMiddleware\PageCache->pass(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#28 /var/www/html/web/modules/contrib/advban/src/AdvbanMiddleware.php(57): Drupal\page_cache\StackMiddleware\PageCache->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#29 /var/www/html/web/core/modules/ban/src/BanMiddleware.php(50): Drupal\advban\AdvbanMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#30 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(48): Drupal\ban\BanMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#31 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(51): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#32 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/AjaxPageState.php(36): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#33 /var/www/html/web/modules/contrib/remove_http_headers/src/StackMiddleware/RemoveHttpHeadersMiddleware.php(49): Drupal\Core\StackMiddleware\AjaxPageState->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#34 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/StackedHttpKernel.php(51): Drupal\remove_http_headers\StackMiddleware\RemoveHttpHeadersMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#35 /var/www/html/web/core/lib/Drupal/Core/DrupalKernel.php(741): Drupal\Core\StackMiddleware\StackedHttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#36 /var/www/html/web/index.php(19): Drupal\Core\DrupalKernel->handle(Object(Symfony\Component\HttpFoundation\Request))
#37 {main}

Not sure if that helps any..

@bradjones1 the Pecl yaml parser still works - I tested this already.

@sidgrafix where is yaml_parser_class set? It should never be a boolean - that would not have worked on 10.2.x - see #31.

@alexpott I don't have it set anywhere! I've never set it, other than seeing it available in settings.php where else would it be possible to set it?

If Acquia is injecting settings into settings.php (via environment variables, an include etc.), it could be set there.

@catch I don't use Acquia and just checked all custom theme and module files for any hooks that may be setting yaml_parser_class and cannot find anything injecting it. I also don't have any env's or includes and nothing in php ini configs.

Is it possible the setting was a default set by core on install back in Drupal 9.x somewhere and it wasn't updated/changed properly on existing installs during an update.

@sidgrafix can you do grep -R yaml_parser_class ./ on the Drupal root directory of the server where you are experiencing the problem.

@alexpott Appears to show up only in default expected locations and inactive!
grep -R yaml_parser_class ./ returns:

./web/sites/default/default.settings.php:# $settings['yaml_parser_class'] = NULL;
./web/sites/default/settings.php: # $settings['yaml_parser_class'] = NULL;
./web/core/assets/scaffold/files/default.settings.php:# $settings['yaml_parser_class'] = NULL;
./web/core/lib/Drupal/Core/Serialization/Yaml.php:    if ($class = Settings::get('yaml_parser_class')) {
./web/core/lib/Drupal/Core/Site/Settings.php:    'yaml_parser_class' => [
./web/core/lib/Drupal/Core/Site/Settings.php:      'message' => 'The "yaml_parser_class" setting is deprecated in drupal:10.3.0. This setting should be removed from the settings file, since its usage has been removed. See https://www.drupal.org/node/3415489.',
./web/core/.deprecation-ignore.txt:# In Drupal 10, skip deprecations for the "yaml_parser_class" setting.
./web/core/.deprecation-ignore.txt:%The "yaml_parser_class" setting is deprecated in drupal:10.3.0. This setting should be removed from the settings file, since its usage has been removed. See https://www.drupal.org/node/3415489.%

@sidgrafix well how does it get set to TRUE... there must be something somewhere setting it to TRUE. Is your settings.php including files from outside Drupal root?

@alexpott, nope it isn't set anywhere and I can honestly say I never set it for any reason on either of the installs with this issue. Both of which had been in development since Drupal 9.x

I'll try to dig into things deeper by looking back thru every Drupal release prior to see when the setting was original introduced into Drupal and see if I can figure out how a setting I've never used and likely others was set as a Boolean when clearly it should not be. My best guess is somewhere in Drupal release history the setting was used as a Boolean then changed and not properly removed or changed on installation of an update.

@sidgrafix These settings are not stored in the database - they are only configured in code through settings.php. And this setting has never been a boolean, since it was introduced in #1920902: Add a Drupal Yaml wrapper so we can default to PECL Yaml component if it is available → it's always been a string.

@alexpot

On my local dev the config setting is:

NULL

On Acquia Cloud it returns:

bool(true)

Pushed a very simple fix for people where this has been set to TRUE for whatever reason. Very odd and no idea how it worked on 10.2 but as this feature is removed in 11.x I think we can just be pragmatic and forget about this.

@alexpott

vendor/bin/drush ev "var_dump(\Drupal\Core\Site\Settings::get('yaml_parser_class'));"
/vendor/drush/drush/src/Commands/core/PhpCommands.php(32) : eval()'d code:1:
NULL

Drupal version : 10.3.5
PHP version : 8.3.13
Drush version : 12.5.3.0

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.

probably a false positive

Given the only cases in the wild that we know of are where it is somehow set to TRUE I think this is the pragmatic solution for now, this only needs to remain until Drupal 10 EOL so we have no maintenance concerns going forwards.

Would still love to know exactly how it is being set to TRUE in these environments!

Committed/pushed to 10.5.x and cherry-picked to 10.4.x and 10.3.x, thanks!

catch → closed merge request !10189

@catch, I'm a little confused! Was a fix not implemented and committed (#54) for Drupal 10.3.x?
I just updated to 10.3.9 and removed the patch from #24 and the issue still persists with WSOD! Had to put patch back in. Patch #24 is the only one that works without issues as well. If I use the patch for more info from #29 there is no WSOD however I get the same error repeated like 70+ times filling pages of logs with User warning: Class "1" does not exist. if I drush cr or drush updb.

@sidgrafix this week's releases only contained security fixes. Bug fix releases are scheduled for the first Wednesday of the month; this fix will be released in the first week of December.

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