Follow-up to #2825215: Media initiative: Essentials - first round of improvements in core
Follow-up to #2831274: Bring Media entity module to core as Media module

Once the Main media patch #2831274: Bring Media entity module to core as Media module will be in. I'm creating this issue to track the follow-up issues for rest of the contributed projects.

Media Provider Modules

Media provider modules

There are already several media provider modules that extend functionality of
Media entity:

  1. Image #2831937: Add "Image" MediaSource plugin / #2883452: Provide upgrade path for media_entity_image config changes to Drupal core
  2. Audio #2864024: [PP-2] Audio Port to the proposed Media core module API
  3. Slideshow #2869308: [PP-1] Slideshow Port to the proposed Media core module API
  4. Deprecated: Embeddable video was replaced with Video embed field.
  5. Twitter #2869157: [PP-1] Twitter Port to the proposed Media core module API
  6. Instagram
  7. Document #2883449: Provide upgrade path for media_entity_document config changes to Drupal core / #2870140: [PP-1] Document Port to the proposed Media core module API
  8. SlideShare
  9. Soundcloud
  10. Spotify
  11. Video (local)
  12. Tumblr
  13. Facebook #2869021: Facebook Port to the proposed Media core module API
  14. Woodwing Elvis DAM
  15. Media Entity Flickr
  16. Lightning Media Flickr
  17. Audio embed field (sandbox)
  18. Inline Entity Form
  19. Devel
  20. Plugin
  21. Pinterest
  22. Riddle 2.x (has a submodule with media_entity integration)
  23. lightning_media_pinterest
  24. lightning_media_facebook
  25. lightning_media_imgur
  26. lightning_media_flickr
  27. lightning_media_d500px
  28. lightning_media_soundcloud
  29. lightning_media_tumblr
  30. lightning_media_spotify
  31. media_entity_googledocs

Comments

naveenvalecha created an issue. See original summary.

xjm’s picture

Title: [PP-1] Plan for Contributed Modules after 2831274 » [PP-1] Plan for contributed modules with Media Entity API in core

Clarifying what the node ID is for those who don't have it memorized. Thanks @naveenvalecha!

naveenvalecha’s picture

Issue summary: View changes

Added issue link for facebook and media_entity_audio

Thanks @xjm Could we get the reviews on the recent ports media_entity_facebook and media_entity_audio

//Naveen

naveenvalecha’s picture

Issue summary: View changes

Added child issues for media_entity twitter and media_entity_image

//naveen

naveenvalecha’s picture

Issue summary: View changes

Added inline_entity_form, Devel and Plugin module to the list.

//Naveen

naveenvalecha’s picture

Issue summary: View changes
naveenvalecha’s picture

naveenvalecha’s picture

Issue summary: View changes

Added link of media_entity_document issue #2870140: [PP-1] Document Port to the proposed Media core module API

//Naveen

chr.fritsch’s picture

naveenvalecha’s picture

naveenvalecha’s picture

Issue summary: View changes

Converted unordered list to ordered list.

naveenvalecha’s picture

axel.rutz’s picture

Hi all, i boldly added #2879969: Make Media field mappings reusable between media types here as i feel this will be an issue and i might put some effort into it.
Please can somebody who knows the media issue space and agenda better tell what's a good place for it - thanks!

EDIT: Picked the wrong issue, moved to #2825215: Media initiative: Essentials - first round of improvements in core

naveenvalecha’s picture

Title: [PP-1] Plan for contributed modules with Media Entity API in core » Plan for contributed modules with Media Entity API in core

This is no longer a blocker issue.

naveenvalecha’s picture

Status: Postponed » Active

This issue is unblocked now as the main patch #2831274: Bring Media entity module to core as Media module is in :)

//Naveen

seanB’s picture

Issue summary: View changes
Gábor Hojtsy’s picture

SeanB just wrote this in the media meeting on this topic: We need to target media_entity / media_entity_document and media_entity_image as those will be the modules we actually will deprecate. Other modules will probably need to release new versions to adapt to the new API. I think that is mostly what is going on in this issue but more related issues would need to be opened for sure.

marcoscano’s picture

