Source Document: Current State of the Media Module.

Saturday August 6, I spent the day testing the current state of the Media module. I wanted to find out how useful it is right now, as well as what I believe is missing before it is ready for a full release. I did this exercise from a site builders perspective.

This issue contains a bullet summary of my findings and suggestions about what is needed. Whenever there exists an issue dealing with a specific bullet, it will be added so its easy to see the status of it.

If you know of any existing issue that is not in the list below, please edit this summary and add it.

Important: Please keep in mind that this is not an official specification or roadmap for the Media module. My hope is that it can form the base to that though. If it does, it will be simple to add issues for the missing features in the list below.

Please also note that many of the issues listed below is not filed against the 2.x version, but they seems serious enough to be looked at and checked if they exists in 2.x as well. Only issues where it says its been fixed in 2.x has been excluded.

Issues are grouped and ordered from newest to oldest as well.

Edit Image Field with Media module

Edit tab:

  • The default storage setting for a field is not respected. Needs new options, including permissions if user are allowed to change location or not.
    Workaround solution - See the Source document at the top for a workaround using the IMCE module to upload and organize files in folders before use.
  • File properties (pixels and size) is visible, but not used. Needs sitewide settings as well as field specific overrides. Use case for when this is needed explained in document.
  • Alt and Title visible but not used. Should probably be moved to "admin/config/media/file-types".
  • Help text moves to under the media box when more than one file can be added.
  • Default image visible, but doesn't fill any purpose.

#1213108: Allow the media field widget to select specific browser plugins

Field Settings tab:

  • Upload destination and Default Image looks to duplicate the settings at the bottom of the Edit tab

Adding Fields to File Type

Located at: admin/config/media/file-types

  • Possible to add file/image fields to a media file type, what implications has that?
  • Even possible to add the existing image field to itself...
  • Restrictions needed for who can edit what for added media.
  • Needs to be possible to override field values when reusing an existing file, without updating the global values.
  • What happens when edits are made, will the propagate automatically to all places the media file is used?
  • How will updates to the global values affect overridden values?
  • Currently fields have to be manually added to each file type. A lot of fields will be needed to be used for all, or many file types. Possible to add a setting "Use an all file types" or "Use only on these file types"?

Adding/Editing media content

#1242884: Image alt and title tags filled in via the wysiwyg editor are lost
#1140404: Add insert module integration
#1213252: Allow media file's fields to be edited in a modal or after upload in the media widget
#983924: Improve usability of configuring media types / extensions and allowing uploads for those extensions

Media Browser

#1251468: Hide Confusing Field 'Description' When Embedding Media
#1224766: Remove default media browser and replace with a default view
#1213252: Allow media file's fields to be edited in a modal or after upload in the media widget
#1071074: Filters for admin/content/media

Other important issues and release blockers

#1240834: Cannot delete images added via an image field on an entity, what is previously deleted
#1239056: Remove Media at content edit page cause the file to be completely deleted from server/database?
#1238772: Disable the 'Media browser' WYSIWYG button until it has been enabled for the text format
#1228790: Popup browser broken when using "Add another item" on multiple field
#1224788: Move the file entity forms to project/file_entity
#1201936: Move the media field to a non-required submodule
#1174802: Add media-field-value tokens.
#1085136: die() usage should be replaced by exit()
#1070974: Additional help to indicate that the Media Filter must be enabled
#1069582: How to use an alternate stream wrapper when saving media files?
#1058098: Add ctools page_manager support for file/%file path
#1056718: Thumbnail view without added media gives errors
#1051090: Revamp file view modes: migrate media_small to teaser, media_large to full, media_preview to preview; deprecate link & original
#1034034: Title and data values for media fields is inaccessible to formatters
#1032186: Add hook_media_rendered_flush()
#1024874: Add support for m4v as 'video/x-m4v' in file_entity_file_mimetype_mapping_alter()
#938070: Multilanguage support

Issues that need some love

This is a list of issues that can't really be classified, either they are very old or someone with more knowledge needs to look and see if they are a release blocker, and especially if they relate to 2.x.

#1174374: Use a more specific selector to replace the add file link in the admin ui
#1141082: Provide a UI for identifying and reverting CTools Exportables overrides of file display configurations
#979844: Add event handler when media is selected for a field so that other modules might intervene
#962110: Add views handlers for the media field type
#846708: Implement hook_file_delete to cleanup references to that file in media fields, and media meta-data fields
#840688: The media popup browser shouldn't be creating new dialogs each time it is invoked

