Timeline for There were errors validating the config synchronization after changes to modules and config
Current License: CC BY-SA 4.0
7 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Dec 8, 2023 at 19:10 | review | Close votes | |||
| Dec 24, 2023 at 3:03 | |||||
| Dec 8, 2023 at 18:53 | comment | added | norman.lol | Hahaha, we've all been there. Glad you sorted it out. | |
| Dec 8, 2023 at 18:52 | comment | added | norman.lol | Does this answer your question? Order of drush commands for automated deployment? | |
| Dec 8, 2023 at 18:52 | comment | added | GeorgeCiesinski | I am ashamed to say I missed the obvious. Drush cex exports to my files/ directory by default which is in my .gitignore. The config folder contained outdated config from before, which is why it was failing. I used cyberduck to delete the old config folder and upload the new one, and "[success] The configuration was imported successfully." | |
| Dec 8, 2023 at 18:49 | comment | added | norman.lol | First deployment should disable the module (removed entry in core.extension.yml and removed module config). Second deployment should remove the module from the filesystem (via compser.json/.lock). As @cilefen says: The module needs to be present to get uninstalled, to get possible uninstall hooks in that module run and clean up a bit. You can't uninstall a module that's not there. | |
| Dec 8, 2023 at 18:40 | comment | added | mona lisa | In step 5)i, is the module code present when that command runs, or isn't it? | |
| Dec 8, 2023 at 18:13 | history | asked | GeorgeCiesinski | CC BY-SA 4.0 |