Drop support for config overrides and use switcher values

Upon further thought, I don't see why we couldn't extend the current environment deriver to be plugin based. We already have the ability to provide at least:

• The current settings.php config, with the addition of adding the machine name to enable permissions
• Simple host name matching
• Regex based host name matching

This would vastly simplify the upgrade path, as the settings.php plugin would be active by default.

After implementation, we would have to take another swing at permissions, to cover existing sites that do not have the machine name in settings.php.

I've done some experimentation with converting the current environment code into a plugin system. I'm currently working through the ability to add settings for each implementation of the plugin, for example the patterns for the regex. This is apparently accomplished with EntityWithPluginCollectionInterface which is not documented very well.

As things stand the issue description stands to be updated.

I'm not sure how far you got with this as there haven't been any updates in a while.

At first, I thought this was overkill, but it makes sense if you really want to support all of these use cases.

But I'm not sure it's even necessary. Why wouldn't folks simply want to automatically determine by URL? This could include regexes and aliases (say for private or non-load-balanced hostnames)? These can be enhancements added on later.

I'm coming from 💬 Granular permissions are not working as expected. Active , where I had to use the environment ID to determine the necessary permission to check for, which I need to set in settings.php, but that's just because it was quick. Machine names wouldn't need to be set if we just relied on the URL (or some variation/alias).

I think a plugin system for detecting the current environment would be really helpful.
While a lot of people would opt to use URL matching to discover the current environment, I can see other methods being used:
- a config override in settings.php
- a setting in \Drupal::state()
- a system environment variable (retrieved via getenv()) - e.g. set by a CI script targetting a specific environment
- ...

Hi all, I think we can approach this like any other override to the environment indicator—similar to how we handle overrides in settings.php.

The key functionality we need is a way to clearly communicate to site owners or administrators what is setting the fg_color and bg_color—whether it’s an override in settings.php, the environment_indicator.indicator config, or an environment indicator switcher.

There is already work in progress to enable the core functionality that displays a message when config is overridden in settings.php (see ✨ Adopt usage of #config_target in ConfigFormBase: using schema validation constraints for simple config. Active ). I would suggest implementing a similar message when overrides are made via a URL set on an environment indicator switcher.

We will also need to define and agree on an override precedence order. My initial suggestion is:
1. settings.php (highest precedence, cannot be overridden in the UI)
2. URL override via environment indicator switcher, regex, or another plugin
3. environment_indicator.indicator configuration (default)
4. Nothing set

If we do plan on implementing this order, I suggest we add an option-based setting to environment_indicator.settings to allow choosing the method of override. The available options might include regex and switcher_url.

To me, this means the architecture for this feature can be:

• A new plugin system for determining the active environment and setting the name, fg_color, and bg_color, with at least one plugin for detecting the active environment via switcher URL.
• A new getActiveEnvironment() method in src/Service/EnvironmentIndicator.php that delegates to the configured plugin and returns the environment values. (Only one plugin active at a time.)
• Updates to all consumers (e.g., environment_indicator_toolbar, favicon, environment_indicator module) to use the service method for setting the active environment.
• A new setting in environment_indicator.settings for choosing which plugin determines the active environment.

Let me know what you think, keeping in mind, the reason for introducing override logic (rather than setting the config directly) is to preserve compatibility with the configuration staging workflow. By treating the environment values as runtime overrides, we avoid modifying the environment_indicator.indicator config itself—allowing it to remain deployable and under version control like any other staged configuration.

Knowing when stuff if overridden is certainly helpful.