Updated: Comment #0

Problem/Motivation

We will need basic field widget for entity reference fields that will be used to reference media from other entity types (nodes, ...). We definitely need to give another look to all implementations in D7 (Media, Scald, Asset) and work on top of that.

Widget should probably be as extensible and pluggable as possible. It would be nice to have some mocks before we dive into the code.

UX must be our first priority. Widget should provide seamless content creator workflow out of the box. We must provide things as multi-upload, multi-select, in-place metadata edit, ... by default.

System should be very flexible but should also hide any unnecessary complexity by default. It should allow us to create simple media solutions with almost no configuration needed while leaving options that will allow complex media implementations with complex configurations to achieve their needs.

Proposed resolution

Remaining tasks

- create mocks
- define how widget integrated with different "source providers"
- define how widget provides plug-ability
- write code

User interface changes

- provides field widget UI

API changes

- n/a

- #2100515: Figure out and implement media types

Comments

slashrsm’s picture

Issue summary: View changes
Issue tags: +DC Vienna sprint
John Pitcairn’s picture

One thing I would very much like to see is for data fields attached to the referenced media entity to be locally overridable in the referencing instance, and revisionable along with the referencing entity. This should be conceptually and functionally separate from editing anything associated with the referenced media resource.

My current custom D7 solution/kludge (screenshots on request) is conceptually very similar to the 2-layered referencing proposed for media entity, and implements this strategy.

It involves a field collection called "media asset", which itself contains a media module field. Additional field collection fields are locally overridable from within the referencing node form and revisioned along with the referencing node. The media module field uses the standard media library/upload popup, with a tweaked library view to allow additional searchability.

There is a conceptual separation between editing things that are specific to the media instance (caption, alt/title overrides, display style, link, etc, via the node form field collection) vs things that are global to the media resource itself (default alt text, tags, other fields on the file entity, via media module popup).

My clients "get" this separation pretty quickly, and it helps them avoid the unfortunate global changes that tended to occur if I just gave them a media module field with additional fields on the file entity.

I wonder whether media entity might be able to take a similar approach?

slashrsm’s picture

This is definitely very valid use-case. I also had it once and we had really hard time satisfying it (I can say that you managed to achieve much nicer solution that we did at the time). This is something that MediaBox seem to do right. They provide two entity types (Mediabox and Mediabox display). Mediabox display entity is actually used when you reference the entity and they override Mediaboxes fields on display entity.

It, however, seems that there are majority of sites that do not need this feature. That makes me feel that we should not ship with this included by default. I'm currently more in favour of providing this in a separate module, that would "inject" this intermediate layer (either using field collection or something else). This would allow people with such needs to add this functionality to their site. That also means that we need to design main architecture with this in mind (e.g. make relatively easy to inject another layer).

How does this sound?

John Pitcairn’s picture

I'd personally be happy with a separate module. It's a fair bit of work bending field collection and media to handle it at present (especially integrating with wysiwyg), it would be great if media entity could provide something flexible enough to implement this nicely.

But non-technical users in my experience think of the media as "part of" the parent, not something separate, especially if all their interaction with it is from the parent entity form. So I think it is a reasonable expectation that local instance data would be revisionable along with the parent entity by default as soon as you create a new revision of the parent.

This is of course all handled by default when media is inserted via wysiwyg. But "use wysiwyg" shouldn't be the standard answer - I'd expect default field behavior should be consistent from the user's point of view, otherwise it's a considerable "WTF??" when the user (and the compliance team) discovers it isn't.

If it's a separate module, and off by default - what happens when somebody has built their site without local data overriding/revisioning, because they didn't read the documentation fully enough? Now their boss is yelling at them and the legal department isn't happy. Will there be a way to simply "turn on" local data revisioning for all their existing media content by enabling the optional module (ie will it take over existing fields), or will they also have to replace all their field instances and figure out how to import data into the new field instances? Ouch.

Dave Reid’s picture

Worth considering is this actually Media's problem to solve. Why couldn't a solution be built that supports this kind of behavior for any type of entity referenced via an entity reference field? I should be able to reference a node but override it's title when used in this one place as a link. A solution for that should also solve the Media local/global field data issues.

John Pitcairn’s picture

Good point, and I can see that would be pretty useful. Though a generic solution would be considerably more work and support than something focused on this specific and perhaps less uncommon use-case. Not sure I have the chops to build it unfortunately. Still ... hmmm...

jcisio’s picture

I also think that it is out of the scope of Media. There are two problems:

- Override some data of an entity: there is a D7 module https://drupal.org/project/entity_override.
- An UI to utilize the first point: it could be an arbitrary data used in WYGIWYG embedded code, or structured data in the backend (it can be considered as an Entity Reference feature request).

When people ask me how to override some data with entity reference (or Atom reference in Scald), I usually tell them to make a Field Collection (or Multifield etc.) field, each with one entity reference + fields to override, then override them we the field collection entity is viewed.

But a general solution for any referenced entity is out of the scope of Media.

John Pitcairn’s picture

OK, I give up ;-)

slashrsm’s picture

I agree. It is definitely out of scope for this specific module, but since this is a valid use case we have to leave the doors open for this kind of solutions.

Field collection is definitely one of the ways to achieve this (and I agree with Dave that it is a bigger problem that needs to be solved in general). Another approach could be with Relation or something similar. Both Relation and Field collection are similar at the end of the day. They are both entities that you reference from another entity.

jstoller’s picture

I've also been having this issue on a site I'm working on, and like other's I've turned to Field Collection. My file entities only contain globally managed fields and any fields which vary locally are placed in the Field Collection. However, I'm still seeing a big problem with image cropping. All the cropping modules seem to work directly on the media asset, but I need my editors to have the flexibility to alter the crop in each place an image asset is used. I assume this specific functionality is out of scope for Media itself, but I would like to see the module built in such a way that the functionality can be easily implemented by other modules, like Manual Crop.

slashrsm’s picture

Version: » 8.x-1.x-dev
Status: Active » Closed (won't fix)
Issue tags: -DC Vienna sprint +Media Initiative

At NYC camp we decided to use future entity_browser module, that will provide this functionality for all entity types.

See https://groups.drupal.org/node/418803 for more info.