Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use Config Override System to set configuration values. #370

Open
rosiel opened this issue Nov 24, 2023 · 0 comments
Open

Use Config Override System to set configuration values. #370

rosiel opened this issue Nov 24, 2023 · 0 comments

Comments

@rosiel
Copy link
Contributor

rosiel commented Nov 24, 2023

Related issue: Islandora-Devops/islandora-starter-site#17

Whereas

Drupal has a config override system which is, essentially, writing your config values in settings.php. This is how Isle Site Template currently sets values.

And with the recent acceptance of some Pull Requests relating to warning users that configs are being overridden, now config overrides provide a good UI/UX...

I propose

We use config override (as above) to set config values instead of the current method of drush config:set or drush config-set (see lines in buildkit's utilities.sh).

Moreover, per Issue #326 , media.settings standalone_url has no business being set at all. This is the domain of the starter site or whatever other existing configs you're loading.

In a similar vein, ISLE should not be setting:

  • openseadragon.settings manifest_view
  • jsonld.settings remove_jsonld_format
  • system.theme default carapace

Reasoning

  • Using the config override method would make it easier to create and share updates and PRs to the Starter Site as there aren't unnecessary changes forced into the config diff. This is a known problem and doing this would solve it.
  • Having a common method of overriding values with the Isle Site Template will make understanding the two systems easier.
  • Using this system of configuration override is a good practice that vendors and other institutions can emulate, so getting the community accustomed to how it works would be advantageous.

The further changes proposed (i.e. not setting unnecessary config values)

  • would make the starter site more functional as someone who launches the starter site will see the starter site as is meant to work.
  • Would make a sensible separation between the system that spins up the site (and necessarily sets the locations of external services) from the part of the system that manages Drupal configuration (now we have the starter site but the principle applies even when other config management systems are used).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant