- Issue created by @jedihe
I've experienced config problems while upgrading from 1.x to 2.x (from 8.x-1.9 to 2.0.0). The release notes of
config_split
lack of "migration" / "Upgrading from v1 to v2" steps.I'd say the module maintainers need to keep the composer dependency [module dependency] for a while, the best thing you could have done is to uninstall/disable the Drupal module and not both things at once (1. uninstall it from Drupal. 2. remove it from composer [I think it's not set in composer but in the info.yml file as a module dependency]). The config_split module should have run the configuration updates first and then uninstall the config_filter module, it did the opposite due to the `composer require` need to upgrade the module in composer.
Probably config_split module needs to keep hook update 8001 as is and add a new hook_update (8004) to the 2.x branch where you assume the config_filter is installed and uninstall it for us, that would prevent unexpected loss of configurations.
- Status changed to Needs review
about 1 year ago 12:35pm 15 February 2024 - 🇨🇭Switzerland bircher 🇨🇿
I updated the module page please check it and let me know if this would have saved you some frustration. The notice about config filter is also added the the release note. I copied it from config ignore.
RE #5: No the whole point of a major version change is that it allows "breaking changes". So I will not be adding the dependency on config filter. You should always require all your drupal modules explicitly (and in my opinion with explicit version numbers so that you don't run into problems with update hooks changing configuration that you then forget to export, drupal modules are not like php libraries, they have an impact on the database schema so they need to be managed with much more care).
Uninstalling Config Filter is out of scope for config split, but there is ✨ Suggest uninstalling when there is no other module depending on it. Fixed which has been part of config filter since 1.11 →
I try to keep the disruption between major versions of the module minimal, so yes if you don't disable patching then a bunch of the config files will be different, but it should behave largely the same. It depends on how you use config split of how much these patches affect you. - 🇨🇴Colombia jedihe
@bircher: great! the upgrade section in the project page is very useful!
Just one small additional suggestion: is it possible to link to the step-by-step in the issue summary above from the upgrade section in the project page? seeing specific commands/steps like the ones I wrote there is super-helpful for anybody with enough experience to just start trying those out.
- Status changed to Fixed
about 1 year ago 7:47am 21 February 2024 - 🇨🇭Switzerland bircher 🇨🇿
Thanks for checking it.
I don't know if listing commands for updating a module belong to the project page if nothing changes from the normal workflow.
When you update any module or drupal core you need to follow this procedure.
To point out that this is not new I usually reference the session at Drupal dev days in Sevillie 2017. https://nuvole.org/blog/2017/mar/30/our-presentations-drupal-dev-days-se...The steps for updating is on page 41. I think is is also somewhere in the documentation.
Automatically closed - issue fixed for 2 weeks with no activity.