Background and Problem

Drupal core is an amazing content structuring tool with options to give rich structure to basically everything in the system. While Drupal core includes basic file and image support, it is a far cry from what a modern web system should support out of the box for media handling. External media cannot be embedded easily in core and media cannot be reused.

Due to very limited functionality provided by core it is also very hard for contrib to build on top of it. Core should provide base APIs, design patterns and paradigms to guide contrib work.

Proposed resolution

Provide a three-pronged implementation approach to media solutions, that involves three distinct groupings of functionality targeted at different use cases: Media Essentials, Extras and Extend. Three key objectives of this approach are to:

  • Involve new contributors to help existing media team members to create a Media Essentials suite as a minimum viable solution that provides a basic group of media functionality in Drupal 8 core by 8.3's release candidate. Solutions built as part of this should also provide solid foundations for all work that will be part of other two groups of functionality.
  • Media Extras suite to provide a group of rich media entity/editing functionality in contrib, which will eventually be integrated into Drupal 8 core once stable.
  • Enable new contributors to use the Media Extend functionality in Drupal 8 to integrate 3rd party media tools/Digital Asset Management systems (DAMs) within the overall ecosystem of Drupal media modules.

The overall experience for end users should be seamless regardless of which media modules their site happens to be using, and the implementation should be straightforward for site builders, architects and developers based on solid documentation in the Drupal 8 Media Handbook.

Process and where to find it

The initiative has weekly meetings in #drupal-media on Freenode IRC at 2pm GMT on Wednesdays.

Proposal roadmap

Media Essentials

This functionality will be the MVP for Media in Drupal 8 core. The objective of this MVP is to provide a simple media solution to make Drupal 8 easy to use out of the box for basic use cases. This MVP can ideally be achieved in a short time -- to be included in Drupal 8.3 RC1 (even as an experimental modules if needed to begin with). This goal can also ideally be achieved with the help of some of the new contributors/development efforts, assisted by the existing media team members.

For more information about this part of the plan see the related issue: #2825215: Media initiative: Essentials - first round of improvements in core.

Media Extras

Media extras will build on top of core to provide missing functionality such as multi-file upload, image cropping, advanced embedding, browsing and reusability scnarios etc. The target use case for this functionality will be small-to-large publisher or large enterprises with more complex media needs that the average user (but will fall short of requiring a DAM). It is our goal to move any relevant pieces of this group to core when they are stable enough.

Most of the modules to deliver this functionality already exists in Drupal 8 contrib; as such, integrating this into core will largely involve re-purposing existing modules and making necessary revisions to add this functionality to Drupal 8 core. Once modules in contrib are complete/stable, efforts will be undertaken to incorporate this functionality into future versions of D8 core (e.g., by Drupal 8.4 or 8.5 release candidates). This will effectively move parts of the Media extras suite into core and improve its feature set.

More advanced functionality will always (or for a longer period of time) reside in contrib (as with some other key/complex modules recently added to core - e.g., views, date, multilingual, etc.). This approach should be fine for the target users/use case, since they are more likely to be able to navigate implementing contrib modules. Contrib situation will also be easier to understand since core will provide much better guidelines and patterns.

All "80% use cases" functionality should eventually become part of core. Everything else that will cover very specific cases will most likely stay in contrib in the foreseeable future.

This effort involves the existing Drupal 8 media modules. Modules that are currently considered part of the Media extras are:

Not in scope

Media Extend

In addition to the above Media Essentials and Extras functionality, a third group of very advanced media functionality will also be available in Drupal 8 that will be focused on extending Drupal to integrate closely with third party media platforms -- particularly Digital Asset Management (DAM) systems (e.g., Bynder, Entermedia, Brightcove, ThePlatform, Ooyala etc.). The target use case for this functionality will be very large enterprises/publishers that will commonly rely on third party media tools to help manage large libraries of media assets (e.g., hundreds or thousands of media assets), which can often involve complex licensing, advertising or related functionality.

The architecture and timeline for this extendibility has yet to be determined. However, ideally this can be accomplished in a manner that allows for new contributors to help create the functionality in a consistent manner that allows for easy/consistent implementations with a consistent end user experience (i.e., in contrast to the stand alone/inconsistent implementation in Drupal 7 -- e.g., where implementations of tools such as Brightcove and Entermedia were largely stand alone solutions that weren’t able to be integrated into the media ecosystem). As an example, work has been underway to implement Brightcove functionality in Drupal 8, and ideally this implementation can be a seamless part of the overall media functionality/ecosystem in Drupal 8.

Media Extend will be based on tools provided in Media Extras enriched with heavily enterprise oriented and/or custom solutions.

Related work

