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
- Prevent inserting hard links, such as when dragging an image to a text area field
- Possible to edit all settings for an embedded file without having to delete and reembed it.
#1291518: Use Field Formatters for Embedding Options
#835516: Add ability to edit file meta data and fields when embedded in WYSIWYG - Be able to fill in all fields, depending on permissions, when adding a new media file.
#1421786: display fields when embedding with WYSIWYG
#1246862: Uploading images and using media styles / formats
#1062304: Fill in the available fields when creating media in the WYSIWYG - Rename uploaded file.
- Optionally use the Field Permissions module?
#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
- Special treatment of the User Picture upload and similar features.
- Be able to restrict what files/folders a user/role can browse.
#1190542: Access control: add per-service granularity to media_internet permissions
#992978: Add 'View media browser library' permissions - Be able to rename files.
- Basic features to move files to new locations.
- How will global changes to files be propagated to where they already are used?
#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
Comment #1
rickmanelius CreditAttribution: rickmanelius commentedSubscribe. Thanks for all your hard work putting this together!
Comment #2
dddbbb CreditAttribution: dddbbb commentedsub
Comment #2.0
dddbbb CreditAttribution: dddbbb commentedMoved the Google Docs to the top to make it more visible and easier to find.
Comment #3
sonar_un CreditAttribution: sonar_un commentedSubscribe - What a great list!
Comment #4
tsvenson CreditAttribution: tsvenson commentedAlright. 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!
Comment #4.0
tsvenson CreditAttribution: tsvenson commentedAdded a whole bunch of related issues...
Comment #5
attiks CreditAttribution: attiks commentedGreat job, subscribing
Comment #5.0
attiks CreditAttribution: attiks commentedMoved one issue to a better location
Comment #6
kofi CreditAttribution: kofi commentedSubscribing. Thanks for your work!
Comment #6.0
kofi CreditAttribution: kofi commentedAdded workaround using IMCE
Comment #6.1
tsvenson CreditAttribution: tsvenson commentedAdded issue 1242884 alt/title attributes
Comment #7
idflood CreditAttribution: idflood commentedSubscribing
Comment #8
MacRonin CreditAttribution: MacRonin commentedsubscribe +1
Comment #9
zambrey CreditAttribution: zambrey commentedsubscribe
Comment #10
AdrianB CreditAttribution: AdrianB commentedFantastic work! Subscribing.
Comment #11
kreynen CreditAttribution: kreynen commentedWow... subscribe.
Comment #12
fenstratSubscribing
Comment #13
renat CreditAttribution: renat commentedSubscribe
Comment #14
Jackinloadup CreditAttribution: Jackinloadup commentedSubscribe
Comment #15
Simon Georges CreditAttribution: Simon Georges commentedGreat job!
Comment #16
matglas86 CreditAttribution: matglas86 commentedSubscribe
Comment #17
anavarreSubscribe
Comment #18
aturetta CreditAttribution: aturetta commentedNice 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.
Comment #19
franzGreat! Seconds to aturetta.
Comment #20
aaron CreditAttribution: aaron commented@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.
Comment #21
tsvenson CreditAttribution: tsvenson commented@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.
Comment #22
betoscopioSubscribing, great work.
Comment #23
mrsinguyen CreditAttribution: mrsinguyen commentedSubscribing
Comment #24
zoon_unit CreditAttribution: zoon_unit commentedsubscribing
Comment #25
Dave Reid@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.
Comment #26
kingjohnnet CreditAttribution: kingjohnnet commentedsubscribiing
Comment #27
DamienMcKennaLooking at the list, I think I'm going to start gibbering. On the other hand: subscribe =)
Comment #28
pepperstreet CreditAttribution: pepperstreet commentedThanks for the infos and efforts!
(subscribing)
Comment #29
tsvenson CreditAttribution: tsvenson commented@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.
Comment #30
jakonore CreditAttribution: jakonore commentedGreat summary! Subscribe
Comment #31
paranormals CreditAttribution: paranormals commentedSubscribing
Comment #32
dddave CreditAttribution: dddave commentedAs 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?
Comment #33
kreynen CreditAttribution: kreynen commentedI'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.
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?
Comment #34
tsvenson CreditAttribution: tsvenson commented@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.
Comment #35
Dave ReidWith 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/.
Comment #36
tsvenson CreditAttribution: tsvenson commented@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?
Comment #37
kreynen CreditAttribution: kreynen commentedI 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 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.
Comment #38
tsvenson CreditAttribution: tsvenson commented@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.
Comment #39
dddave CreditAttribution: dddave commentedApart 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.
Comment #40
wmostrey CreditAttribution: wmostrey commentedIt'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?
Comment #41
gaele CreditAttribution: gaele commentedsub
Comment #42
dlumberg CreditAttribution: dlumberg commentedThis is great, sub
Comment #43
SeanBannister CreditAttribution: SeanBannister commentedsub
Comment #44
hernani CreditAttribution: hernani commentedSub
Comment #44.0
hernani CreditAttribution: hernani commentedMoved 1242884 to the right place in the list.
Comment #45
mightyiam CreditAttribution: mightyiam commentedsub. Great work!!!
Comment #46
DamienMcKennaI'd also like clarification from the maintainers on @wmostrey's question from #40 above:
Comment #47
dddbbb CreditAttribution: dddbbb commented+1 on clarity from the maintainers
Comment #48
Dave ReidWe 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.
Comment #49
wmostrey CreditAttribution: wmostrey commentedI'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.
Comment #50
brunodboRe #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.
Comment #51
kingjohnnet CreditAttribution: kingjohnnet commentedsub
Comment #52
brunodbo@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.
Comment #53
slashrsm CreditAttribution: slashrsm commentedI 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.
Comment #54
yareckon CreditAttribution: yareckon commentedThere 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.
Comment #55
dddave CreditAttribution: dddave commented@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.
Comment #56
slashrsm CreditAttribution: slashrsm commentedI 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?
Comment #57
yareckon CreditAttribution: yareckon commentedI 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.
Comment #58
BenK CreditAttribution: BenK commentedSubscribing
Comment #59
brunodboTo 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...
Comment #60
brunodboSprint info: http://groups.drupal.org/node/173749
Comment #61
betoscopioSub
Comment #62
Andrew_Mallis CreditAttribution: Andrew_Mallis commentedsubscribe.
Comment #63
acbramley CreditAttribution: acbramley commentedSub. 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.
Comment #63.0
acbramley CreditAttribution: acbramley commentedAdded issues 1248730 and 1251468
Comment #64
madeby CreditAttribution: madeby commentedThanks 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
Comment #65
chiebert CreditAttribution: chiebert commentedsub
Comment #66
drupaltronic CreditAttribution: drupaltronic commentedsub
Comment #67
bryancasler CreditAttribution: bryancasler commentedsubscribe
Comment #68
desiman CreditAttribution: desiman commentedsub...
Comment #69
dddbbb CreditAttribution: dddbbb commented@desiman Stop subscribing, start following: http://drupal.org/node/1306444
Comment #70
protools CreditAttribution: protools commentedhttp://drupal.org/node/1347692 - it would be cool
Comment #71
menteb CreditAttribution: menteb commentedSubscribe +1
Comment #72
helmo CreditAttribution: helmo commented@menteb Stop subscribing, start following: http://drupal.org/node/1306444
Comment #73
n8j1s CreditAttribution: n8j1s commentedRight 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.
Comment #74
tsvenson CreditAttribution: tsvenson commented@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.
Comment #75
Andrew_Mallis CreditAttribution: Andrew_Mallis commentedWithout 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.
Comment #75.0
Andrew_Mallis CreditAttribution: Andrew_Mallis commentedRemoved all fixed and closed issues.
Comment #76
lpalgarvio CreditAttribution: lpalgarvio commentedgreat 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.
Comment #77
Devin Carlson CreditAttribution: Devin Carlson commentedFiles 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!
Comment #78
dimitriseng CreditAttribution: dimitriseng commentedHi. 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!
Comment #79
aturetta CreditAttribution: aturetta commentedRelated 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....
Comment #79.0
aturetta CreditAttribution: aturetta commentedRemoving issues marked as won't fix and replacing issues marked as duplicates with their duplicate issue
Comment #80
darksnow CreditAttribution: darksnow commentedLooks 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.
Comment #81
tsvenson CreditAttribution: tsvenson commentedOh, 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.