Once the upgrade path is stable and well tested, there are several places that need to be updated with that information:
- The module's readme file
- The project page
- The handbook
- ??
We can use this issue to draft the process that will work for most sites, trying to take into account all possible scenarios. Here below a first draft we can iterate on:
UPGRADE INSTRUCTIONS
- Backup your code and your database
- Test that you can successfully roll-back from the backup!
- Upgrade the codebase with:
-
- Core: >= 8.4.x
- Media Entity: 8.x-2.x
- All media entity providers: 8.x-2.x (or use patches from #2860796: Plan for contributed modules with Media Entity API in core). Note that the modules Media Entity Image and Media Entity Document, if present, don't need to be updated. Their configs will be updated by the main Media Entity updates.
- All modules that depend on or interact with Media Entity: 8.x-2.x
- The new contrib module Media Entity Actions: 8.x-1.x
- If your site uses media entities with the "Generic" provider, make sure you download to your codebase the Media Entity Generic module as well.
- Clear your caches
- (Optional) Check that all requirements for the upgrade are met with
drush mecu.
IMPORTANT: Please note that if you are running DB updates with Drush 9 (between 9.0.0-alpha1 and 9.0.0-beta7), you are strongly encouraged to use this command prior to running the updates. Drush 9 will not run the requirements validation and will try to run the updates even if your site has some of the requisites misconfigured. Executing the updates in that scenario will likely break your site. This was fixed in Drush 9.0.0-beta8. Drush 8 users don't need to worry about this. - Run the DB Updates, either by visiting
/update.php, or usingdrush updb - Double-check that the Media Entity module is uninstalled, and remove it from the codebase. Remove also Media Entity Image / Document, if present.
Known issues concerning the upgrade path:
- If your existing site relies on the EXIF image metadata handling, please check #2927481: Integrate sites relying on EXIF metadata handling in the media upgrade path before proceeding with the upgrade.
- Entity Browser has a 2.x branch that has new features for media in core, for example the widget that was formerly present in the "Media Entity Image" module. However, if you intend to upgrade Entity Browser to the 2.x branch, you should do that only after performing the main Media Entity upgrades. There is currently a bug preventing the Media Entity upgrade if the Entity Browser 2.x is present in the codebase.
| Comment | File | Size | Author |
|---|---|---|---|
| #27 | interdiff-18-27.txt | 2.16 KB | marcoscano |
| #27 | 2917099-27.patch | 2.99 KB | marcoscano |
| #18 | interdiff-16-18.txt | 423 bytes | marcoscano |
| #18 | 2917099-18.patch | 2.35 KB | marcoscano |
| #16 | 2917099-16.patch | 2.4 KB | marcoscano |
Comments
Comment #2
marcoscanoComment #3
marcoscanoComment #4
marcoscanoAdded:
- A mention to the contrib
media_entity_actionsfor sites that use actions- A mention to encourage users to run
drush mecuif they are on Drush 9, once that will be their only way of preventing the upgrade to break, in case of misconfiguration.Comment #5
Narretz commented> Clear caches AFTER the code has been updated, but BEFORE running the DB updates
That means it is vital to first update the code, then clear the cache, and the run the db updates?
In that case, maybe a note could be added that you should use drush `drush pm-updatecode` instead of `drush pm-update`?
Comment #6
marcoscanoComment #7
seanbThis looks good, should we put this on the project homepage?
Comment #8
Narretz commentedI feel like there's an important step missing: remove the contrib "media" module before updating.
Comment #9
marcoscanoRe #8:
That's an interesting point. In principle, I think this information doesn't strictly belong to these instructions, once the upgrade path itself doesn't support the D8 contrib media module (The module should just be completely uninstalled and removed from the project before upgrading).
But I do see value in maybe adding a separate note at the bottom indicating that users in that scenario won't be able to upgrade before uninstalling the contrib module. The update itself won't break, it will just abort at the requirement's check phase if the site has contrib media while running DB updates.
For the record, d.o usage reports indicate that the number of potential users affected by this is significantly smaller than users affected by a normal upgrade from Media Entity:
Media 8.x: ~300 sites
Media Entity 1.x: ~18,000 sites
Comment #10
akalata commentedComment on #4, bullet 3: I've been trying to find 2.x branches for media_entity_document and media_entity_image, since they aren't on the list of patches.
#2860796-18: Plan for contributed modules with Media Entity API in core mentions that these modules will be handled in media_entity, but it's not at the top of the issue as part of the table.
I'm not sure that we can call out these modules as "don't worry about these" either, because if you're using composer to manage things you'll need to update media_entity_image 8.x-1.x #2916854: Allow inclusion in a Composer-built code base alongside Media Entity 1.x in order to be able to get media_entity 2.x via composer.
media_entity_document will need a similar update as well.
My preference would be, for consistency's sake, to create 8.x-2.x branches of both these modules with the composer.json updates.
Comment #11
marcoscanoRe #10:
You are right! I have included a description to that point mentioning that these 2 providers don't need to be updated. The config changes for these media types are handled by the main Media Entity upgrade path (2.x branch), so there is definitely no need for downloading 2.x branches of these 2 modules. Do you think the new edited text is enough to prevent confusion?
I'm not sure to fully understand the composer problematic. Could you perhaps indicate some specific example where the problem exists?
Thanks!
Comment #12
akalata commentedre: composer, looks like these were recently fixed:
And the updated text for #4 is much clearer, thanks!
Comment #13
marcoscanoI have updated the Media Entity project page with these upgrade instructions. I'll make sure whatever changes we do here in this draft are also reflected there.
Comment #14
marcoscanoNow that #2919381: Don't cache media_entity_type_plugins landed, we don't need to manually clear caches before running the DB updates.
Comment #15
marcoscanoRe-wording the Media Entity Actions point a little bit, once it's not really optional.
Comment #16
marcoscanoI have updated the ME project page and the documentation page with the same text.
With this patch we have the same info on the module's README.md file.
With that I believe we can call this Fixed?
Comment #17
woprrr commentedI think this part is not really lisible because that display two *BIG* title at same level and strike mes eyes :D
What do you think about write directly
That seems more clear.
Comment #18
marcoscanoThere you go!
Comment #19
woprrr commented<3 LGTM we can call this RTBC I think.
Just I add mention of https://www.gitbook.com/book/drupal-media/drupal8-guide/details That's should be great to not forget this page and add mentions of Upgrade path.
Comment #20
johnpitcairn commentedIf you have deleted the core default "medium" image style, you will need to re-create it before running the DB updates, because media config has a dependency on it.
If the image style is not present, an error is thrown during
media_entity_update_8201:Configuration objects provided by media have unmet dependencies: core.entity_view_display.media.image.default (image.style.medium)
Comment #21
marcoscano@John Pitcairn thanks for reporting this!
Can you please indicate how you managed to delete the thumbnail image style?
I think we should indeed make sure the upgrade path accounts for that, probably re-creating the image style that was deleted before proceeding with the updates. However, I'm having a hard time reproducing a testing scenario for that. (see #2923354: Impossible to remove the Thumbnail image style, which may be a different bug, in any case...)
Comment #22
marcoscano@John Pitcairn sorry I realize I had misread your comment. You were referring to the "medium" image style, not "thumbnail".
So yes, the "medium" can be deleted and we need to handle that during the upgrade path. I opened #2923372: Upgrade fails if site has "medium" image style missing for that.
And besides that, there is the other bug (#2923354: Impossible to remove the Thumbnail image style), which crashes the site when you try to delete the "thumbnail" image style.
Comment #23
bdimaggio@marcoscano FWIW, I had these results after updating Drupal from 8.3.7 -> 8.4.2, updating media_entity to 8.x-2.x, and adding media_entity_actions:
I.e., seems like adding a cache-clear instruction as suggested in #5 is warranted.
Comment #24
marcoscano@bdimaggio you are right, Drush 9 will discover the new cli service, but Drush 8 won't, so for a different reason, it seems that we will need to keep the manual cache clearing as part of the process... :(
Comment #25
marcoscanoComment #26
bdimaggioI've run some test upgrades and they conform perfectly to the instructions you have here, @marcoscano. As far as I'm concerned, this should be RTBC, but I'm not making the state change myself in case there's something I'm missing.
Comment #27
marcoscanoThank you @bdimaggio for double-checking this!
I believe we are in a point where the steps are quite well-defined, and we can call this fixed.
I have updated the other pages that have the same information, and added the list of steps to the readme file as well.
If we find anything that needs improvement, I believe we should open follow-ups to fix those.
Comment #29
marcoscanoThanks everyone!