The proposed outline above builds on some of the recent Drupal Media status updates (see Jul 2016 NYC Camp Media Sprint update or May 2016 DrupalCon Nola Media Summit Status Update Presentation or Sep 2015 DrupalCon Barcelona Media Status Update) and some of the Drupal Media Initiative planning. Thanks to Dave Reid and Janez Urevc for their leadership of media efforts in recent years, and the dedication and contributions of Aaron Winborn which helped lay the foundation for our Drupal 8 efforts.

Existing core features

  • File listing
  • Embedding of images (through upload)
  • File usage tracking
  • Image and file fields (with relevant widgets and formatters)
  • Alt and title fields on images
  • Description field on files

Open core issues

Contributed projects

Efforts involve and build on top of the existing Drupal 8 media modules.

Team and resources

Existing members of the Media initiative:

+ new contributors (critical for success of the initiative).

Our goal is to organize few focused week long sprints to push the initiative forward. It is absolutely crucial to have all of the core members attend those sprints. Details about dates, location, funding are still to be defined.

Signoffs

TBD

Signoffs needed

TBD

Signoffs given

TBD

Comments

Gábor Hojtsy created an issue. See original summary.

Gábor Hojtsy’s picture

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

Title: Media in Drupal 8 initative » Media in Drupal 8 Initiative
slashrsm’s picture

Media Essentials basically includes two things that were identified as potential candidates for 8.3.x:
- Field widget for image fields that combines (multi) uploading of new files and re-using existing ones (reusability)
- Embedding remote media in WYSIWYG through oEmbed ("url_embed in core")

I assume this should be the highest priority at the moment, since 8.3.x feature freeze will be here soon. Should we discuss details about this two features here or immediately open separate issues?

Media Extras part (inclusion of more contrib modules, more advanced workflows and support for remote media, ...) will be primary topic of my core conversation in Dublin. Let's open initial discussion about approach, solutions, functionality here and hopefully define more concrete plan for it by then.

webchick’s picture

