🇺🇸United States @trackleft2

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.

Hi there, thank you for your interest in contributing to this module, we will no longer be accepting fixes to the javascript version of environment indicator integrations. If you would still like to help out, please review the merge requests on 📌 Update module to use CSS variables instead of adding inline CSS. Active and 🐛 Gin Compatibility: Account for "open" vertical toolbar Active for the issue described here.

Those two issues block this one in my opinion.

trackleft2 → created an issue.

This is ready for final review.

trackleft2 → changed the visibility of the branch 4.x to hidden.

trackleft2 → changed the visibility of the branch 3310409-add-permission-to to hidden.

Thank you

trackleft2 → created an issue.

Needs issue summary update and a database update that enables the environment_indicator_toolbar module.

trackleft2 → created an issue.

I went ahead and merged the fix, but I'll hold off on creating a release until I get confirmation that the fix works for you all.

See https://www.drupal.org/project/environment_indicator/issues/3530665 🌱 [META] Release Plan for Environment Indicator Patch (bugfix) Release 4.0.24 Needs review

trackleft2 → created an issue. See original summary → .

Thanks @nicodh! I've added a merge request that hopefully resolves the issue?

https://mr111-9szdrkjpjwhiv06rgrncbsjlyq5m4iav.tugboatqa.com/

trackleft2 → changed the visibility of the branch 4.0.x to hidden.

Closing as duplicate of ✨ Adopt usage of #config_target in ConfigFormBase: using schema validation constraints for simple config. Active

Cool, I made a phpunit test too. It seems to successfully check the fix.

Thanks! Your proposal and patch both look good to me.

I've been attempting to reproduce the error described here, but have not been successful so far.

Here are the variables in my set up.
Gin: 4.0.6
Gin Toolbar: 2.0.0
Drupal: 10.3.14 or Drupal

In Gin I am using the vertical toolbar.

Safari on MacOs, or Chrome on MacOs using a mobile view port.

My environment_indicator.settings configuration looks like this:
```
_core:
default_config_hash: RHFPAppLk6zO1dvgmh8B7KnqfC2cFwvZapHp4z8YWhs
toolbar_integration: { }
favicon: true
version_identifier: environment_indicator_current_release
version_identifier_fallback: deployment_identifier

```

My environment_indicator.indicator configuration looks like this:
```
name: Test
fg_color: '#ffffff'
bg_color: '#dd3f8f'

```

What does you configuration look like?
Does the solution on either of these issues resolve the issue?

- 🐛 Gin Compatibility: Account for "open" vertical toolbar Active
- 📌 Update module to use CSS variables instead of adding inline CSS. Active

Looks good to me, Thanks!

As of the 4.0.22 release, the toolbar integration that was previously included in this module has been deprecated and will not receive further improvements.

That said, we are actively working to improve the implementation found in the environment_indicator_toolbar module.

One of the goals of the environment_indicator_toolbar module is to improve the performance of the toolbar indicator by relying solely on server-side rendering and CSS, with no JavaScript required.

There are a couple of issues open about this too if you are interested at:
- 🐛 Gin Compatibility: Account for "open" vertical toolbar Active
- 📌 Update module to use CSS variables instead of adding inline CSS. Active

To support this approach, we can take advantage of CSS’s ability to target data-* attributes. This allows us to set environment-specific values as attributes on the <body> tag, which can then be used by CSS to dynamically apply styles.

Here’s an example of how you might set these values in a hook_preprocess_html() implementation:

/**
 * Implements hook_preprocess_HOOK() for page templates.
 */
function environment_indicator_toolbar_preprocess_html(&$variables) {
  $active_environment = \Drupal::config('environment_indicator.indicator');
  // Add data attribute for foreground color.
  $fg_color = strtolower($active_environment->get('fg_color') ?? '');
  if (preg_match('/^#[0-9a-f]{6}$/i', $fg_color)) {
    $variables['attributes']['data-environment-indicator-fg'] = $fg_color;
  }
  // Optionally add more for background or other styles
  $bg_color = strtolower($active_environment->get('bg_color') ?? '');
  if (preg_match('/^#[0-9a-f]{6}$/i', $bg_color)) {
    $variables['attributes']['data-environment-indicator-bg'] = $bg_color;
  }
}

Then, in your CSS, you can apply conditional styling based on those attributes:

body[data-environment-indicator-fg="#000000"] {
    --environment-indicator-icon-filter: invert(100%);
}

body[data-environment-indicator-fg="#ffffff"] {
    --environment-indicator-icon-filter: invert(0%);
}

.toolbar .toolbar-bar .toolbar-tab>.toolbar-icon.is-active::before {
    filter: var(--environment-indicator-icon-filter, none);
}

I hope that makes sense. We'd be happy to accept a merge request that satisfies these requirements.

trackleft2 → made their first commit to this issue’s fork.

trackleft2 → created an issue.

Thank you, I'll get a new release out with this in it soon.Sorry about the new bug. I am not sure why the PHPUnit tests are failing now.

trackleft2 → changed the visibility of the branch 3483905-adopt-usage-of to hidden.

trackleft2 → changed the visibility of the branch 4.x to hidden.

trackleft2 → changed the visibility of the branch 3224593-accessibility-fixes-for to hidden.

trackleft2 → changed the visibility of the branch 4.x to hidden.

I've updated MR !95 by merging in upstream changes and rearranging things a bit in order to be more in line with where the module is headed. In order to test you must now enable the environment_indicator_toolbar module.

trackleft2 → changed the visibility of the branch 4.x to hidden.

I've added a post update function that just resaves all of the existing cron migrations on the site in order to recalculate dependencies.

I think we need to add a post_update function in order to update existing cron migration config entities to add their dependencies.

trackleft2 → changed the visibility of the branch 2.1.x to hidden.

trackleft2 → changed the visibility of the branch 3451525-add-config-dependency to hidden.

The PHPUnit test introduced in this MR does not appear to adequately test this functionality.

I say this because the https://git.drupalcode.org/project/user_expire/-/jobs/5542470 test passed with or without the fix. Running the "Test Only Changes" test should fail but it does not.

trackleft2 → changed the visibility of the branch 8.x-1.x to hidden.

trackleft2 → created an issue.

Hi sahil.sharma@io-media.com I'll add this to the plan for the next release. Thanks! The patch looks ok to me, so feel free to use it until then.

Sorry for taking so long in creating a release with this in it. We have a lot tied up in our release number at the moment and don't want to back track since our next patch release should drop any day now and it would be a lot of administrative work to sneak in a hotfix.

On the bright side, during the process of creating the new release, we did realize that we should be supporting 7.3 and Drupal 9.3 and changed that to our target.

I've updated this to add dynamic title handling for the edit and delete form pages, and put it in a merge request with a tugboat preview.

trackleft2 → made their first commit to this issue’s fork.

Sounds like this has been resolved, I've added to the documentation: https://www.drupal.org/docs/extending-drupal/contributed-modules/contrib... →

Add usage note for config_split

Move Environment switchers link above inline code help.

Adding config split instructions
Update headings
adding links

Change lando to ddev

Add example that would cover multiple environments.

Add link to config split documentation  https://www.drupal.org/docs/contributed-modules/configuration-split/crea... →

Update headings.

Bolding the module names to further promote modular architecture.