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
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
Comment #3
alexpottCan we add a test for this. I'd love to fix it but I'm also scared of breaking it in the future.
Comment #4
tstoecklerI 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.Comment #5
bircherRE #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!
Comment #6
tstoecklerAhh that's a neat idea, hadn't thought of that 👍 Thanks!
No worries about the issues, all good.
Comment #7
mxr576Pipeline 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.
Comment #8
mxr576Moving this to needs work since test coverage is missing.
Comment #10
christianadamski commentedIt 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.