Support from Acquia helps fund testing for Drupal Acquia logo

Comments

DamienMcKenna’s picture

Subscribe.

steinmb’s picture

+1 and subscribing.

Jackinloadup’s picture

subscribe

rickvug’s picture

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

aaron’s picture

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

rickvug’s picture

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

dafeder’s picture

I'm not sure it's intuitive to have a filefield for media when you're primarily using embedded video from 3rd party sources.

Niklas Fiekas’s picture

Subscribe.

dddave’s picture

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

Dave Reid’s picture

Version: 7.x-1.x-dev » 7.x-2.x-dev
Issue tags: -Release blocker +D7 stable release blocker

I think we should form_alter() the media field out of the 'Add new field' part of the field UI for now in both branches.

dmsmidt’s picture

+1

effulgentsia’s picture

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

aaron’s picture

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

Dave Reid’s picture

Yeah after more thought I agree. Removing blocker tag.

mfer’s picture

Not sure if it's a new thing but I can play video (problem reported in #9) without any problems from youtube.

mfer’s picture

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

slashrsm’s picture

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

rickvug’s picture

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

yareckon’s picture

slashrsm, 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?

slashrsm’s picture

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

Dave Reid’s picture

Issue tags: +Media Sprint 2011
ParisLiakos’s picture

Subscribe

Dave Reid’s picture

Title: Remove the media field » Move the media field to a non-required submodule
Category: feature » task

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

Niklas Fiekas’s picture

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

becw’s picture

Assigned: Unassigned » becw

I'm working on this.

becw’s picture

Here's an initial patch. There are two obvious issues with it so far:

  1. After this change, no data is loaded into 'media' fields.
  2. Field formatters that are specific to the 'media' field need to move into the new mediafield module.

I'm still working on this, I just wanted to post my work so far.

Dave Reid’s picture

Status: Active » Needs work
becw’s picture

I forgot to move hook_field_schema() from media.install to mediafield.install. That fixes most of the issues. However, I'm still getting errors in some theme_file_*() functions.

amateescu’s picture

Status: Needs work » Needs review
FileSize
23.01 KB

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

amateescu’s picture

becw’s picture

Reviewing...

becw’s picture

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

Dave Reid’s picture

+++ b/media.installundefined
@@ -627,3 +596,28 @@ function media_update_7200() {
+ * Enable the new Media Field module if this site uses "media" fields. Filefields are now preferred for storing media.

"File field"?

+++ b/media.installundefined
@@ -627,3 +596,28 @@ function media_update_7200() {
+  return t('The "Media" field type has been moved to the new "Media Field" module. Filefields can be used to store media.');

Again should be "File fields"?

+++ b/media.installundefined
@@ -627,3 +596,28 @@ function media_update_7200() {
+  return t('The "Media" field type has been moved to the new "Media Field" module. Filefields can be used to store media.');

"File fields" not "filefields"

+++ b/modules/mediafield/mediafield.infoundefined
@@ -0,0 +1,5 @@
+description = Provides a field type that stores media-specific data.

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.

idflood’s picture

Reroll of patch in #32 with changes proposed in #33. I've simply added "(deprecated)" to the description.

Dave Reid’s picture

Status: Needs review » Reviewed & tested by the community

I think this is ready to go.

Dave Reid’s picture

Status: Reviewed & tested by the community » Fixed

Committed #34 to 7.x-2.x. Thanks everyone!
http://drupalcode.org/project/media.git/commit/a7ae39c

Dave Reid’s picture

Just an FYI that the Views integration didn't get transferred over but I fixed it with:
http://drupalcode.org/project/media.git/commit/234fee7

skybow’s picture

subscribe

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

jjclint’s picture

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

rwilson0429’s picture

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

jjclint’s picture

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

rwilson0429’s picture

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