Score:1

Configuration overrides have unpredictable results

nr flag

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.

(Note: I understand if config_split is off-topic here since it is not a core module. I have created an issue queue on Drupal.org, but I'm still hoping that someone will see the question here and offer an insight.)

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?

Score:1
nr flag

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.

za flag
I have been dealing with BLT lately, and yes the settings includes (along with the Acquia ones) makes it rather confusing. Additionally, unless you create your own detector there is only [dev, stage, prod, ci, ode, ah_other, local] - EnvironmentDetector#getEnvironments
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.