Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
- Dial back the content_moderation schema version using:
drush ev "drupal_set_installed_schema_version('content_moderation', 8000);"
- Apply the patch.
- Run drush updb.
Comment | File | Size | Author |
---|---|---|---|
#9 | 2890189-832-833-upgrade-9.patch | 665.09 KB | Sam152 |
#9 | interdiff.txt | 509 bytes | Sam152 |
#4 | interdiff.txt | 3.71 KB | Sam152 |
#4 | 2890189-832-833-upgrade-5.patch | 664.6 KB | Sam152 |
#3 | 2890189-832-833-upgrade-3.patch | 663.48 KB | Sam152 |
Comments
Comment #2
Sam152 CreditAttribution: Sam152 as a volunteer and at PreviousNext commentedComment #3
Sam152 CreditAttribution: Sam152 as a volunteer and at PreviousNext commentedInitial start of this with @jhedstrom approach from #2846618: Unofficial content_moderation 8.2.x to 8.3.0 upgrade path.
I couldn't get this test to pass. Just running this approach I get:
I tracked this down to the indexes the issue introduced being missing.
If I try and use the update manager to update the entity definition, it says the field needs to be updated, despite running updateFieldStorageDefinition.
Comment #4
Sam152 CreditAttribution: Sam152 as a volunteer and at PreviousNext commentedI've had another look at this. I managed to come up with quite a hideous patch (with code pulled from a few sources) which doesn't seem to leave any pending entity updates, ensures the new indexes exist and changes the column size.
My guess is the entity update manager will never change the column size of a table that already has data, so it has to be done manually. The ->applyUpdates is needed to create the indexes, which is has no problem doing (could possibly be made more specific, only update our entity type).
Schema before update:
Schema after:
Comment #6
mstef CreditAttribution: mstef commentedTesting with 8.3.4. Patch applies cleanly and everything seems to be working. I'll continue testing.
Thank you very much for your work.
Comment #7
fgmWith this patch applied:
* drush updb --entity-updates applies cleanly
* but then drush entup throws:
Comment #8
Rop CreditAttribution: Rop as a volunteer commentedAfter applying the patch
drush updb --entity-updates
still throws:
Comment #9
Sam152 CreditAttribution: Sam152 as a volunteer and at PreviousNext commentedFor some reason composer patches wont apply a patch correctly if it only contains new files. Adding an empty newline to the module file seems to fix things. I was getting the patch files in ./core/core/modules instead of the correct ./core/modules path.
Comment #10
Sam152 CreditAttribution: Sam152 as a volunteer and at PreviousNext commentedComment #11
fgmThe upgrade path passes like a charm now, and the data look as expected. Thanks for the impressive work.
The most worrying part for me is the fact that this introduces
content_moderation_update_800[1-3]()
implementations, which might cause conflict when the module leave experimental status and official versions of these same functions start appearing. But so for, none exist in 8.3.3/8.3.4/8.3.5.Comment #12
Sam152 CreditAttribution: Sam152 as a volunteer and at PreviousNext commentedYou're welcome!
The instructions in #2846618: Unofficial content_moderation 8.2.x to 8.3.0 upgrade path say to dial back your schema version by using
drush ev "drupal_set_installed_schema_version('content_moderation', 8000);"
.It'd be great if someone had time to organise the instructions into the meta and make sure they were referenced from each issue summary.
Comment #13
DamienMcKennaJust to voice my concern - not having an upgrade path between minor versions is one thing, but making architectural changes that result in broken configuration and/or data without providing the necessary update scripts is a pretty user-hostile decision. Huge thanks to everyone working on this update script.
Comment #14
Rop CreditAttribution: Rop commentedI've tried the patch again, but it does not seem to fix the problem, as mentioned before.
I could be doing something wrong.
My situation is: I've started using content_moderation in 8.2.6 , I've then updated core successfully to core version 8.3.2 using the relevant patch from this (parent)issue. That worked fined. After this I've update core to 8.3.4 but despite apllying patch#9 I keep getting the errors about too long keys. (I've also tried 8.3.3)
The patch applies fine, it asks to overwrite the existing files, yet drush entity-updates fails.
Anyone an idea why it fails while others are succesfull?
Comment #15
fgm@roproprop : You need to run drush updb first. After that there remains nothing to update for drush entup.
Comment #16
Gábor HojtsyRe @DamienMcKenna:
Well, the goal with experimental modules is to move faster, which by definition means breaking things. Its like an 8.x-1.x-dev of a contrib module, anything may change. If developers would write an upgrade path then they would need to provide an upgrade path test (data dumps, etc), so moving fast is not really feasible anymore. What distinguishes experimental modules from non-experimental modules then? The only difference between a 8.x-1.x-dev contrib module and an experimental module in core now is where it is.
(Whether this is a good idea is a different question, but if the documentation or the warnings when enabling or having experimental modules enabled lead you to believe otherwise, then we need to fix those for sure).
Comment #17
xjmComment #18
xjmComment #19
Rop CreditAttribution: Rop commented@fgm I did run
drush updb
first. After that status still says entities need to be updated.I've now tried again doing only
drush updb
and I again get these errors:Comment #20
Sam152 CreditAttribution: Sam152 as a volunteer and at PreviousNext commentedComment #21
Sam152 CreditAttribution: Sam152 as a volunteer and at PreviousNext commentedYour schema version is at 8001 instead of 8000, you need to make sure 8001 runs by rolling it back. See the updated issue summary.
Comment #22
Rop CreditAttribution: Rop commented@Sam152 Thank you! that did the trick..all good now.
Sorry for the confusion.
Thanks for your work on this.
Comment #24
Sam152 CreditAttribution: Sam152 as a volunteer and at PreviousNext commented