🇺🇸United States @trackleft2

Tucson, AZ 🇺🇸
Account created on 2 April 2014, over 11 years ago
#

Merge Requests

More

Recent comments

🇺🇸United States trackleft2 Tucson, AZ 🇺🇸

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.

🇺🇸United States trackleft2 Tucson, AZ 🇺🇸

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.

🇺🇸United States trackleft2 Tucson, AZ 🇺🇸

This is ready for final review.

🇺🇸United States trackleft2 Tucson, AZ 🇺🇸

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

🇺🇸United States trackleft2 Tucson, AZ 🇺🇸

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

🇺🇸United States trackleft2 Tucson, AZ 🇺🇸

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

🇺🇸United States trackleft2 Tucson, AZ 🇺🇸

trackleft2 created an issue.

🇺🇸United States trackleft2 Tucson, AZ 🇺🇸

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

🇺🇸United States trackleft2 Tucson, AZ 🇺🇸

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

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

🇺🇸United States trackleft2 Tucson, AZ 🇺🇸

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

🇺🇸United States trackleft2 Tucson, AZ 🇺🇸

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

🇺🇸United States trackleft2 Tucson, AZ 🇺🇸

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

🇺🇸United States trackleft2 Tucson, AZ 🇺🇸

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

🇺🇸United States trackleft2 Tucson, AZ 🇺🇸

Looks good to me, Thanks!

🇺🇸United States trackleft2 Tucson, AZ 🇺🇸

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.

🇺🇸United States trackleft2 Tucson, AZ 🇺🇸

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

🇺🇸United States trackleft2 Tucson, AZ 🇺🇸

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.

🇺🇸United States trackleft2 Tucson, AZ 🇺🇸

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

🇺🇸United States trackleft2 Tucson, AZ 🇺🇸

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

🇺🇸United States trackleft2 Tucson, AZ 🇺🇸

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

🇺🇸United States trackleft2 Tucson, AZ 🇺🇸

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.

🇺🇸United States trackleft2 Tucson, AZ 🇺🇸

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

🇺🇸United States trackleft2 Tucson, AZ 🇺🇸

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

🇺🇸United States trackleft2 Tucson, AZ 🇺🇸

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

🇺🇸United States trackleft2 Tucson, AZ 🇺🇸

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

🇺🇸United States trackleft2 Tucson, AZ 🇺🇸

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

🇺🇸United States trackleft2 Tucson, AZ 🇺🇸

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.

🇺🇸United States trackleft2 Tucson, AZ 🇺🇸

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.

🇺🇸United States trackleft2 Tucson, AZ 🇺🇸

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.

🇺🇸United States trackleft2 Tucson, AZ 🇺🇸

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.

🇺🇸United States trackleft2 Tucson, AZ 🇺🇸

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

🇺🇸United States trackleft2 Tucson, AZ 🇺🇸

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

🇺🇸United States trackleft2 Tucson, AZ 🇺🇸

Add usage note for config_split

🇺🇸United States trackleft2 Tucson, AZ 🇺🇸

Move Environment switchers link above inline code help.

🇺🇸United States trackleft2 Tucson, AZ 🇺🇸

Adding config split instructions
Update headings
adding links

🇺🇸United States trackleft2 Tucson, AZ 🇺🇸

Change lando to ddev

🇺🇸United States trackleft2 Tucson, AZ 🇺🇸

Add example that would cover multiple environments.

🇺🇸United States trackleft2 Tucson, AZ 🇺🇸
🇺🇸United States trackleft2 Tucson, AZ 🇺🇸

Update headings.

🇺🇸United States trackleft2 Tucson, AZ 🇺🇸

Bolding the module names to further promote modular architecture.

Production build 0.71.5 2024