Comments

rickmanelius’s picture

Subscribe. Thanks for all your hard work putting this together!

dddbbb’s picture

sub

dddbbb’s picture

Issue summary: View changes

Moved the Google Docs to the top to make it more visible and easier to find.

sonar_un’s picture

Subscribe - What a great list!

tsvenson’s picture

Alright. Have now gone over every open issue, except support issues, and inserted them where I think they belong in the list in the issue summary.

There are quite a few duplicates in there, but I have left them as is for now. Mainly because I don't have enough knowledge about the inner parts of the Media module to decide which one to keep and which ones to mark as dupes.

There are most likely also a lot of issues that either are fixed already or isn't related anymore because of design changes. Here too I have listed them so that users with the right knowledge can make the right decisions about them.

My suggestion now is that everyone that wants to see a full release of the Media module, goes over this list, as well as all other open issues to merge/close duplicated, close fixed or depreciated issues. That way we will get the number of open issues down, from the 237 it is now, to something much more manageable and can start digging into those that prevent the full release.

If no one objects, I plan to keep updating the issue summary by removing fixed issues, as well as add new ones for those features that have none. Hopefully this will help everyone to keep track on what is going on and what is still needed.

I also think we need to make a decision if there is a need for a 1.0 release as well or if all focus should be on the 2.x branch. I opened #1241994: Prioritize the Media module 2.0 release where we can discuss that.

It is probably also a good idea to remove the link to #1018640: [meta] How to help get Media to 1.0 release and beyond in "want to help" at the top of the project page. Instead add a link to this issue and make it much more visible for users to find.

Lets get this done!

tsvenson’s picture

Issue summary: View changes

Added a whole bunch of related issues...

attiks’s picture

Great job, subscribing

attiks’s picture

Issue summary: View changes

Moved one issue to a better location

kofi’s picture

Subscribing. Thanks for your work!

kofi’s picture

Issue summary: View changes

Added workaround using IMCE

tsvenson’s picture

Issue summary: View changes

Added issue 1242884 alt/title attributes

idflood’s picture

Subscribing

MacRonin’s picture

subscribe +1

zambrey’s picture

subscribe

AdrianB’s picture

Fantastic work! Subscribing.

kreynen’s picture

Wow... subscribe.

fenstrat’s picture

Subscribing

renat’s picture

Subscribe

Jackinloadup’s picture

Subscribe

Simon Georges’s picture

Great job!

matglas86’s picture

Subscribe

anavarre’s picture

Subscribe

aturetta’s picture

Nice start, I hope to help in the next weeks

Also, please keep in mind that translation has a big role in the adoption of this kind of UI modules: as it's currently engineered, the translations system works only on released versions, so it's better to release an alpha version every time you commit a major change in textual strings, to ease the work of the translation teams.

franz’s picture

Great! Seconds to aturetta.

aaron’s picture

@aturetta: Thanks, I didn't realize that. I'll plan to roll a quick 7.x-2-0-alpha1 today, unless I hear a compelling reason not to.

tsvenson’s picture

@aaron: No objections from me whatsoever :)

Maybe it would also be a good idea to remove the 1.x branch from the project page when the 2.0 alpha1 is visible, just to put more emphasis on that 2.x is the one being worked on. Anyone needing 1.x can always get it from the View all releases link.

Update: Just looked at the usage stats. While 2.x jumped from 262 to 452 the last week, 1.x beta5 jumped from 5,486 to 6,262. Great to see an increase of 75% for 2.x, but in shear numbers it lags the 1.x branch.

betoscopio’s picture

Subscribing, great work.

mrsinguyen’s picture

Subscribing

zoon_unit’s picture

subscribing

Dave Reid’s picture

@aaron: Can we roll a 7.x-2.0-unstable1 release instead? I know some incoming things are going to break APIs so I'd like to really give the version the implied 'things will be changing' type of name.

kingjohnnet’s picture

subscribiing

DamienMcKenna’s picture

Looking at the list, I think I'm going to start gibbering. On the other hand: subscribe =)

pepperstreet’s picture

Thanks for the infos and efforts!
(subscribing)

tsvenson’s picture

