Contrib.social

Switch from a ConfigInstaller override to hook_modules_installed

Open on Drupal.org →
Created on 13 April 2023, almost 2 years ago
Updated 3 May 2023, almost 2 years ago

Problem/Motivation and Proposed Solution

Bircher pointed out on Slack that optional config is only ever installed when new modules are enabled and not during other operations. Since that's the timing and behaviour we want to mimic we also have a hook that we can use in the form of hook_modules_installed.

There's a few trade-offs to keep in mind while making that switch.

Our current implementation ensures we don't unnecessarily clear any caches since our interjection happens before $this->configFactory->reset(); in ConfigInstaller::installDefaultConfig. I'm unsure when hook_modules_installed runs and whether that would require an extra cache clear.

We're currently invoked twice since ConfigInstaller::installOptionalConfig is executed twice from ConfigInstaller::installDefaultConfig. Moving to the hook would deduplicate that. Since we mostly work on things that get statically cached in memory this isn't currently a large problem.

One of the goals of this module is to use as many existing building blocks as possible. An important piece of that is to make sure our modifications' dependencies behave the same as regular config dependencies. However the ConfigInstaller::validateDependencies method which we use to achieve that is protected which means we can't easily re-use this logic outside of ConfigInstaller.

Remaining tasks

User interface changes

API changes

Data model changes

✨ Feature request
Status

Closed: won't fix

Version

1.0

Component

Code

Created by

🇳🇱Netherlands kingdutch

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

Comments & Activities

  • Issue created by @kingdutch
  • Comment almost 2 years ago →
    🇨🇭Switzerland bircher 🇨🇿
  • Comment almost 2 years ago →
    🇳🇱Netherlands kingdutch

    Postponing this on the fact that we can't re-use the dependency validation logic and from a maintenance perspective I really don't want to duplicate this.

    Crediting Bircher with providing the insights that led to this possible module improvement :)

  • Status changed to Closed: won't fix almost 2 years ago
  • Comment almost 2 years ago →
    🇳🇱Netherlands kingdutch

    We ran into 🐛 Installing config modify in an existing project can cause race conditions Fixed which requires the steps of config_modify to be per-module.

    For example: Install new module B which depends on config_modify. This should

    • First install the config_modify module ignoring all existing module's config/modify alterations (since they're assumed to be present through other means)
    • Then install module B which might trigger config/modify that's in that module itself

    Switching to hook_modules_installed would mean that we'd be called once for both modules after they're both installed. At that point we'd need to take care to go through each module in dependency order so that we don't accidentally exclude B's config/modify files.

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024