Media in Drupal 8 Initiative

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.

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

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

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

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

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

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

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

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

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

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?

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?

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

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

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

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

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.

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.

@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

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.

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

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.

@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: [drupalImage] Optionally apply image style to images uploaded in CKEditor 5).

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.

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.

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?

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

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.

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

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

#28:

• Drag and drop image uploading: a patch has been in progress for a while now: #2560457: Support drag-and-drop image uploads in CKEditor
• The ability to add images via URL: this is already supported in core. It's just discouraged… because it's a bad practice. Hotlinking images is not something you should do, even more so because it can result in the image disappearing. In any case, if you disable "image uploads" for a text format, that is what you get. AFAICT you're asking to allow users to paste image URLs even when image uploads are enabled, which is something we also have an issue for: #2510394: [drupalImage] Setting to still allow linking to an image by URL even when uploads are enabled
• Multi-upload support is tricky, because most systems that support this for images simply don't bother with alt. Which is why — for images — it's probably better to not support this.

#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: ++++++

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

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

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.

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.

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.

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!

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

Created child ticket for remote media handling.

Added WYSIWYG embedding of any entity type child issue.

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

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?

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

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.

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.

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

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

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.

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.

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

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!

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.

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

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

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

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

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: [META] Support WYSIWYG embedding of media entities.

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.

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!

Moved media essentials to a separate issue: #2825215: Media initiative: Roadmap

I've started an issue to address WCAG and ATAG for the accessibility gate. When Drupal core didn't have audio and video, large parts of WCAG and ATAG didn't apply.

Now we have pre-configured bundles in Standard profile for local video and local audio, so ATAG and WCAG come into scope. We should address text-based alternatives: transcripts and captions. There's an idea at #3002770: Provide authors with tools to manage transcripts and captions/subtitles for local video and audio.

This issue is quite outdated. The media module is in core and we are working on updating the roadmap for media in #2825215: Media initiative: Roadmap. The "Media Extend/Extras" stuff was never intended to be part of core, so I think we can say this issue is fixed.