@DamienMcKenna Can understand that. I am not a skilled Drupal coder, hope to be one day. I just did my best to try and save some time for others, especially the maintainers.

jakonore’s picture

Great summary! Subscribe

paranormals’s picture

Subscribing

dddave’s picture

As someone who already upgraded to the 7.2x branch (which works fairly well) I can say the following: The real problems begin when you ditch the styles module and try to recreate the necessary settings via the "file types" settings (I guess provided by file entity module?). The UX is nightmarish and I don't want to imagine the amount of trouble a newbie has to go through if the workflows there aren't optimized. That should be a major focus apart from proper functionality. I figured most of it out but by no means this is userfriendly, easy or fun atm.

...or did I miss something?

kreynen’s picture

I've been mentoring slashrsm's GSoC project to develop a Derivatives API for Media. If you've watch his screencast about HTML5 video support with Media, you'll see his project is well on it's way to being a stable D7 replacement for media_mover.

Between the Derivatives API project and the D7 branches of the provider modules I maintain/co-maintain (media_archive, media_vimeo, media_bliptv, and media_pegtv) for clients, I've had to keep a close eye on changes to media and media_youtube to keep everything working.

While @tsvenson work consolidating the issues is great and the 2x.-unstable branch is helpful, the information on the project page is still confusing.

There are also some critical issues that still must be fixed before we release 2.0. Want to help?

The 'want to help' still links to @tsvenson's original '[meta] How to help get Media to 1.0 release and beyond' post from back in January. The list of provider "plugins" on the Media project page is also dated listing only a few providers and pointing to optional modules that will/might be abandoned in the 2.x transition.

I've posted a Wiki listing Modules that Extend the Media Module that I'm familiar with on GDO.

It would be great if some of the 'subscribers' to this post would volunteer to keep that document current with the status of the modules in the 1.x branch and 2.x so when someone asks a questions like What is the recommended solution for someone who wants to go live right now, there is answer.

While Media's code continues to improve, documentation and communication continue to be an issue.

It is now possible to grant a maintainer permission to edit the project page and manage issues without the write to VCS permission. While @tsvenson might not have the chops to contribute code, he has shown he has the understanding and energy to help with project management and documentation.

@aaron Any issues with letting @tsvenson take that on?

tsvenson’s picture

@kreynen @aaron: I'm fine with being able to keep the project page up2date. Already help with support for Token and Pathauto and have that maintainer permission for those to be able to assign issues etc.

I am also usually on IRC in the drupal-media channel so can/will run any changed to project page with maintainers first when needed.

Dave Reid’s picture

With probably a major textual changes that need to be made, anyone at any time can file an issue for a revised project page HTML, or link to a http://lullapad.com/.

tsvenson’s picture

@kreynen: Great work on the wiki page, lots of modules I didn't know of.

With so many modules, and developers knowing so much about the Media module, I think we should try and come up with a way to better share knowledge and talk about whats needed. The media group and the IRC channels are there, but not very used. The group has 413 members, and the IRC channel usually about 10-20 users logged in.

Maybe a media-developers@drupal.org mailinglist would be a good complement?

kreynen’s picture

I really doubt there will ever be a new mailing lists on drupal.org since there is a reoccurring call to kill off the existing lists in favor of IRC, issues queues and GDO. I also doubt an email list would address my biggest concern, which is that some information appears to encourage users to upgrade from 1.x to 2.x now while at the same time @Dave Reid wants to break things to make them better. There are a lot of moving parts to these configurations and if 7.x-2.0-unstable1 and future 7.x-2.x release until some future date are intended for testing only, that should be made absolutely clear.

We should also be putting effort into the media_dev install profile as well. There are several issue marked as needs review in addition to the issues I recently added...

#1245468: 2.x branch of the profile?
#1245682: Use packaging to build downloadable profiles for testing

I have no idea who's going to review those issues. When I talked to Jacob at D4D in Boston, he said he was no longer on the Gardens team and wasn't going to be working on media for the foreseeable future.

The media_dev profile is a good starting point.

The profile has the potential to be a good starting point, but it is in desperate need of a refresh. Compare the steps required for basic media testing with the more advanced derivative api testing.

Creating an environment to test media with specific versions of modules should not be this hard.

tsvenson’s picture