One thing I think we talked about at some point was the idea of Media Essentials essentially being "make Drupal's media experience comparable with WordPress." This is important, because often WordPress gets chosen over Drupal because Drupal is perceived as extremely limited due to this and other key missing functionality. :( So to help with that, here are some side-by-side comparisons. (I'm using WordPress.com and Drupal 8.2.x-dev here.)

Default content editing page - WordPress

WordPress default content editing page

You can see that this page was definitely designed by someone with an eye for design. Functionality we are currently lacking (at least in the default install) such as Draft, Auto-Save, and post scheduling is front-and center. They also allow setting a location for the post and automatically display links to share the post on various social networks (Facebook, Twitter, etc.). The WYSIWYG is more fully featured, and includes buttons like "Proofread writing" and "Add contact form." WordPress also ships with a default field "Featured image" which displays the image in a well-designed way.

Default content editing page - Drupal Core

Drupal default content editing page

By comparison, Drupal's default content authoring experience is pretty sparse. We expose some techie terminology such as "URL Path Settings" and "Text format." There's no auto-update of anything in the sidebar as we're typing. We're missing some pretty key features that users expect, even "pretty paths."

Media insertion - WordPress

WordPress media insertion

Clicking the "Add Media" button in the far left of the WYSIWYG editor pops open this modal with a media library. You see a list of existing pictures to choose from, as well as the ability to add new ones, either with upload or via URL. Support for Audio, Videos, and Documents (pdf/doc) is included out of the box, and the library allows browsing by type.

Media insertion - Drupal Core

Drupal media insertion

By comparison, Drupal's add media button is only an "Image" button and only supports uploading new images, not selecting from existing, not pulling in via URL. We don't have a way to upload video, audio, nor documents. Drupal appears extremely limited by comparison.

Image insertion - WordPress

Multiupload with preview
Media Gallery insertion

Uploading a new image supports multiselect, you see the images uploaded into your library with a progress spinner, then thumbnails of each upon upload success. You then have the ability to put these into a gallery within your post, in sort of a "View lite" interface where you can select the layout (square tiles, slideshow), how many columns, whether or not to randomize, where to link, and what size of image to display. You see a real-time preview of whatever options you choose on the left.

Image insertion - Drupal Core

Image insertion in Drupal
Missing alt text error

By contrast, Drupal only supports single upload. No preview of the image. No ability to select its size. Alt text is a required field. You can set some minor adjustments, such as alignment and specify a caption, but there's no preview, so it's unclear what happens until after pressing Save.


I could keep going with this (and am happy to do so in sub-issues), but hopefully this gets across that "Media Essentials" alone is a huge pile of work, which consists of at least:

  • A well-designed media library accessible from the content authoring experience (as opposed to the admin backend)
  • The ability to add a media item by URL
  • The ability to select from an existing media item
  • Previews of new items
  • Support for audio
  • Support for video
  • Support for documents
  • Support for muti-upload
  • Media gallery support
  • The ability to select the image style of an image (thumbnail, etc.)

And so on. And if we start on this work in core a year or more from now, we're going to continue to severely harm adoption of Drupal. :(

andypost’s picture

Also I like to mention about need to ship default content #2094481: Support default content entities

platinum1’s picture

+1 for this project
@webchick Your pragmatic analysis of D8 and the competition is rather painful

Gábor Hojtsy’s picture

@slashrsm:

Media Essentials basically includes two things that were identified as potential candidates for 8.3.x:
- Field widget for image fields that combines (multi) uploading of new files and re-using existing ones (reusability)
- Embedding remote media in WYSIWYG through oEmbed ("url_embed in core")

I assume this should be the highest priority at the moment, since 8.3.x feature freeze will be here soon.

This is contrary to the issue summary I copied from the Media meeting notes which says Media Extras remains the highest priority (based on which we had some discussion recently). Which on would be then?

Gábor Hojtsy’s picture

Issue summary: View changes
yoroy’s picture

So webchicks list is a useful first stab at possible MVP features. Do we have other versions of this list? In IRC today we discussed the possibility of creating a little survey to prioritise the items in this list, but maybe something similar has been done before?

webchick’s picture

Yes, sorry. My list was intended to be "this is what Media Essentials needs to entail if competitive parity is a desired outcome" and definitely needs to be prioritized for MVP.

After bucketloads of searching and a hint about Prague from @yoroy, I managed to track down http://janezurevc.name/why-do-we-complain-about-drupal-media-solutions-a..., which has the following list, based on a survey of 200 community members back in 2013 (See DrupalCon Prague presentation):

  1. Embed media in WYSIWYG
  2. Re-use of media
  3. Site-wide media library
  4. Ensuring accessibility (alt/title tags, captions, subtitles, transcriptions, ...)
  5. Organize media in folders/categories
  6. Seamless integration with remote media (FTP, HTTP, YouTube, Flickr, ...)
  7. Search in media (in context of library and/or attach/usage workflow)
  8. Advanced formatting options/abilities (view modes, advanced file formatters, ...)
  9. Add/edit metadata on file level (fieldable files)
  10. Upload multiple files in one step

So I think it makes sense to start from this list. MVP might be the first 3 items (and really two because the first is done now in D8), maybe focused solely on images for now because that's what we have in core today?

phenaproxima’s picture

...maybe focused solely on images for now because that's what we have in core today?

IMHO, images are what the Essentials MVP should coalesce around, precisely because they're already in core, and it's probably the type of media that will be most heavily used in the majority of day-to-day scenarios. If we focus on delivering an MVP around images, then expand that later to include other media types, I think we'll very likely be able to deliver something terrific for 8.3. Otherwise I'm afraid we might get mired in unexpected details.

TL;DR: I'm in favor of quick wins for the MVP, building on what's already in core as quickly as practical. If oEmbed video would be a quick win, we can go there too but I'd vote we stick primarily to images and take on oEmbed only if we have time.

darketaine’s picture

I assume #11's priorities are both for media in WYSIWYG and out of it (instead of image field) right?

cosmicdreams’s picture

@webchick : per #11 :

5. Organize media in folders/categories

Does this mean impacting the physical location of the files? or assign taxonomy terms to files so that they can be properly sorted / filtered within the administrative user interface?

Or perhaps there's a post that explains the context of this list?

webchick’s picture

I'm just copying from the blog post verbatim so I couldn't really say. @slashrsm might be able to provide more context.

samuel.mortenson’s picture

I would say that given the immense popularity of https://www.drupal.org/project/imce, there is a definite interest in sorting Files. Drupal doesn't have visual content hierarchies (i.e. "Folders") like other CMSes, so we would have to think about the best way to accomplish this without sacrificing the level of abstraction File Entities have from how they're stored.

phenaproxima’s picture

Drupal doesn't have visual content hierarchies (i.e. "Folders") like other CMSes, so we would have to think about the best way to accomplish this without sacrificing the level of abstraction File Entities have from how they're stored.

I don't want to derail the thread, but what about using Taxonomy for this? Taxonomy terms can be organized into hierarchies very similar to directory structures, they can be easily attached to file entities just like any other field, and the hierarchy can be completely rearranged without affecting the file entities in any way.

andypost’s picture

@phenaproxima I see no reason to use taxonomy for folders because files already has directory structure
Also big trees of terms are mostly impossible to manage and has serious overhead

Gábor Hojtsy’s picture

Issue summary: View changes
slashrsm’s picture

Does this mean impacting the physical location of the files? or assign taxonomy terms to files so that they can be properly sorted / filtered within the administrative user interface?

This was not specified in the survey question. I considered this an implementation detail which was not important for my goal that I had with that survey - understanding which high-level features users need/want.

My opinion is that Taxonomy should be used for that. Drupal (any many other applications nowdays) abstract files from the actual filesystem being used to store them (just think about iOS, Android, ...). As soon as we depend on filesystem structure we coupled files with public/private files. If site is using Hash wrapper filesystem structure doesn't make absolutely no sense to user. Same could be the case with most of the remote wrappers such as S3.

yoroy’s picture

@slashrsm are you still happy with the items and their ordering in the list in #11?

Lets agree on those priorities first and then we can dive into the details of how to solve for those problems :-)

davidhernandez’s picture

RE #14 I would agree that for most people how the files are stored on the file system is an implementation detail. They just want to be able to organize files in some way in the user interface. Having used/managed multiple different DAM systems before, how the files are stored doesn't come up in conversation. In fact, I could see an advantage to not mimicking the same structure. You'd be exposing that structure publicly, which you may not want.

slashrsm’s picture

@yoroy: Based on my conversations with people it seems that those are still the most requested features.

On today's #drupal-media IRC meeting, we discussed #11 and came up with this as what to focus on for 8.3 (keeping numbers consistent with that comment):

1. Embed media in WYSIWYG (scoped down to just images). This is already in core, so not sure if there's more to do here for this item.

2. Re-use of media (scoped down to just images). We discussed that while we'd love this to be a View so that it could be customized by a site builder (like nearly every other administrative listing in core), that we would likely need to start with a non-View implementation, because embedding a View into a form in order to make the selection process work is still a challenge. Some follow-ups here include:
a) Creating a UX issue to design this library. Note that there's prior art here in https://www.drupal.org/project/media, including the screenshot at the top of that project page.
b) Creating an issue and sub-issues to track the blockers for making the library implementable as a View.

