Problem/Motivation

Status overrides in settings.php have unexpected results

Steps to reproduce

I'm setting up configuration splits with Drupal 9 and encountering unexpected results.

None of my splits are marked as "Active" in the active configuration or the exported configuration YAML.

I want to set the default Local split in settings.php and then use settings.local.php to override it on dev, stg, prd environments.

My local development environment is DDEV-Local v1.17.5. The three remote environments are all set up on one remote server in the client's private AWS, in three different Apache VirtualHosts.

I can't use environment variables to differentiate the dev, stg, prd environments since they are all on one host. It's been a challenge differentiating the environments without the usual Acquia or Pantheon environment variables.

This is the default override in settings.php:

  $config['config_split.config_split.local']['status'] = TRUE;
  $config['config_split.config_split.prd']['status'] = FALSE;
  $config['config_split.config_split.stg']['status'] = FALSE;
  $config['config_split.config_split.dev']['status'] = FALSE;

So far, so good. The Local split is "active (overwritten)".

Things get weird when I edit this to enable another split in my Local environment:

  $config['config_split.config_split.local']['status'] = FALSE;
  $config['config_split.config_split.prd']['status'] = TRUE;
  $config['config_split.config_split.stg']['status'] = FALSE;
  $config['config_split.config_split.dev']['status'] = FALSE;

After editing settings.php (and clearing cache, of course) the Production split is "active (overwritten)", as expected.

Unfortunately, the Local split is also "active (overwritten)" despite setting its ['status'] = FALSE;.

Things get weirder when I attempt to logically negate the values of all the splits:

  $config['config_split.config_split.local']['status'] = FALSE;
  $config['config_split.config_split.prd']['status'] = TRUE;
  $config['config_split.config_split.stg']['status'] = TRUE;
  $config['config_split.config_split.dev']['status'] = TRUE;

Now, the Local split is still "active (overwritten)" despite setting its ['status'] = FALSE;.

The Stage and Production splits are "active (overwritten)" to match their ['status'] = TRUE;.

And the Dev split remains "inactive" despite setting its ['status'] = TRUE;.

Any idea what is happening here?

The problem does not occur only in DDEV-Local; it persists across the three remote environments as well:

  • In the Dev environment, only the Local split is active.
  • In the Stage environment, Local and Stage splits are active.
  • In the Prod environment, Local and Prod splits are active.

I think my next step will be to recreate the Dev and Local splits with different names.

Proposed resolution

None known.

Remaining tasks

None known.

User interface changes

None known.

API changes

None known.

Data model changes

None known.

Comments

hotwebmatter created an issue. See original summary.

bircher’s picture

bircher
Location 🇨🇿
commented

This is very strange indeed.
I suspect that there is something strange going on with how your different settings.php files are assembled.
Config Split is leveraging the standard configuration override system of Drupal core to determine which split is active or not. So I am not sure how to help here.

hotwebmatter’s picture

hotwebmatter commented
Issue summary: View changes

Thanks bircher for the quick response!

The problem does not occur only in DDEV-Local; it persists across the three remote environments as well:

  • In the Dev environment, only the Local split is active.
  • In the Stage environment, Local and Stage splits are active.
  • In the Prod environment, Local and Prod splits are active.

I think my next step will be to recreate the Dev and Local splits with different names.

hotwebmatter’s picture

hotwebmatter commented
Status: Active » Closed (works as designed)

I changed the machine names of the splits (e.g., dev_split) and everything works as expected.

Therefore, the problem was being caused by the acquia/blt package, which uses the acquia/drupal-environment-detector package to set the active split based on Acquia environment variables.

Since $_ENV['AH_SITE_ENVIRONMENT'] is unset, the Local environment split will always be active.

I'm not sure why the Dev split cannot be activated, but that is probably related as well.

I could remove BLT from the project entirely since we are not using Acquia hosting, and therefore we are no longer using it for much, but I was reluctant to set up the automated testing stuff again without all that Robo goodness.

Instead, I made acquia/blt a Composer dev dependency so it would not be installed in higher environments. Apparently, that was not enough -- it still messes with my config splits, and may have other unpredictable side effects.

The quick fix is to change machine names for splits. Probably ditching BLT altogether is a better solution in the long run.

Closed (works as intended)

P.S.: If your BLT project is hosted on Acquia, then the environment detection will work correctly, and this problem will not arise. No wonder this is such a rare problem -- most people probably do not use BLT outside of Acquia's environments.

bircher’s picture

bircher
Location 🇨🇿
commented

Thanks for keeping the issue updated.
I am glad you found a solution, I have not used BLT and only briefly DDEV so I couldn't really help there. I didn't know BLT did some magic to config split, so that is good to know.