Problem/Motivation
Core comes with some basic support for local files. With "local files" we usually refer to files that are stored on the same server as a given website is hosted from. That usually works fine for images. A lot of other media asset types are often remote nowadays. "Remote media" usually means media assets that are hosted on 3rd party services and also act as standalone resources on the internet, but they can incorporated in other resources too (usually by using embed codes). Examples of such remote resources are YouTube videos, Instagram photos, SoundCloud audio assets, Tweets, Facebook posts, ... Drupal core doesn't provide any support for those.
Contrib space has been solving this problem on its own for ages. In Drupal 7 and earlier we had many different solutions that approached it in a slightly different way. In Drupal 8 we standardised on a single solution. Media entity provides storage solution for local and remote media, handles metadata, thumbnails, business logic and validation in a standardised way. It was adopted by distributions like Lightning and Thunder and it is on a good way to become one of the most popular Drupal 8 modules.
Main problem in the current Drupal 8 situation it the lack of guidance from core. Since there is absolutely nothing in it contrib needs to make all decisions on its own. If, on the other hand, core would provide some basic solutions we could build on that in contrib with much more confidence.
Proposed resolution
Design core solution for handling of the remote media. Ideally rely on solutions that already exist in contrib space and build on top of that.
Remaining tasks
- Resolve #2669802: Add a content entity form which allows to set revisions , which is currently blocking this (media_entity depends on Entity API because of it)
- Move media_entity to core (more or less as it is), see #2831274: Bring Media entity module to core as Media module
- #2831936: Add "File" MediaSource plugin
- #2831937: Add "Image" MediaSource plugin
- Define default bundles (similar to what @Sam152 proposed in #2786785-48: Media in Drupal 8 Initiative) - part of the two "plugin" issues above for now
- #2831940: Create file field widget on top of media entity
- #2831941: [PP-1] Re-create Image field widget on top of media entity
- Ideally re-think field widgets UX and improve it along the way. There are some issues about that already. See: #2113931: File Field design update: Upload field.
- #2831943: Use "rendered media" (not links) as default media field formatter; add modal to configure the used media view mode
At this point we achieved core feature parity. In order to show what is supported by the media entity and to have an example implementation in core also:
- #2831944: Implement media source plugin for remote video via oEmbed
- Create field widget for it.
- Create formatters for it.
Finally, the upgrade path from contrib to core. @phenaproxima explained this in #18:
As per @Wim Leers' comment over at #2831936-148: Add "File" MediaSource plugin, let me explain a little about the plan for creating an upgrade path from Media Entity to core Media.
At the December 2016 media sprint in Berlin, we made a conscious decision to keep the data model of Media entities consistent between Media Entity and core Media. The purpose of this was twofold -- first, the data model was pretty tight as it was, and there wasn't really anything we felt needed to change about it. Secondly, we wanted to keep the upgrade path as smooth as possible, and messing with the data model is always a squirrelly proposition.
So really, the upgrade path from Media Entity to Media is mostly about API changes. You have to change any code that integrates with Media Entity to integrate with Media instead -- which have very similar APIs, though with some relatively minor differences. The biggest data-layer change involves the renaming of media_bundle config entities to media_type, but Media Entity 2.0 will provide an update hook to make that change.
Speaking of which -- Media Entity 2.0 is intended to be a simple upgrade path to core Media. That's all it is; just a bridge to get people (and contrib modules) onto core Media. It will provide no new functionality.
User interface changes
TBD
API changes
TBD
Data model changes
TBD
Comments
Comment #2
effulgentsia CreditAttribution: effulgentsia at Acquia commentedThank you for this issue!
The parent issue's summary says:
So, I'm wondering what the scope of this issue should be. Is it just to move Media entity to core, with more or less its existing feature set? Or should it also include changing Standard profile's
field.field.node.article.field_image.yml
andfield.field.user.user.user_picture.yml
fromto
?
And, if we do that, then a few questions:
"Select a field type"
drop down? Currently, within the"Reference"
group, the options are"Content, File, Image, Taxonomy term, User, Other"
. Do we want to keep "File" and "Image" as primary option labels, but change them to actually create an ER field for a Media entity type with "File"/"Image" bundle? But then, we'd still need a way to add an actual file/image field type, for example, as fields within the Media bundles themselves. Which could maybe be somehow buried within "Other", but currently "Other" takes you to an ER field configuration, so where can we branch to instead choose a file/image field type if that's what you want? Or do we want to totally deprecate file/image field types, and then let the field within the Media bundle be an ER field for a File entity type?field.field.user.user.user_picture.yml
field be a direct image field or ER field to a File entity rather than having to make it an ER field to a Media entity? In other words, should we leave such a capability around not only for existing sites prior to some future forced migration, but also for new sites as well?Comment #3
Sam152 CreditAttribution: Sam152 as a volunteer and at PreviousNext commentedI wrote about how some of the issues raised in #2 could be addressed.
Comment #4
slashrsm CreditAttribution: slashrsm at MD Systems GmbH commentedMy idea was to use parent issue to present general plan and to discuss technical details in sub-issues like this one. In order to achieve what this issue is proposing (and have feature parity with what core currently offers) I think we need to do the following steps:
1. Move media_entity to core (more or less as it is)
2. Define default bundles (similar to what @Sam152 proposed in #2786785-48: Media in Drupal 8 Initiative)
3. Create field widgets that work with "Image" and "Document" bundles and offer similar UX as current core's file and image formatters
3a. Ideally re-think UX and improve it along the way. There are some issues about that already. #2113931: File Field design update: Upload field. is one example.
4. Create formatters that offer feature partiy with current core's formatters.
At this point we achieved core feature parity. In order to show what is supported by the media entity and to have an example implementation in core also:
5. Create one remote video bundle. Probably YouTube. Could be implemented through oEmbed, which would technically support many more providers.
6. Create field widget for it.
7. Create formatters for it.
Either that or maybe limiting file/image fields to media entity bundles through
isApplicable()
.To keep things consistent I'd rather still go with media entity. Media can be excluded from the library in other ways. Media module adds a "Show in library" boolean field on the media entity for example which is on by default.
There is definitely some additional overhead, but I think that benefits outweigh it. This problem should also be mitigated by the fact that we now have entity (and super-duper render) cache in core.
Comment #5
slashrsm CreditAttribution: slashrsm at MD Systems GmbH commentedComment #6
Gábor HojtsyComment #7
seanBThis would be great! I can definitly see the benefit of a more flexible base for media in core. As far as I'm concerned this doesn't have to replace the file/image fields, as long as they all store the data as media entities. Just having a media field with different widgets for different use cases could work just as well though.
There could be some debate over the bundles and modules it ships with out of the box. Should remote media be optional or not? Currently all media entity types are submodules. Having everything as submodules is the best solution imho, but this makes the whole media suite really complex. This is something to think about when implementing this. It might be good to trade some flexibility to make everything simple to install.
Besides that, I think the entity type should just be named 'Media', since all other entities don't have the _entity suffix.
Comment #8
slashrsm CreditAttribution: slashrsm at MD Systems GmbH commentedTypes that core ships with don't need to be in submodules I think. Obviously there will be much more plugins available as contrib modules.
I agree with this. However, we shouldn't forget about sites that are already using media_entity today. We want to allow smooth transition for those.
Comment #9
slashrsm CreditAttribution: slashrsm at MD Systems GmbH commentedComment #10
slybud CreditAttribution: slybud commentedI am very happy to see this happening for better media management is clearly the next step to make Drupal core greater than ever.
As a project director with many big media projects developped and maintained (starting in D6, and now continuing on D8), I can only +1 this approach, which is scalable and more DAM-oriented, and on top of which we can build great UX.
Thanks @slashrsm and all the Media Entity/Initiative people involved for all the great work done so far and to be done !
Comment #11
Gábor Hojtsy@slashrsm started a child issue for this at #2831274: Bring Media entity module to core as Media module to work on completing the first step and make media entity available in core. The conversion of other things related to it will still need more issues, therefore this being a META now.
Comment #12
Gábor HojtsyComment #13
Gábor HojtsyComment #14
slashrsm CreditAttribution: slashrsm at MD Systems GmbH commentedLink to sub-issues
Comment #15
slashrsm CreditAttribution: slashrsm at MD Systems GmbH commentedComment #16
BoobaaComment #18
phenaproximaAs per @Wim Leers' comment over at #2831936-148: Add "File" MediaSource plugin, let me explain a little about the plan for creating an upgrade path from Media Entity to core Media.
At the December 2016 media sprint in Berlin, we made a conscious decision to keep the data model of Media entities consistent between Media Entity and core Media. The purpose of this was twofold -- first, the data model was pretty tight as it was, and there wasn't really anything we felt needed to change about it. Secondly, we wanted to keep the upgrade path as smooth as possible, and messing with the data model is always a squirrelly proposition.
So really, the upgrade path from Media Entity to Media is mostly about API changes. You have to change any code that integrates with Media Entity to integrate with Media instead -- which have very similar APIs, though with some relatively minor differences. The biggest data-layer change involves the renaming of media_bundle config entities to media_type, but Media Entity 2.0 will provide an update hook to make that change.
Speaking of which -- Media Entity 2.0 is intended to be a simple upgrade path to core Media. That's all it is; just a bridge to get people (and contrib modules) onto core Media. It will provide no new functionality.
Comment #19
Wim LeersLifted #18 into the IS for better discoverability.
Comment #23
moshe weitzman CreditAttribution: moshe weitzman as a volunteer commentedAny changes worth noting in the IS? I know we did Oembed since the last update.
Comment #24
phenaproximaComment #26
seanBSince #2831944: Implement media source plugin for remote video via oEmbed and #2996029: Add oEmbed support to the media library have landed, I think we can say remote media is now supported in core. Yay!