3. Site-wide media library (scoped down to just images). Can very likely be a view - it is not possible to reliably display images only with a view in core, contrib modules are needed for that at the moment. If 2. is implemented as a view they can share most of the logic. They should also share look & feel. We need to take this into consideration when working on mocks for 2.

6. Seamless integration with remote media (scoped down to just videos (not other media types) from Youtube and possibly other embeddable providers (not from FTP)). CKEditor Media Embed Plugin already implements much of this and @effulgentsia is working on porting that to a core patch and will open a core issue when further along with that. Another module to look at is URL embed. While it is unlikely that that module would be simple moved to core (dependencies to Embed module).

8. Advanced formatting options (scoped down to just selecting an image style, per #2061377: Allow image style to be selected in Text Editor's image dialog (necessary for structured content)).

That's it. The other items are probably out of reach for 8.3 core, but who knows: if someone is inspired to push core patches along for them, go for it.

In terms of 8.4 and further we'd like to do a bigger refactoring of media functionality in core. The functional goal of that is to:
- extend 1., 2., 3. from images only to any media
- support any local and remote media in 6.
- bring 8. beyond image styles (entity view display configuration)
- Solve other items in #11 (4., 5., 7., 9. and 10.)

It is not necessary that all this functionality will be ready for 8.4, but I am hoping for most of it (depends on available resources and funding). Solutions that will be introduced will be based on what is already available in contrib. Our main task is to figure out how to bring pieces from contrib into core in a sensible way and where to draw the line (what goes in and what stays in core).

Existing solutions like Lightning and https://github.com/drupal-media/media will be used as the inspiration during that process.

EDIT: @effulgentsia co-authored summary of today's meeting, which is one part of this comment.

webchick’s picture

Cool, that all sounds entirely sensible to me, and a great smattering of user-facing media improvements targeting 8.3. I'll try and spin off an issue for the media library design later today that compares/contrasts a few of the various approaches. (Unfortunately, the issue queue is terrible for this kind of ideation :\). I don't know where to begin with the issue for blockers to implementing the Media Library as a View, but +100 to getting that posted sooner than later; that could very well block acceptance of the media library as an 8.3 feature, so the sooner core folks can gain awareness of those issues and get started on addressing them, the better.

cosmicdreams’s picture

Should we put this "scope of work" into a separate issue so we can manage the initiative separate from the list of tasks that need to be completed?

Is that a good idea?

I would love to needle with small questions but don't want to flood this thread with them.

Where should the work be focused?

slashrsm’s picture

Issue summary: View changes

Few updates to the IS. Should better reflect what I believe we agreed in the past weeks of meetings.

slashrsm’s picture

Issue summary: View changes
webchick’s picture

Oh, regarding:

Embed media in WYSIWYG (scoped down to just images). This is already in core, so not sure if there's more to do here for this item.

If you compare WP/Drupal screenshots in #5, there's still quite a lot of feature gap remaining. Drag and drop image uploading, the ability to add images via URL, and multi-upload support stick out to me. As well as impressive visual design throughout.

webchick’s picture

@cosmicdreams: I think comments about overall scope / priorities of this initiative are fine here. If it's getting into nit-picky implementation details about one particular aspect, better to comment on the implementation issue (and/or the contrib issue queue if it's in contrib) for that thing specifically.