@kreynen: Haven't tested the media_dev profile, but wonder if it still is needed? IIRC it was developed way back before Drupal 7 was even in beta and was to help getting things working, especially with the Styles dependency.

Now though, you just need to enable Media and File Entity, then configure the plugin for CKEditor and its done. Very little configuration needed.

But, as your #1245682: Use packaging to build downloadable profiles for testing say, adding the majority of sub modules to Media to the profile is probably a better option to quickly let developers and testers going with it.

On the other hand, I would personally use the manual configuration as I then can do it the way I build sites and get constant feedback from how it works after each configuration change or new module added to the test site than from a profile that most likely is "tweaked" to make sure things don't break.

dddave’s picture

Apart from the sexyness that is the CKE integration could we please not forget all the people trying to recreate the good old emfield-days? I think this might be the (second?) most common usecase: Build a dedicated videofield and let users put the youtube/vimeo/whatever code into it. This basically works but getting the display right is pretty broken atm.

wmostrey’s picture

It's unclear to me what the current path for the Media module is. We currently have 7.x-1.0-beta5. Are we also working towards a stable 7.x-1.0 release, or is that a dead branch now and is all effort being put into getting 7.x-2.0 released?

gaele’s picture

sub

dlumberg’s picture

This is great, sub

SeanBannister’s picture

sub

hernani’s picture

Sub

hernani’s picture

Issue summary: View changes

Moved 1242884 to the right place in the list.

mightyiam’s picture

sub. Great work!!!

DamienMcKenna’s picture

I'd also like clarification from the maintainers on @wmostrey's question from #40 above:

  • Is any official effort going into the v7.x-1-x branch to make it stable & reach a 1.0 release?
  • If so, what is the priority of stabilizing it vs working on v7.x-2.x? Does anyone have a set goal for what v7.x-1.x should contain?
  • If not, is it officially an dead branch?
dddbbb’s picture

+1 on clarity from the maintainers

Dave Reid’s picture

We are still pushing to finish the 7.x-1.x branch - but at this point it is essentially feature-locked and any new features are pushed to the 7.x-2.x branch like Views integration, CTools plugins for media browser etc. We will be having a sprint in Sept to both push for a 1.0 release (fixing the remaining release blocker bugs), as well as work on the new 2.x features.

The biggest priority should be a stable 7.x-1.0 release, but that doesn't mean we can't also be working on 7.x-2.x at the same time.

wmostrey’s picture

I'm all up for the feature lock on Media 1.0 and getting a stable version released, with all new features going into 2.x. In the mean time back- and forward-porting all bugs found.

brunodbo’s picture

Re #33 - I updated the project page:

- Included the link to this page (left the link to the 1.x branch meta page, since this branch is also still active).
- Added the link to the extension module wiki page on GDO.

kingjohnnet’s picture

sub

brunodbo’s picture

@Dave Reid: Do you know when the sprint is happening, and can people join in through IRC? People could also join in to make a summary of the sprint afterwards, so we can keep people informed on the state of Media.

slashrsm’s picture

I added two modules to gdo wiki, which kreynen created. I will try to help with this issues as much as I can, but I also have to work on media_derivatives to make it stable and useful ASAP.

I am also interested in that code sprint.

yareckon’s picture

There are so many patches out there for various branches of the media module it is ridiculous. We need to stop writing them and start rejecting/cleaning/applying them. Maintainers need to reject them if you won't take them, or at least direct folks which branch to reroll against. On a project this big, git adds to the problem as everyone is working on a different client branch and deadline. We really need traffic cops and someone with the right and will to say both "yes" and "no" not only for their internal version of the media module, but for the official branches that everyone is looking to work off of. It's not enough for the committers to be coders here, we need someone setting and communicating the agenda, and someone (else?) acting as an intake manager to triage new issues.

Anyone else think that all d.o. project pages need a blog-like stream of official communication from maintainers? A static, infrequently updated project description should always be the intro to the project, but there needs to be a place for these meta issues that is visible to all people that are stakeholders in a module.

dddave’s picture

@54
I understand your frustration about the current situation of Media because I feel basically the same. However tsvenson is doing a good effort on streamlining the issue queue situation.
The current lack of progress is mainly caused by this terrible event: http://aaronwinborn.com/blogs/aaron/drupal-commuity
The other maintainers are busy guys (Dave Reid especially)but progress is imminent with the upcoming sprint. I hope things get better in the next weeks.

