Problem/Motivation

in #3047812: Add a Config Transformation event dispatching during config import and export We added the configuration transformation API.
However, we forgot to dispatch the transformation events to the installer for "install from config". So now modules that updated to use the core API (for example config split 2.x and config ignore 3.x) are "broken" compared to how they used to work.
A workaround is to import the configuration right after having Drupal installed.

Steps to reproduce

See #3425466: Active splits should be considered and imported during site-install
The explanation of why this used to work with Config Filter 1.x but doesn't work with anything using the core API is because Config FIlter 1.x wraps the sync storage whenever it is installed. This means that while the first config import of the "install from config" doesn't consider config split or config ignore, the second config import does (It was originally meant to just align anything small things).

/**
 * Reverts configuration if hook_install() implementations have made changes.
 *
 * This step ensures that the final configuration matches the configuration
 * provided to the installer.
 */
function install_config_revert_install_changes() 

When using Config Filter 1.x, this does a bit more than just reverting configuration from hook_installs.

Proposed resolution

Dispatch the config import transformation event in function install_config_import_batch() and in function install_config_revert_install_changes()
We could consider batching also the second config import.

Remaining tasks

patch
review
commit
celebrate

User interface changes

none, maybe we need to batch the second config import install step too, in which case there is another batch process during install.

API changes

none

Data model changes

none

Release notes snippet

Configuration Import Transformation event is dispatched when installing Drupal from configuration.

Issue fork drupal-3426298

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Comments

bircher created an issue. See original summary.

alexpott’s picture

Issue tags: +Needs tests

Can we add a test for this. I'd love to fix it but I'm also scared of breaking it in the future.

tstoeckler’s picture

I recently opened #3424255: Config storage transformers do not get applied when installing Drupal from configuration for this, because I hit this with Config Overlay, as well. I only had the change in the "revert" step there, which seems to be sufficient at least according to Config Overlay's test coverage ;-). I left out the change in the initial import because as far as I can tell, there are no modules installed at that point anyway, so I felt like there's really no benefit to it. And ExcludedModulesEventSubscriber (which is the only transformer in code) will not have any effect on the initial install either, as far as I can tell. Just curious about the reasoning there, not at all opposed. In fact, if it doesn't break anything, it does seem more "correct" to do it in both cases. I guess if we do add another config subscriber in core it's nice to have that already affect the initial import and not just the "revert". In any case, will close my issue as duplicate.

bircher’s picture

Issue tags: +CMI 2.0 candidate

RE #3: yes definitely needs tests! just didn't have enough time to add them.

RE #4: Yes, you are right, in the first steps there are no modules installed that could interact. However! You can add services via settings.php even from modules that are not yet installed. So we should definitely do it for both, which would mean the second import has to do much less if you add your modules services via settings.php to take effect in the first round. (which is what I think I will suggest people do for config split if they run into troubles with the non batched version or if they split their sync storage to smithereens against all recommendations)

And sorry for not having found your issue, and thanks for finding mine!

tstoeckler’s picture

Ahh that's a neat idea, hadn't thought of that 👍 Thanks!

No worries about the issues, all good.

mxr576’s picture

Pipeline on the MR is currently in a failed state, could be due to transient errors but since the build log has expired, I am going to rebase and see what happens.

mxr576’s picture

Status: Active » Needs work

Moving this to needs work since test coverage is missing.

jan.stoeckler made their first commit to this issue’s fork.

christianadamski’s picture

It worked here!

We have 4 Subsites, all have config_splits, but only 2 have as off recently separate modules to be isntalled. That worked, but only by re-importing after install, which broke our CI pipeline.

With this MR, it just worked.

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.