Implement the current environment as a service and utilize plugins

Open on Drupal.org →

Created on 11 August 2023, over 1 year ago

Updated 19 August 2024, 8 months 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. It stands to reason that there are multiple ways that the current environment could be determined, and it should be up to the user as to how they want to do so. This is a perfect use case for a plugin. There are also many issues here in the queue that could be much more easily resolved if we evolve the code in this way.

Currently I see three possible methods of determination:

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

Proposed resolution

Define a plugin manager for current environment
Add a dropdown on each environment to select the plugin to use
Allow for each plugin to provide configuration (like a regex pattern)
Evolve the code to determine the current environment through the plugin system.
Evolve the logic (permissions, rendering) to utilize the current environment properly through the plugin system.

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 current environment to a service. Opts to keep settings.php except now you use the machine name for mapping which is not dynamic in nature. Also the current environment gets saved to state/cached
📌 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 current environment
🐛 InvalidArgumentException: "Class "\Drupal\environment_indicator\Form\EnvironmentIndicatorSettingsForm" does not exist." Active Would no longer be an issue

Remaining tasks

Update the documentation.
Develop a plugin manager for current environment.
Enable the plugin manager and the config entity to store plugin settings
Determine how best to retain/cache the current environment, so as not to recalculate it on each page load.

User interface changes

A new select list on the environment indicator form to select the plugin, and load in the selected plugin's config 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

!28Implement the current environment as a service and utilize plugins
Open
🇺🇸United States devkinetic
updated 5 months ago

Comments & Activities

Issue created by @devkinetic
Merge request !28Issue #3380586: Drop support for config overrides and use switcher values → (Open) created by devkinetic
Comment over 1 year ago →
🇺🇸United States devkinetic
Comment over 1 year ago →
🇺🇸United States devkinetic
Comment over 1 year ago →
🇺🇸United States devkinetic
Comment over 1 year ago →
🇺🇸United States devkinetic
Comment over 1 year 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 over 1 year 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
5 months ago
Total: 141s
#331375

contrib.social Blog FAQ Discussions

Production build 0.71.5 2024