Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
Now that #1166168: Expose a widget for filefield and imagefield, so that media browser can be used for them has gone in, the media field is redundant and possibly misleading. I'd like to remove it entirely, and change existing mediafields to filefields in an update.
Comments
Comment #1
DamienMcKennaSubscribe.
Comment #2
steinmb CreditAttribution: steinmb commented+1 and subscribing.
Comment #3
Jackinloadup CreditAttribution: Jackinloadup commentedsubscribe
Comment #4
rickvug CreditAttribution: rickvug commented@aaron What was the original intention of media reference field? Are there any advantages of having a media reference field? On the surface moving to a widget on file field is a big +1.
Comment #5
aaron CreditAttribution: aaron commented@rickvug: The Media module has been in development for several years now, since early in d7's dev cycle. We originally created the media field to work around the fact that there was no file entity at that time, and even when that was fixed in core, it was still too limited for our purposes until very recently, when we finally expanded its functionality (allowing for fieldable file entities) with the contributed File Entity module (packaged with Media). The latest commit finally took the last step of applying the Media widget to file/image fields, thus this ticket.
I cannot think of any reasonable advantage to using a media field now, but am open to other opinions.
Comment #6
rickvug CreditAttribution: rickvug commented@aaron Got it. Sounds like this ticket should be a top priority then so more users don't start using the media reference field. An upgrade path (or at least instructions) will be needed.
Comment #7
dafederI'm not sure it's intuitive to have a filefield for media when you're primarily using embedded video from 3rd party sources.
Comment #8
Niklas Fiekas CreditAttribution: Niklas Fiekas commentedSubscribe.
Comment #9
dddave CreditAttribution: dddave commentedI finally got a video to play with a media_asset field, but still have no luck with using a filefield. Supposed it isn't my fault I suggest killing the mediafield AFTER making the filefield solution work completely.
Comment #10
Dave ReidI think we should form_alter() the media field out of the 'Add new field' part of the field UI for now in both branches.
Comment #11
dmsmidt+1
Comment #12
effulgentsia CreditAttribution: effulgentsia commentedI disagree about removing the media field. I agree with making sure filefield works fully, such as addressing #9 and the other issues we already have in the queue about it, but what media field has that's useful is the "data" column. While there aren't many (any?) modules making use of that yet, an example of experimental work to do so is in http://drupal.org/sandbox/cocoloco/1090384. I guess if we really want to remove the media field, we can add a data column to filefield, if we can do so in a way that doesn't break any core filefield functionality.
Comment #13
aaron CreditAttribution: aaron commentedi believe in early discussions with dopry, he'd advocated using a data field for core filefield. or rather, i believe he mentioned a flat table for metadata. in any case, neither was implemented.
#12 and #7 are both good arguments for keeping media field.
also, i agree with #9 on waiting to make a final decision to remove it until at least we have the filefield version more stable.
Comment #14
Dave ReidYeah after more thought I agree. Removing blocker tag.
Comment #15
mfer CreditAttribution: mfer commentedNot sure if it's a new thing but I can play video (problem reported in #9) without any problems from youtube.
Comment #16
mfer CreditAttribution: mfer commentedFor most things the data column (as described in #12) is a bad idea. There are rare occasions where it's a good idea. A data column cannot have it's content queried in the database or with EFQ and cannot have it's information exposed to views. It's a very limited use case. and should be used very sparingly.
We should have more field types that can accept the media browser. It might be a good idea to document how to use hook_field_widget_info_alter() to add new fields to the list of ones that can use the media browser. Instead of a data column where anyone can stuff their differences in how about lots of fields per use case that can all use the media browser?
Comment #17
slashrsm CreditAttribution: slashrsm commentedI agree with #12. Media field is the only field at the moment that allows us to add caption text to a field. There are title and alt in core image field, but those are generally not the same as caption.
+1 to keep this field.
Comment #18
rickvug CreditAttribution: rickvug commentedI'm -1 to keep the field. I was very happy to see file field in core as the "one true way" to add a file field to an entity. Having a media field with almost no perceivable difference will add confusion and could be problematic as user's want to customize the field via widgets and formatters that assume file field. With file field at least there is only one target for all of contrib. My 2 cents at least.
Comment #19
yareckon CreditAttribution: yareckon commentedslashrsm, isn't the caption text usually context specific? IE, you want to usually write the caption specifically to match the node you are embedding media into, not usually on the picture itself? And if not, can't you just add a field to the media file entity? Just add a caption field right there and it can go everywhere the media does. Using the data field is overkill in my opinion.
One thing I am confused about is how title and alt work into the filefield? If they exist in imagefield, how do they get entered on media?
Comment #20
slashrsm CreditAttribution: slashrsm commented@yareckon: My client has a requirement, to have possibility to override default caption (field on file) on node, where file is attached (media field on node).
Comment #21
Dave ReidComment #22
ParisLiakos CreditAttribution: ParisLiakos commentedSubscribe
Comment #23
Dave ReidWe discussed this during the sprint and our decision is to spin off the media field type into a self-contained sub-module that depends on Media, but is not required by Media. This allows us to not encourage people to enabled it by default and also allow users that currently are using the field to still be supported.
Comment #24
Niklas Fiekas CreditAttribution: Niklas Fiekas commentedThis is a good idea anyway. Modules that provide fields that are in use cannot be disabled, so #943772: field_delete_field() and others fail for inactive fields suggests splitting field types from other functionality.
Comment #25
becw CreditAttribution: becw commentedI'm working on this.
Comment #26
becw CreditAttribution: becw commentedHere's an initial patch. There are two obvious issues with it so far:
I'm still working on this, I just wanted to post my work so far.
Comment #27
Dave ReidComment #28
becw CreditAttribution: becw commentedI forgot to move
hook_field_schema()
frommedia.install
tomediafield.install
. That fixes most of the issues. However, I'm still getting errors in sometheme_file_*()
functions.Comment #29
amateescu CreditAttribution: amateescu commentedThose errors are not related to this patch, as they can be reproduced on a fresh install.
In the attached patch I continued @becw's work by separating hook_field_formatter_*() implementations. Is there anything else to do here? :)
Comment #30
amateescu CreditAttribution: amateescu commentedThose errors are fixed with the patch from #1270036: File Entity breaks the array output of the file field default formatter.
Comment #31
becw CreditAttribution: becw commentedReviewing...
Comment #32
becw CreditAttribution: becw commentedTests run, the update path works, and it's pretty much just moving code. I think it's ready. In the attached re-roll, I've made a couple of changes to comments and whitespace.
In the commit message, we should note that this contains an update function--folks using the "media" field type will get blatant errors until
media_update_7201()
is run.Comment #33
Dave Reid"File field"?
Again should be "File fields"?
"File fields" not "filefields"
Should we add something to description warning about its deprecation?
--
Otherwise I do not see anything major and so this could really use like one more manual test to make sure existing media fields do not break.
Comment #34
idflood CreditAttribution: idflood commentedReroll of patch in #32 with changes proposed in #33. I've simply added "(deprecated)" to the description.
Comment #35
Dave ReidI think this is ready to go.
Comment #36
Dave ReidCommitted #34 to 7.x-2.x. Thanks everyone!
http://drupalcode.org/project/media.git/commit/a7ae39c
Comment #37
Dave ReidJust an FYI that the Views integration didn't get transferred over but I fixed it with:
http://drupalcode.org/project/media.git/commit/234fee7
Comment #38
skybow CreditAttribution: skybow commentedsubscribe
Comment #40
jjclint CreditAttribution: jjclint commentedSorry to bump an old thread, but i'm a bit at lost here.
I'm using all the latest release devs on d.10 and I'm not sure which 'Type of data to store' under the manage fields in the relevant content type admin menu.
After reading a bit I've decided to switch my images from 'type of data to store' > 'image' to 'type of data to store' > 'multimedia asset'. This creates a somewhat of an extra steep - matching the file style to the image style because in views 'multimedia assets' have only media file styles as formatters - But it helped me map these fields for feeds.
I now read about this and that being deprecated and I would like to know - Giving all this deprecation what is the (most) right way of displaying images. Should I choose the media asset field the image field or maybe even the file field? Same goes for videos I guess - is it multimedia asset or file field?
All these new developments with no sufficient and coherent instructions (maybe I missed it) kinda leaves the user wondering when he's faced with the select 'type of data to store' option.
Comment #41
rwilson0429 CreditAttribution: rwilson0429 commentedI too am looking for the most appropriate configuration for images for new installations. The project documentation and the media module install documentation indicate that media field is deprecated.
The Media Roadmap documentation appears to indicate that the core image field will also deprecate in favor of file field. Under the 'Core Issues' sections of the documentation it states: 'Deprecate core's image field and enforce file field as the definitive file reference'. There is further suggestion of core image field deprecations at Issue #1290672: Documentation for image field -> file field '.....steer people away from image fields'.
Considering the tremendous development efforts done on this project, the documentation seems fairly substantial in comparison to other D7 modules documentation.
So, for me, all indications points to using file field for new projects when it can satisfy the use case.
Edit: A word of caution. The Great YouTube Mystery: How to play a video? I, and apparently lots of others, have found it tremendously frustrating trying to get videos to play in D7 without using the deprecated media field. I tried for 2 days to get the core file field to play nicely with videos, in particular Youtube videos. While I had some success using mediaelement.js module for local files stored in the core file field, in the end, I had to resort back to using the deprecated Media field to play YouTube and Vimeo videos. So, that's a huge plus for keeping the media field in the Media Module.
Comment #42
jjclint CreditAttribution: jjclint commented@41 I went with multimedia asset back when I started the project because - at the end of a long tiring search - that was the only way I could play 3rd party videos. So you can imagine how frustrating it was to find out about the field being deprecated.
Regarding the problem you've mentioned with embedded videos, I would give the Oembed module a try.
Comment #43
rwilson0429 CreditAttribution: rwilson0429 commented@jjclint, the media field is included as a separate module (multimedia field) in the latest Media module devs. As long as the maintainers continue to provide it as a separate module, your frustrations may be lessen for a while.
I've been looking for a solution that would allow me to use a single field to store both local videos and links to 3rd party videos. I hate providing users with a bunch of confusing fields, that as far as they are concern does the same thing - play videos. I think that I'm coming close to solution for this.
I've been experimenting with the MediaFront Module and the media players provided in that module. So, far I've been able to play YouTube and Vimeo using the core's file field using the Media Module and the MediaFront Module's OSM media player. I can also use the same file field to play local videos. MediaFront also comes with a very nice minimalistic html5 media player which depends on the HTML5 Media module player.
I've been communicating with Travis (MediaFront module and HTML5 Media module maintainer) to try to get an acceptable resolution. Travis is extremely helpful and a very responsive maintainer. He is keenly aware of the D7 media headaches and he is very helpful at suggesting solutions. You may want to check out this thread http://drupal.org/node/1436742
BTW, thanks for the Oembed module suggestion. I will definitely give it a try.