slashrsm’s picture

I totally agree with both of you and I'm willing to help as much as I can. Where can be more info about that code sprint found?

yareckon’s picture

I had heard about aaron's illness, and been inspired by his incredible response to it. Perhaps the logjam in the issue queues is just the reminder that good people are dearly missed when they are having to deal with real life issues. On the other hand, I stand by my proscription of how the team (including aaron, whose participation continues) could shift focus to getting the mainline media module some momentum and pushing some of the forks, patches and brainstorming either clearly IN or OUT of the official direction.

BenK’s picture

Subscribing

brunodbo’s picture

To get an idea of the state of Media module, see this interview with effulgentsia: http://acquia.com/resources/podcasts/acquia-podcast-34-alex-bronstein-me...

brunodbo’s picture

betoscopio’s picture

Sub

Andrew_Mallis’s picture

subscribe.

acbramley’s picture

Sub. I also think #1276090: Media browser library doesn't display "Other" file types. should be addressed. It's pretty important to have ALL file types available to the media browser.

acbramley’s picture

Issue summary: View changes

Added issues 1248730 and 1251468

madeby’s picture

Thanks for this update. I created an issue with some questions, thoughts and ideas that is really important for the full usage of the module. At least for us.

If anyone would care to join the debate or help answer some of my questions I would be really grateful:
http://drupal.org/node/1271728

chiebert’s picture

sub

drupaltronic’s picture

sub

bryancasler’s picture

subscribe

desiman’s picture

sub...

dddbbb’s picture

@desiman Stop subscribing, start following: http://drupal.org/node/1306444

protools’s picture

menteb’s picture

Subscribe +1

helmo’s picture

@menteb Stop subscribing, start following: http://drupal.org/node/1306444

n8j1s’s picture

Right now the biggest thing keeping me from using this module is the inability to store my files in subfolders based on tokens. This module is awesome, a huge step forward for drupal, but until I can control where my files are being stored it will lack usefulness for me.

tsvenson’s picture

@n8j1s That is something a lot of user would like to have too. You are of course welcome to contribute a patch or create a add-on module adding that capability. Best is to add it to the File Entity module in that case.

Andrew_Mallis’s picture

Without structure to uploads, browsing for files is a chore, and managing the filesystem a real bother.

Filefield Paths works great already. However, we're talking about File Entities here, which are a different animal.

There is some talk on that module's issue queue worth checking out.

Andrew_Mallis’s picture

Issue summary: View changes

Removed all fixed and closed issues.

lpalgarvio’s picture

great work!

it would be awesome to be able to map/change the file types (application, audio, image, text, video other) to their respective file extensions and file mime types -- even better to allow admins to add more file types.

Devin Carlson’s picture

Files types are handled by the File entity module.

Work on supporting custom file types and providing an interface to manage file types (along with the MIME types allowed for each file type) is occurring in:

I'm sure that any help testing the currently available patches would be appreciated!

dimitriseng’s picture

Hi. As probably a lot of others, I am trying to figure out if I should use the 2.x for new projects or stick to 1.x. I have done some testing with 2.x and seems to be working relatively ok, thanks for all the great work from all involved. However, is there a planned date for releasing at least an alpha or beta release soon, instead of having only unstable? Any advice would be appreciated, many thanks and happy new year!

aturetta’s picture

Related to that, please forgive me if I remember that tagging a release (at least alpha) will allow translation teams a chance to localize the module....

aturetta’s picture

Issue summary: View changes

Removing issues marked as won't fix and replacing issues marked as duplicates with their duplicate issue

darksnow’s picture

Looks to me like there are five issues up in that list that have not been resolved.

Is this list still current and if so, any idea when there might be a release of Media 2?

It seems to me that the 1.x branch is obsolete, as it says on the front page of this, but without a 7.2.x release being the recommended release there is wide spread confusion about the state of this module and which version we should all be using.

Cheers.

tsvenson’s picture

Status: Active » Closed (won't fix)

Oh, this old thing still alive. While it's great so many issues have been closed, this document is very outdated and a lot of big changes has been made since.

I'm closing it as (won't fix). If anyone with more current knowledge of the Media project feels it should still be open, feel free to correct me.

For current info, see the http://groups.drupal.org/media Media group or the #drupal-media IRC channel.