Just extending from #17 on possible scenarios, with the purpose of being explicit and having everyone on the same page :)
(I believe we are, but as they say... "better explicit than implicit")

I'm assuming all scenarios below are happening when Drupal 8.Y is released, where "Y" here is the version from which we will start saying "don't use media_entity contrib anymore because media is in core now". Based on https://www.drupal.org/node/2825215#followup-roadmap I "think" this will be 8.5, but TBH I'm not 100% sure about the consensus here. This would be also the point in time where we start officially considering media_entity (& co.) deprecated.

Scenario 1: A new site is built after 8.Y

- The site uses / wants to use:
-- media entities
-- files
-- images
-- "foo" media source (with stable 2.x branch)
-- "bar" media source (without stable 2.x branch)

This site is strongly encouraged to use the media-in-core path and contribute to port the source plugin "bar" during the site's development effort.

Scenario 2: An existing site uses media entities and needs to upgrade to 8.Y due to a security release

- The site uses:
-- media_entity
-- media_entity_document
-- media_entity_image
-- "foo" media entities (with stable 2.x branch)

This site will need to follow the upgrade paths:
#2880334: Add update path of media_entity config changes from 1.x to core media module
#2883449: Provide upgrade path for media_entity_document config changes to Drupal core
#2883452: Provide upgrade path for media_entity_image config changes to Drupal core
+ whatever the "foo" source plugin has defined in its upgrade path.

Scenario 3: An existing site uses media entities and needs to upgrade to 8.Y due to a security release

- The site uses:
-- media_entity
-- media_entity_document
-- media_entity_image
-- "foo" media entities (with stable 2.x branch)
-- "bar" media entities (without stable 2.x branch)

This site has then 2 options:

3.a) Stick with media_entity contrib
In this case the site will upgrade core to 8.Y but will continue using the whole set of solutions from contrib (i.e. media_entity 1.x). This example shows why it is important to ensure that whateaver is added to 8.Y, it shouldn't break existing sites that want/need to keep using contrib media_entity modules for some time.

3.b) Upgrade "on their own"
Many sites may be able to:
- have their teams to develop their own upgrade path to "bar" entities
- use an untested / non-stable patch from the "bar" issue queue
- even maybe drop entirely the "bar" entities from their site
so they can still fall into scenario 2 above and upgrade everything. IMHO this shouldn't be considered the rule though.

Does this make sense? Have I missed any other possible scenario?

marcoscano’s picture

Oh there is indeed another one:

Scenario 4: An existing site uses the D8 "media" module itself and needs to upgrade to 8.Y due to a security release

- The site uses:
-- The D8 version of media
-- media_entity
-- media_entity_document
-- media_entity_image
-- "foo" media entities (with stable 2.x branch)
-- "bar" media entities (without stable 2.x branch)

This site unfortunately won't be able to opt to something like 3.a, because in 8.Y core media will have taken the namespace of the media module. The only option this site has will be to uninstall the module and delete it from the codebase before upgrading to 8.Y.
This sounds a big deal, but should be mitigated by the following:
- There was never a stable release of media for D8 (only -dev), and its usage doesn't seem to indicate there was time enough for it to be adopted by many real sites
- Media in D8 was mainly a glue module that provided some default configuration, some CSS, JS and other tweaks. Once it relied always on the media_entity(_*) suite, all storage layer and configuration will still be compatible to the new media-in-core.
- Because of the point above, all upgrade paths indicated in Scenario 2 would be directly applicable here, and the additional work would be to:
-- effectively uninstall / remove the media module itself
-- follow all upgrade paths from Scenario 2 for the config renaming and API code changes
-- potentially apply back (in custom code or by some additional contrib module) the tweaks that the "glue code" implemented in the media module.

seanB’s picture

Scenario 3 is the most problematic obviously. There could be a conflict when we want people to use media instead of file and image (and we change things in core with this in mind) but people not being able to remove media_entity yet because of contrib modules not being ready.

This is something we should discuss some more. If we need to wait with the deprecation of media_entity until all contrib modules have an upgrade path, this significantly increases the amount of work. On the other hand we can't force people to upgrade when we know their site will break if they use certain modules.