andypost’s picture

About image uploading there's a lot work done in #2113931: File Field design update

Wim Leers’s picture

#28:

Fabianx’s picture

#31: Multi-upload for images has been crucial for most larger clients I have worked with.

Disclaimer: For one of them I created file_dropzone module, which has been enhanced with some unfortunately proprietary code to make the UI much much nicer.

In our case it was for slideshows in three modes for the upload widget:

- Overview
- List
- Preview

with tabs to switch between them.

And it can be implemented efficiently together with 'alt' tags. In the end you just show a list with form fields, where you can quickly edit the alt text.

Basically you would have two modes:

- List mode (with details and easy alt text changes per picture) - can be any fields that are configured as 'quick edit' (or such).
- Overview Picture mode, where you just display one picture beneath each other.

That solves your 99% use case.

Also a media explorer with multi select capability is very important and drag and drop to any file field from a media explorer is also pretty important. (and we already support that as well in general as you can just set a 'fid' for a file field)

--

To the initiative and getting to at least Wordpress level: ++++++

webchick’s picture

Agreed both that multi-upload and accessibility are not mutually exclusive, and also that this is critical functionality, even for not larger clients. :)

As far as remote images, I wasn't suggesting hot-linking, necessarily. I agree that's problematic. Just the ability to *add* an image to Drupal that comes from an external URL (which then would presumably be downloaded in the background and treated as a normal local image upload; that's how sites such as Twitter, Facebook, etc. handle this AFAIK).

Wim Leers’s picture

I'd love to see all that, but I was just cautious about making that part of the MVP (both multi-upload with then a bunch of text fields, and the auto-fetching of remote images). That's all :)

slashrsm’s picture

Issue summary: View changes

Multi-uploads are supported in core today. It is not entirely obvious, but user can select multiple images when uploading them to a multi-value file/image field.

Few more updates of IS based on suggestions by @Gábor Hojtsy.

webchick’s picture

I think there's been some general confusion around "MVP" vs. what this initiative as a whole needs to entail. Sorry for my part in making that confusing.

To me, there are multiple scopes here we need to define:

1) What do we want to get into Drupal 8 core as a whole (most likely, 2+ years of development) that together falls under the "Drupal 8 Media initiative"?
2) What do we sequentially need to get done first, second, third because there are hard dependencies between them, and/or because they would have short-term high user impact?
3) Of that list, what do we realistically think we can get done for 8.3?
4) And as to the rest, what do we hope to achieve in 8.4, 8.5...?

In other words, in my view, this initiative template in the end needs to end up looking a lot like #2721129: Workflow Initiative, and encompass everything in #5 (plus whatever else isn't listed there), with target versions for various phases. It sounds like we're well on our way to defining the 8.3 chunk ("MVP"), which is great. I'm less clear on the part where Media Extras in contrib goes into core in 8.4/8.5... what does that mean, in terms of end-user impact? What features are we aiming to get into core first, second, third? What underlying architecture stuff is required, so we can start on that shortly? etc.

yoroy’s picture

Yeah, I think it'd be good to break out into another plan issue for the 8.3 MVP, we're refining what that is now which is relatively noisy for the goal of tracking the overall initiative in here.

webchick’s picture

Issue tags: +Drupal core ideas

Hi there! This is an issue that we'd ideally like to move to the new "Drupal core ideas" queue when/if #2785735: [policy, no patch] Agile process for bigger changes in core (Part A: Ideation) goes through (hoping for the next week or two). If you could read that issue and provide your thoughts on that, that would be great!

webchick’s picture

Sorry, ran out of time last week. Here it is! #2796001: [prototype] Create design for a Media Library

slashrsm’s picture

Issue summary: View changes

Created child ticket for remote media handling.

slashrsm’s picture

Issue summary: View changes

Added WYSIWYG embedding of any entity type child issue.

webchick’s picture

Project: Drupal core » Drupal core ideas
Version: 8.3.x-dev »
Component: other » Idea
Issue tags: -Drupal core ideas

Moving over to the new Drupal Core Ideas queue while we get this into shape.

weseze’s picture

The https://www.drupal.org/project/file_browser module seems to fix a lot use cases listed here. Has it been considered to just include that module?

alexpott’s picture

Issue summary: View changes
slashrsm’s picture

@weseze: file_browser has a lot of dependencies. It is not realistic to move all of them into core immediately.

barami’s picture

Hi..

In my experiance, organize media assets by taxonomy is better than organize with real system folder structure.
For purpose file_entity or media or other media management modules aim to manage media. Also they have features to re-use media assets.

If manager move or change category of media assets on folder structure based system, media display can broken at pages which manager does not know.

