The Drupal 8 to 9 $config_directories deprecation is not detected

Hi Gabor,

Thanks very much for the patch.
Just tested it on:

• Drupal: 8.9.17
• Upgrade status: 8.x-3.8

Patch from #8 applied fine but I'm getting the following messages now:

Use of $config_directories in settings.php is deprecated. Use $settings['config_sync_directory'] instead.	Deprecated configuration used
Use of $config_directories in settings.php is deprecated.	Not used

 
See screenshot:

When I'm actually using the following in settings.php:

// Config sync directory.
$settings['config_sync_directory'] = '../config/sync';

With this code in settings.php, I would expect the warnings to be gone, or green, since this is what is recommended at:
The sync directory is defined in $settings and not $config_directories

Please let me know if there's anything I've been doing wrong or missed, in the config or the usage of the module.
Sorry, but I haven't had time to look further in code where the problem could come from.

Thanks in advance for your help.

Thanks a lot Gabor for your prompt and clear reply it's greatly appreciated.

I've tested again with your advice with the dev version: drupal/upgrade_status (dev-3.x 04edb37)
with the patch from #8, which applied nicely...

and it worked! See screenshot below:

Thanks a lot Gabor, once again.

As far as I'm concerned, this can be considered RTBC.

Same here! -- applied the patch from #8 to upgrade_status (drupal/upgrade_status:3.x-dev@dev) -- the $config_directories requirement on the upgrade status report page accurately lists a status of "✅ Not used" 🎉

The Dev Version has made the error message gone.

#10 -> #12

But I have a problem with the scan function. I already had that before.
see picture Scan button

The Button is not activated.

Thanks Lothar

I'm not sure if this was expected or not... but running ddev on my project and it has several different settings for settings.ddev.php that run if (version_compare) resulting in this being flagged twice.

