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

  1. Backup your code and your database
  2. Test that you can successfully roll-back from the backup!
  3. 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.
  4. Clear your caches
  5. (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.
  6. Run the DB Updates, either by visiting /update.php, or using drush updb
  7. 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.

Comments

marcoscano created an issue. See original summary.

marcoscano’s picture

Issue summary: View changes
marcoscano’s picture

Issue summary: View changes
marcoscano’s picture

Issue summary: View changes

Added:
- A mention to the contrib media_entity_actions for sites that use actions
- A mention to encourage users to run drush mecu if they are on Drush 9, once that will be their only way of preventing the upgrade to break, in case of misconfiguration.

Narretz’s picture

> 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`?

marcoscano’s picture

Issue summary: View changes
seanb’s picture

This looks good, should we put this on the project homepage?

Narretz’s picture

I feel like there's an important step missing: remove the contrib "media" module before updating.

marcoscano’s picture

Re #8:

I feel like there's an important step missing: remove the contrib "media" module before updating.

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

akalata’s picture

Comment 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.

marcoscano’s picture

Issue summary: View changes

Re #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!

akalata’s picture

re: composer, looks like these were recently fixed:

And the updated text for #4 is much clearer, thanks!

marcoscano’s picture

I 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.

marcoscano’s picture

Issue summary: View changes

Now that #2919381: Don't cache media_entity_type_plugins landed, we don't need to manually clear caches before running the DB updates.

marcoscano’s picture

Issue summary: View changes

Re-wording the Media Entity Actions point a little bit, once it's not really optional.

marcoscano’s picture

Assigned: marcoscano » Unassigned
Status: Active » Needs review
StatusFileSize
new2.4 KB

I 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?

woprrr’s picture

+++ b/README.md
@@ -1,3 +1,40 @@
+Upgrade path from Media Entity to Media (core)
+----
 
...
+## Important information about the 2.x branch

I 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

# Upgrade path from Media Entity to Media (core)

This version of Media Entity is intended **only** to be used as a bridge to
move to the new "Media" module included in Drupal core (>= 8.4.0). While the
storage of media entities is the same, some aspects of the API have changed.
Because of that, if you have an existing site using Media Entity 1.x, you need
to follow the upgrade path indicated below in order to move to Media in core.

## Upgrade instructions

That seems more clear.

marcoscano’s picture

StatusFileSize
new2.35 KB
new423 bytes

There you go!

woprrr’s picture

Status: Needs review » Reviewed & tested by the community

<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.

johnpitcairn’s picture

If 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)

marcoscano’s picture

@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...)

marcoscano’s picture

@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.

bdimaggio’s picture

@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:

rat:s2923372 ben$ drush mecu
Symfony\Component\DependencyInjection\Exception\ServiceNotFoundException: You have requested a non-existent service "media_entity.cli". in [error]
/Users/ben/Sites/media-tests/s2923372/core/lib/Drupal/Component/DependencyInjection/Container.php:151
Stack trace:
#0 /Users/ben/Sites/media-tests/s2923372/core/lib/Drupal.php(158):
Drupal\Component\DependencyInjection\Container->get('media_entity.cl...')
#1 /Users/ben/Sites/media-tests/s2923372/modules/media_entity/media_entity.drush.inc(71): Drupal::service('media_entity.cl...')
#2 /Users/ben/.composer/vendor/drush/drush/includes/command.inc(422): drush_media_entity_check_upgrade()
#3 /Users/ben/.composer/vendor/drush/drush/includes/command.inc(231): _drush_invoke_hooks(Array, Array)
#4 /Users/ben/.composer/vendor/drush/drush/includes/command.inc(199): drush_command()
#5 /Users/ben/.composer/vendor/drush/drush/lib/Drush/Boot/BaseBoot.php(67): drush_dispatch(Array)
#6 /Users/ben/.composer/vendor/drush/drush/includes/preflight.inc(66): Drush\Boot\BaseBoot->bootstrap_and_dispatch()
#7 /Users/ben/.composer/vendor/drush/drush/drush.php(12): drush_main()
#8 {main}
rat:s2923372 ben$ drush cr
Cache rebuild complete.                                                                                                                    [ok]
rat:s2923372 ben$ drush mecu
✓ SUCCESS: All upgrade requirements are met and you can proceed with the DB updates.                                   [ok]
Drupal core is the correct version (>= 8.4.0). [8.4.2 detected]                                                                            [ok]
The contributed "Media" module is not installed.                                                                                           [ok]
All provider plugins and modules depending on media_entity are up-to-date.                                                                 [ok]
The "Media Entity Actions" module is available.                                                                                            [ok]
rat:s2923372 ben$

I.e., seems like adding a cache-clear instruction as suggested in #5 is warranted.

marcoscano’s picture

Issue summary: View changes

@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... :(

marcoscano’s picture

Status: Reviewed & tested by the community » Needs work
bdimaggio’s picture

I'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.

marcoscano’s picture

Issue summary: View changes
StatusFileSize
new2.99 KB
new2.16 KB

Thank 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.

  • marcoscano committed 7c5974d on 8.x-2.x
    Issue #2917099 by marcoscano, Narretz, akalata, woprrr, bdimaggio, seanB...
marcoscano’s picture

Status: Needs work » Fixed

Thanks everyone!

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.