One media can used on several pages. And author of pages can different. If one author move media to other path, media display of another authors page will not found media position and broken.

I had aleady experianced with media browser few years age and posted issues to tracker. (#1939210: Moving files is dangerous..)

For the reasons, I prefer to organize media by virtual structure like taxonomy.

fkelly’s picture

Webchick's analysis at #5 pretty much sums the situation up. However, I'd note that we need to be able to walk and chew gum at the same time. I mean, we need to be able to both upload new images and edit ones that are already in a piece of content without going back through ckeditor config. If that's possible now, I don't see how.

Actually I do ... I use IMCE. It solves both the uploading issue AND the reuse issue. I solve multi-upload by using a FTP client. 150 images at a time to a photo gallery that's presented using the great D8 Juicebox contrib module. Reuse any of them in an article just by finding them in IMCE.

Sam152’s picture

I think the goals for core should be really narrow (and achievable). A super bare bones entity type for storing media, barely more than what entity API gives you out of the box and some slick view to browse and select these media items in different contexts. I also think it should be completely unopinionated.

The media entity shouldn’t have any concept of what an image is, what a video is, what a tweet is, what a (insert future thing we consider “media”). It should semantically just be a container for anything that a site decides to consider “media” and use all of our nice entity API concepts like bundles, fields and view modes to power the whole thing. Of course the standard profile would ship with an “Image” bundle, but the underlying system would be totally unaware of this.

This would serve as the building blocks in core that allow site builders and contrib solutions to store different types of media by way of the field API, media would just a bundleable entity after all. If down the track core decided a bundle that stored a Tweet was really important, a field type would be introduced and the standard profile might create the bundle for you. No part of core or otherwise would make assumptions about what bundles exist or not. This is largely how the current media_entity module works (correct me if I’m wrong).

I think the elephant in the room is that File entity is out there and it isn’t going away. Any file or image field is dealing with the concept of a file and not a media entity. I’m possibly getting ahead of myself by considering implementation details, but I think some design goals could be:

  1. Avoid leaving existing D8 sites behind.
  2. Avoid drastically changing existing site-building practices and mental models developed for site-building.
  3. Allow media entity to compliment existing core concepts, not replace them.
  4. Allow media entity to be installed/uninstalled, BC broken and upgrade path free without breaking anything.
  5. Have our cake and eat it to :)

If there was some implementation that satisfied these requirements, it would hugely reduce the friction for introducing a media entity into core.

This is all “back of the napkin” but perhaps an implementation might be as follows. Instead of making anything that interacts with a media entity do so via an entity reference, media entities could essentially “satisfy” other fields. That is, if you wanted an image for your article, it’s still an image field, but you have a media library powered by media entities that are available to populate those field values.

  • The “Image” media entity bundle could satisfy fields of type "image” and “file”.
  • The “document” media entity could satisfy fields of type “file” and where allowed uploads formats => PDF, TXT.
  • The “slideshow” media entity could satisfy fields of type “image” with cardinality > 1.
  • The “Foo” media entity could satisfy fields of type “Bar” and “Baz”.

Once a field has been satisfied by a media entity a record would be stored that such a transaction took place. For our image field example what would be stored in the fields schema (or elsewhere) is:

field_image:
  fid: file:123
  satisfied_by: media_entity:1

Media entity 1:
  field_some_image_field
    fid: 123

At this stage, our generic media entity can go and be used anywhere on our existing D8 sites, site builders do not change their approach to modelling things. The media library could be enabled at the start of a project, the end, disabled down the track, uninstalled and reinstalled when core decides to make a change in the experimental phase. In the article content type in standard the current relationship is:

  1. Article has an image field.
  2. On the article entity display the image style is set to “medium”.

Using an entity reference, this would likely become:

  1. Article has an entity reference field.
  2. The entity reference field is configured to display “rendered entity” and view mode “foo_mode”
  3. The media entity has an image field.
  4. On the media entity display, “foo_mode" the image style is set to “medium”.

It’s a different experience and most sites would likely see both approaches come about if media was integrated in such a fashion.

From an input widget point of view, the media browser would only serve to decorate existing input widgets. Alongside the standard file input, you would have a button to browse the media library, select a media entity to satisfy the field and the standard widget would be filled. The same would apply to fields of any type. Field type “foo” on media entity “bar” could satisfy any “foo” field on any other entity type.

This approach means we aren’t pulling out any existing part of core, replacing any concepts or approaches and overall reducing the friction for achieving this functionality. The initiative would thus look like:

  1. Introduce the unopinionated entity type in core and a slick browser/input widget for those entities (add some config for standard profile)
  2. Let contrib do its thing by way of new field types and field formatters (is core really going to support code that is aware of YouTube, slick carousel, ... (new slideshow library released in a month).

Happy to hear thoughts on this, or be told to buzz off :)