// This specifies the default configuration sync directory.
// For D8 before 8.8.0, we set $config_directories[CONFIG_SYNC_DIRECTORY] if not set
if (version_compare(Drupal::VERSION, "8.8.0", '<') &&
  empty($config_directories[CONFIG_SYNC_DIRECTORY])) {
  $config_directories[CONFIG_SYNC_DIRECTORY] = 'sites/default/files/sync';
}
// For D8.8/D8.9, set $settings['config_sync_directory'] if neither
// $config_directories nor $settings['config_sync_directory is set
if (version_compare(DRUPAL::VERSION, "8.8.0", '>=') &&
  version_compare(DRUPAL::VERSION, "9.0.0", '<') &&
  empty($config_directories[CONFIG_SYNC_DIRECTORY]) &&
  empty($settings['config_sync_directory'])) {
  $settings['config_sync_directory'] = 'sites/default/files/sync';
}
// For Drupal9, it's always $settings['config_sync_directory']
if (version_compare(DRUPAL::VERSION, "9.0.0", '>=') &&
  empty($settings['config_sync_directory'])) {
  $settings['config_sync_directory'] = 'sites/default/files/sync';

For what it's worth, it may be good to tell upgrade status to ignore docker+ applications (lando, docksal, ddev, etc) to ignore managed php files.

Just for reporting, I'm having a similar issue as DYdave in #10. I just don't have the double message but only the "Use of $config_directories in settings.php is deprecated..." error. I'm also using ddev as laura.gates does.

Updating to the dev version fixed the issue.

BTW I think #20 is a good idea.

Updating from the 3.8.0 release to 3.x-dev@dev fixed the issue for me.
The upgrade status report page shows a status of "Not used"

Thanks!

Composer wouldn't install the dev version for me for some reason, so I rolled the following patch. This can be applied to the current release (8.x-3.8) until a new release with this fix and the rollback from https://www.drupal.org/project/upgrade_status/issues/3154341 is provided. This patch will roll back the previous fix and apply the fix from this issue.

This is causing a fatal error in some of our sites where we are using some anonymous functions in our settings.php to modify the $settings and $config objects, possibly due to re-loading the settings.php file on the same request.

So I think that system_requirements has a check for this as well, and it does not trigger this error for us when we load that page. It looks like it just checks the $GLOBALS variable without re-loading settings.php:

  // Handle other configuration directories. This will be removed in Drupal 9.
  // See https://www.drupal.org/node/3018145.
  $bc_config_directories = isset($GLOBALS['config_directories']) ? $GLOBALS['config_directories'] : [];
  unset($bc_config_directories['sync']);
  foreach (array_keys(array_filter($bc_config_directories)) as $type) {
    @trigger_error("Automatic creation of '{$type}' configuration directory will be removed from drupal:9.0.0. See https://www.drupal.org/node/3018145.", E_USER_DEPRECATED);
    ...

I don't think there's a need to even load the settings file again, we should be able to accomplish the same using $GLOBALS and the \Drupal\Core\Site\Settings class:

  protected function isDeprecatedConfigDirectorySettingUsed() {
    if (!empty($GLOBALS['config_directories'])) {
      if (Settings::get('config_sync_directory', FALSE)) {
        // Both are set. The $settings copy will prevail in Settings::initialise().
        return NULL;
      }
      // Only the deprecated variable is set.
      return TRUE;
    }

    // The deprecated variable is not set.
    return FALSE;
  }

Oh that's truly unfortunate that the old global was filled in with the new value and not the other way around, that's just not great, oof.

So the specific error I'm seeing in our settings.php is that when we attempt to include it the second time, the variable $config is NULL, instead of an array. It looks like setting the same three variables to empty arrays, just like \Drupal\Core\Site\Settings::initialize() does resolves it locally for me. And gives a cleaner inspection of the actual settings as well.

This could also be fixed by using include_once or require_once in our settings.php file of our sub-settings files, which we will also do in our code, but the attached patch I would suggest for inclusion and release.

Hi Gábor,

I am having a similar issue that was stated in comment #10. I uninstalled the module and used composer to download drupal/upgrade_status 3.x-dev@dev and reinstalled it in my Drupal project.

I was expecting to clear the error status but it was still present, I dumped the value and for some reason, the global variable $config_directories still has a value assigned to it.

  protected function isDeprecatedConfigDirectorySettingUsed() {
    $app_root = $this->kernel->getAppRoot();
    $site_path = $this->kernel->getSitePath();
    if (is_readable($app_root . '/' . $site_path . '/settings.php')) {
      // Reset the "global" variables expected to exist for settings.
      $settings = [];
      $config = [];
      $databases = [];
      require $app_root . '/' . $site_path . '/settings.php';
    }

    echo "<pre>";
    var_dump($config_directories);
    echo "</pre>";
    exit(1);
    if (!empty($config_directories)) {
      if (!empty($settings['config_sync_directory'])) {
        // Both are set. The $settings copy will prevail in Settings::initialise().
        return NULL;
      }
      // Only the deprecated variable is set.
      return TRUE;
    }

    // The deprecated variable is not set.
    return FALSE;
  }

I even cleared the cache and truncated the tables in the DB just to be sure it's not cache but to no avail. Please see screenshots below:

• https://imgur.com/8uiwo0t
• https://imgur.com/oL0j2sX
• https://imgur.com/N9dkiqq

 
Also, a note - I am using DevDesktop by Acquia for my local environment. There might be something that I missed but any guidance would be much appreciated.

Hi folks

I too was getting this issue and found it to be the fault of the

$config_directories['sync'] = $repo_root . "/config/default";

line that was in my /vendor/acquia/blt/settings/config.settings.php file

I'm using BLT 11.5, but I suspect I should have upgraded that to a higher version and will be doing that shortly as part of the move to Drupal9

I was getting the reported config_directory error on my local (not deployed yet - just working locally with the upgrade status module)

HTH

Sam