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.)

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Comments

ifrik created an issue. See original summary.

Gábor Hojtsy’s picture

Status: Active » Postponed (maintainer needs more info)

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?

jonathan_hunt’s picture

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.

bdhoundus’s picture

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.

alison’s picture

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
Venkatesh Rajan.J’s picture

Subscribing.

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

quimic’s picture

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

ifrik’s picture

Issue summary: View changes
Gábor Hojtsy’s picture

Status: Postponed (maintainer needs more info) » Needs work

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...

ifrik’s picture

The 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.

Gábor Hojtsy’s picture

Title: Warning about $config_directories deprecation is not getting resolved » Warning about $config_directories deprecation will never get resolved, roll it back
Status: Needs work » Reviewed & tested by the community

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.

  • 0612ab4 committed on 8.x-3.x
    Issue #3224551 by ifrik, Gábor Hojtsy, jonathan_hunt, bdhoundus,...
Gábor Hojtsy’s picture

Status: Reviewed & tested by the community » Fixed
ifrik’s picture

Thank you!

Gábor Hojtsy’s picture

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.

Status: Fixed » Closed (fixed)

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