Warning about $config_directories deprecation will never get resolved, roll it back

The form always checks the runtime $GLOBALS value for that config, so it will check it again. Your hosting environment may have backwards compatibility code to keep that setting alive even if its not normally set. Eg. ddev may have that config. We could make this check more flexible, but since I don't think this should affect any of the other functionality, I though we have some time to tinker with that.

Scanning projects should be entirely possible despite any environment issues found. How is it not possible?

I just updated an 8.9.16 site to Upgrade Status 3.8. I get the "Use of $config_directories in settings.php is deprecated. Use $settings['config_sync_directory'] instead." report even though $settings contains $settings['config_sync_directory'] and not $config_directories. e.g. grep -rn 'config_directories' web/sites/ returns nothing. AFAIK this site never had config_directories defined.

I too am seeing the same warning of "Use of $config_directories in settings.php is deprecated. Use $settings['config_sync_directory'] instead." after updating to Upgrade Status 3.8
My settings.php did have an active line defining "$config_directories['sync']". I modified that to "$settings['config_sync_directory']" using the same path definition, saved the file. When I check the Upgrade Status report, I still get the same message. I ran cron, flushed caches, and ran update.php but the message remains.
I don't have any custom modules on the site.

TL;DR: Same here!

-------
Since updating upgrade_status to 8.x-3.8, I'm getting this error on the upgrade status report in the "Drupal core and hosting environment" section:

Use of $config_directories in settings.php is deprecated. Use $settings['config_sync_directory'] instead.

This site has never had the old $config_directories syntax -- it's been $settings['config_sync_directory'] since it was created about a year ago.

But, it isn't preventing me from scanning my custom modules, it's just a persistent error on the upgrade status report.

-------
About me:

• Ubuntu 20.04 host system
• lando v3.1.4
• php 7.3
• Drupal 8.9.16

Subscribing.

Having the same issue after upgrading to 8.x-3.8.

I confirm I have the same issue. The warning does not go away, in spite of correct syntax in settings.php

Hm, it is set for BC on 8.9.x in the global. So I guess the best we can do is to check if the $settings one is not set yet or is not the same. But we cannot quite ensure people deleted their $config_directories. See https://git.drupalcode.org/project/drupal/-/blob/8.9.x/core/lib/Drupal/C... and https://git.drupalcode.org/project/drupal/-/blob/8.9.x/core/includes/boo...

Doh, if we look closely at https://git.drupalcode.org/project/drupal/-/blob/8.9.x/core/lib/Drupal/C... it is apparent that it copies the value both ways, so once that runs, we cannot tell if the setting was set or the global was set as both will be set. If they are different, $settings['config_sync_directory']; will prevail so they will also never be different. So we cannot really check this by merely looking at runtime values.

Better to send this back to the drawing board and roll back #3154341: Doesn't detect the $config_directories deprecation for now.

Sorry for the noise.

If you have ideas how to go about re-implementing this, I am reopening #3154341: Doesn't detect the $config_directories deprecation.

Instead of reopening that one, I opened #3224660: The Drupal 8 to 9 $config_directories deprecation is not detected and already proposed a new patch there. Needs manual testing. If some of you are interested in a viable fix, it would be great to get that tested and landed.