Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
Problem/Motivation
The report detects if $config_directories is used in the settings.php file (see #3154341) but the warning doesn't disappear after this is fixed.
Projects can't be scanned while that warning is there, so the user can't continue preparing the site for an upgrade.
Steps to reproduce
- Install a Drupal 8 site and use the deprecated
$config_directories
in the settings.php file to set where the config directory is. - Add a custom module to be scanned by the Upgrade Status module.
- Install and enable the Upgrade Status module.
- The report correctly warns you that Deprecated configuration is used is settings.php (see screenshot at #3154341).
Scanning of the custom module is not possible, due to this incompability. - Replace $config_directories with $settings['config_sync_directory'] in the settings.php file. Save, run drush cr, reload the report page etc.
- Check the report page: The warning is still there, and the environment is listed as incompatible
scanning projects is not possible.
(Update: The inability to scan projects was caused by another problem with a vendor directory - even though that also seem to have persisted after it was fixed.)
Comments
Comment #2
Gábor HojtsyThe 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?
Comment #3
jonathan_hunt CreditAttribution: jonathan_hunt at Catalyst IT commentedI 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 hadconfig_directories
defined.Comment #4
bdhoundus CreditAttribution: bdhoundus commentedI 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.
Comment #5
alisonTL;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:
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:
Comment #6
Venkatesh Rajan.J CreditAttribution: Venkatesh Rajan.J as a volunteer and commentedSubscribing.
Having the same issue after upgrading to 8.x-3.8.
Comment #7
quimicI confirm I have the same issue. The warning does not go away, in spite of correct syntax in settings.php
Comment #8
ifrikComment #9
Gábor HojtsyHm, 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...Comment #10
ifrikThe inability to scan projects seem to have been caused by another problem, but for some reason also persisted after fixing it. However, I can't reproduce it now myself.
The site uses version 8.9.16 of core-recommended and core-dev, and Devel module is uninstalled.
Comment #11
Gábor HojtsyDoh, 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.
Comment #13
Gábor HojtsyComment #14
ifrikThank you!
Comment #15
Gábor HojtsyInstead 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.