wolffereast’s picture

Issue summary: View changes
John Pitcairn’s picture

@Sam152: I'd be wholly in support of an intermediate media entity.

The simplest reason is so that embedded media can have different local properties in each place it is used. Different alt text, different title, different longdesc ... these should not be tied to the source media. Sure, you could set defaults on the source at upload or in some global edit mode, but those must be overridable per-instance. And I want to be able to grab those local properties in a View of the embedding content.

In D7, for images, I've been accomplishing this with a field collection wrapping a Media image field supported by a lot of custom code, which I'd love to leave behind. For some sites I also need to be able to force users to first add images to content via that field, then allow them to embed only those added media into the wysiwyg. I have a barely adequate custom wysiwyg/ckeditor plugin that handles this.

I'd definitely want to be able to use all the existing entity-referencing goodness that is available. I'm thinking of Inline Entity Form in particular, but also Entity Reference with a rich media selection View (see #2174633: View output is not used for entityreference options for a regression, RTBC). So whatever is used for media editing, selection, embedding etc should be reasonably granular and swappable, and play nice with existing entity ecosystem modules.

lieb’s picture

Here is some feedback from a long time site builder, part local developer, but not a contributor. After reading this thread it really seems like we take 2 steps forward and 3 steps back. We had most of the "essentials" and "extras" in Drupal 7 with the media module, although on the large scale deployments I was involved in it took many months to get this working, and it was somewhat fragile.

Then for Drupal 8 there was this big move to abstract everything to the nth degree, starting with a very basic file entity, and then extending that until at some point you had an image entity, then some views for a browser, etc. Although all of this stuff currently exists for Drupal 8, I for one have not been very successful in getting near the feature parity we had in D7.

I know there is an overarching desire in the Drupal community to "do it right" from a technical standpoint. While this is admirable I believe it is one of the things that holds Drupal back. My feeling is that in the Wordpress community "do it right" means "let's deliver the functionality that our users want, and provide a really nice and easy UI", and that they are less concerned with the technical implementation. Maybe this will come back and bite them someday, I cannot say. But I can say that in these days of continuous integration, and agile development it is okay to take a chance and get the features built, even if you know you may have to go back later and rework some of the plumbing.

At any rate I am very happy to see this moving forward. I do agree that decent media handling is probably the highest priority for Drupal right now.

sarathkm’s picture

Adobe Experience Manager has great media handling toolkit.

Maybe some inputs from there too while moving on with this core process initiative will be beneficial.

charly71’s picture

Cool.. I subscribe the list of features in comment #11 !

fenns’s picture

I had the great fortune of working with lieb (#51), side-by-side, for several years in our organization's enterprise level Drupal distribution.

I'm in agreement with him that many of our media management goals in Drupal 7 were finally met with the Media module in terms of things like bulk uploads, a nice, centralized library and a media browser, the ability to add some metadata (especially the alt tag), and finally, a record of usage. As someone who works both as a systems-wide architect and heavy contributor there were definitely some gaps in terms of the user experience, though.

Looking forward to Drupal 8, we're really excited about the attention that media is getting. The following items are things that different users in our community have shown a strong desire for. Some of these things, I've seen, are in progress already (consider these validation of your targets). A few of these things are items that might be worth consideration down the road. I've split these up between things our entry-level users versus our high-level users are hoping for, other than that, these are in no special order.

Items of importance for our most entry level users include:

  • The ability to bulk upload, both into a centralized library and on an entity-by-entity basis
  • The ability to apply some level of processing (rotation, selection based cropping, etc) on an image during upload
  • The ability to create an arbitrary file link to a document within the rich text editor (select some text, link to a file in the media browser, text doesn't change when the link is applied)
  • The ability to easily position an image in a rich text editor
  • The ability to add a nicely formed caption on an image

Items of importance for our higher powered users include:

  • A robust media management tool that shows us if files are actually being used somewhere, whether in some type of filefield or in CKEditor
  • The ability to configure either a notification of unused media or an auto flush of unused media after a selected time period
  • The ability to perform bulk owner assignment and delete operations
  • Strong Views integration
  • The ability to somehow (eventually) integrate OG or Group level permissions

I hope this has been of some help. Thanks for all of your hard work on this!

theuxguy’s picture

We did a project for a News Publishing agency recently and had to redo the entire Image Upload workflow because the built-in one wasn't very user friendly. Attaching some screenshots here. I am really interested in this initiative. I think my experience as a User Experience Designer can solve this problem.

For now, attaching some screenshots of what we did for the client (modified and branding is removed). However, i think it will require a bit more refining to make it work for all types of users. I will be working on that and will upload some updated media upload workflow later.

slashrsm’s picture

@theuxguy May I ask if this was D7 or D8? How did you technically implement multi-file metadata editing on one page? Did you use multiform module? Entity forms? Something completely custom?

theuxguy’s picture

@slashrsm, this was done on D7. The entire dashboard was redesigned to make it work for the news-publishing workflow. We had to do that using Angular JS (Headless Drupal)

slashrsm’s picture

Issue summary: View changes

Updated IS based on the discussions and conclusions achieved at DrupalCon Dublin. Borders between Essentials and Extras is now blurred a bit. I tried to update the plan to reflect that but to still make sense. Any suggestions are welcome.

"Team and resources" section still needs work. We should list names of main contributors in my opinion. I was also not sure what should be in "Signoffs" sections. I could use some help on that. Same goes for "Not in scope".

Gábor Hojtsy’s picture

Issue summary: View changes

Fixed some grammar in the start of the summary.

Gábor Hojtsy’s picture

Issue summary: View changes

Fixed list of options for embedding.

slashrsm’s picture

Issue summary: View changes
slashrsm’s picture

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

Issue summary: View changes
Status: Active » Needs review

Fix one more typo. I think this can move to RTBC once we fill in the missing list about people and maybe the signoffs. Not sure who's signoff would be needed here yet.

slashrsm’s picture

Issue summary: View changes

Added team members. Is just a list enough or we need to define roles too?

slashrsm’s picture

Issue summary: View changes
slashrsm’s picture

Issue summary: View changes
effulgentsia’s picture

Status: Needs review » Reviewed & tested by the community

Great issue summary and all the thinking behind it. Thank you!

This issue is currently assigned to the "Idea" component. #2785735: [policy, no patch] Agile process for bigger changes in core (Part A: Ideation) contains discussion on the difference between an Idea and a Plan. Other than that discussion issue, the first Idea issue to have reached a Fixed status is #2809635-12: Create experimental installation profile, and in the call that led to that comment, @yoroy framed the difference as an Idea needing to answer "Why?" and "What?" whereas a Plan needing to answer "How?".

In my reading of this issue's summary, the "Why?" (for Media Essentials) is:

  • Provide out of the box support for adding remote media (e.g., YouTube videos) to content.
  • Provide out of the box support for referencing the same media asset (whether a local file/image or remote asset) from multiple places (e.g., from 2 different nodes).
  • Implement the above in a way that provides a foundation for contrib to add more functionality cleanly and interoperably.

And the "What?" (for Media Essentials) is:

  1. Add a Media entity type to core: #2801277: [META] Support remote media assets as first-class citizens by adding Media Entity module in core.
  2. Change Standard profile's image fields (i.e., article image and user picture) to media fields (ER fields referencing media entities): #2801277-2: [META] Support remote media assets as first-class citizens by adding Media Entity module in core.
  3. Add a Media Library, implemented as a View: #2796001: [prototype] Create design for a Media Library.
  4. Integrate the Media Library into the ER selection for media fields: [Needs issue created].
  5. Integrate the Media Library into a CKEditor plugin for embedding media within text fields: #2801307: Support WYSIWYG embedding of entities other than files.

IMO, these make for a great Idea, and there's been great discussion about it, so marking it RTBC for committer review.

If/when this gets approved as an Idea, we'll need to decide whether to continue this issue as a Plan issue, or make a new Plan issue for it. That will then need to answer "How?". For that, I have some questions about performance and UX (see #2801277-2: [META] Support remote media assets as first-class citizens by adding Media Entity module in core). And also a question about #3/#4 above: specifically, what's needed in order to make that actually work? Since at one point, I think someone brought up that Media in contrib has run into several Views limitations with respect to Form integration when trying that. Additionally, when a Plan issue, this will need the "Needs framework manager review" and "Needs release manager review" tags, but I'll wait until this is a Plan issue before adding those.

Thanks again for everyone's great work on this so far. I'm excited to see the idea getting increasingly refined, and looking forward to it progressing as a plan and implementation.

webchick’s picture

Status: Reviewed & tested by the community » Needs work

We discussed this on our bi-weekly Ideas queue call today!

In terms of the overall idea, there was unanimous, enthusiastic support for the "Media Essentials" part, summarized in #67. The "Media Extend/Extras" stuff, however, would be good to split out into its own Idea/Plan(s), since it is less fleshed out and more long-term, so we can't provide sign-off on that at this time.

So from the Ideas perspective of Media Essentials, this Idea is approved! We now need a Plan issue for the Media Essentials part only for 8.3/8.4 (meaning, copy/paste the relevant parts of the issue summary to a new issue and mark it RTBC :)), including a recommendation for an initiative coordinator (who's willing to fulfill the cat-herding these requirements), which Dries can take a look at. Once that's approved we can move this to an "official" core initiative!

slashrsm’s picture

Issue summary: View changes
Status: Needs work » Needs review
Related issues: +#2825215: Media initiative: Essentials - first round of improvements in core