Incorrect Config Sync Directory

By default, Drupal places the configuration sync directory within the site's files directory, using a hash as part of the directory name, thus: sites/default/files/config_HASH. BLT overrides this behavior for both ACE and ACSF. By default, BLT sets the config sync directory to be $repo_root/config/default, although this can be overridden.

If the BLT config settings are not being properly applied or are being overridden, deployments and configuration imports in the cloud can exhibit "odd" behavior, due to Drupal using an incorrect sync directory.

Symptoms of this Problem

The clearest symptom of this is that config is being imported that you do not expect. For instance, you have disabled config splits or removed config, but after deploying the config changes, you still see these splits active, or you see the removed configuration persist. 

Testing for this Problem

The most direct way of verifying this issue is to use drush php to confirm that the site is using the directory you expect as the config sync directory. In a typical BLT project, the config sync directory is set by BLT to config/default in the project root directory:

Drupal core 8.7.x and earlier:

$ drush php
>>> config_get_config_directory('sync')
=> "/mnt/www/html/myprojectroot/config/default"

Drupal core 8.8.0 and later:

$ drush php
>>> \Drupal\Core\Site\Settings::get('config_sync_directory')
=> "/mnt/www/html/myprojectroot/config/default"

If the BLT config settings are not being properly applied or are being overridden, your site might be using a config sync directory that looks like this:

drush php
>>> \Drupal\Core\Site\Settings::get('config_sync_directory')
=> "/mnt/www/html/myprojectroot/docroot/sites/default/files/config_7d2b940371cd3296a843f2cfddcc85a059b273b3/sync"

In this example, the output is the default drupal/core configuration location (note that it is stored in sites/default/files and not in config/default).

Fixing this Problem

In general, this is occurring for one of a few reasons:

1. The BLT settings are not being properly applied
2. The BLT settings are being overridden 

BLT's settings file should be the "last" thing in the settings.php file for "each" site (sites/default for single site, sites/<site> for each site in a multisite). If blt.settings isn't being included, include it by running the command blt blt:init:settings. If it is being included, but other things are happening in the file after its inclusion, move it to the end of the file. This includes any multisite configuration required by Acquia Cloud.