Contrib.social

Drop support for config overrides and use switcher values

Open on Drupal.org →
Created on 11 August 2023, almost 2 years ago

Problem/Motivation

This modules is cumbersome at best to configure, as it requires editing your actual infrastructure files like settings.php. Furthermore you have duplicate/match the colors within your settings file to match your config entities so things are consistent.

The crux of this complication is that your current environment is driven via config overrides, and the menu items are driven by configuration. There is no way to match everything up, and determine your environment dynamically. This adds complications when you want to do things like enforce permissions or update many sites in your workflow by just exporting your config.

Back in D7, the module supported regex matching, but that was removed during the port to D8. I have not found a legitimate reason why this was done.

There are also many issues here in the queue that could be much more easily resolved if we evolve the code in this way.

Proposed resolution

- Add a regex textarea to each config entity, allowing for multiple patterns.
- Evolve the code to determine the active environment to use either the regex or hostname, returning the config entity.
- Evolve the logic (permissions, rendering) to utilize the active environment properly.

There are already some tasks (somewhat) related to this in the queue:

- ✨ Use switcher values for toolbar title, fg_color and bg_color Needs review Has some good ideas like moving active environment to a service. Opts to keep settings.php except now you use the machine name for mapping which is not dynamic in nature.
- 📌 Add relation between switchers and active configuration Closed: outdated Old issue
- ✨ Allow regex / partial domain in hostname Closed: outdated Old issue
- 💬 Does the module automatically detect the current environment it is in based on the URL? Closed: outdated Old issue
- #3065135: Add support for multilingual domain sites → Along with the patch would benefit from the regex option
- 💬 Granular permissions are not working as expected. Active Would benefit / be resolved by dynamic active environment

Remaining tasks

- Update the documentation
- Move the active environment logic to a service
- Determine if an update script is needed as this code removes environment_indicator.indicator and adds environment_indicator.switcher.mapping.regex

User interface changes

A new regex textarea is added to the entity form.

📌 Task
Status

Active

Version

4.0

Component

Code

Created by

🇺🇸United States devkinetic

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Merge Requests

Comments & Activities

  • Issue created by @devkinetic
  • Merge request !28Issue #3380586: Drop support for config overrides and use switcher values → (Open) created by devkinetic
  • Comment almost 2 years ago →
    🇺🇸United States devkinetic
  • Comment almost 2 years ago →
    🇺🇸United States devkinetic
  • Comment almost 2 years ago →
    🇺🇸United States devkinetic
  • Comment almost 2 years ago →
    🇺🇸United States devkinetic
  • Comment almost 2 years ago →
    🇺🇸United States devkinetic

    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.

  • Comment almost 2 years ago →
    🇺🇸United States devkinetic

    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.

  • First commit to issue fork.
  • Pipeline finished with Failed
    8 months ago
    Total: 141s
    #331375
  • Merge request !99Draft: Resolve #3380586 "Tugboat" → (Open) created by trackleft2
  • Comment about 18 hours ago →
    🇨🇦Canada colan Toronto 🇨🇦

    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).

  • Comment about 4 hours ago →
    🇧🇪Belgium svendecabooter Gent

    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
    - ...

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024