Update modified metadata in mapped fields

We would definitely like to make this logic a bit smarter. The main problem is that it is hard to reliably detect whether the field changed on the source or if there was a manual change on the Drupal's side. In first case you generally want to update it, while in the other you most likely don't.

One solution would be to make this configurable (on bundle or even on a field level). Maybe there is some better way. I am not sure.

Any suggestions?

Perhaps a first step could be to always update from the source when the fields mapped to meta-data are hidden from the form?
When these fields are then exposed to the user:
- They will be populated if empty
- They won't be modified if they contain any data

Does that make sense to improve things a little bit?

Solution proposed in #3 still have the potential performance problem. IF media type relies on 3rd party to fetch this metadata we'll have to call it on every save (think about Twitter API). I think that we want to avoid that.

It is true that if we always update from source when the fields are hidden, we would be (potentially) degrading the performance, sometimes unnecessarily. (Although one could argue that the "mapping" functionality has this "inherent" drawback, because if I want to import/syncrhonize the retweet count, for instance, I need to accept that a new call will be needed on each entity save)

But I agree that a better solution would mean leaving this decision to the end user, and make everything configurable.

What about one of these 2 approaches:

Option 1 (configurable per bundle)

- When creating a media bundle, we have a new field settings for the bundle:

  * Field mapping update settings:
    ( * ) Only on entity creation (checked by default, current behavior)
    (  ) Each time the entity is saved

If the second option is checked, then we have a second config value:

  * Field mapping update settings:
    (   ) Only on entity creation
    ( * ) Each time the entity is saved
      [ x ] Override existing values if the field is hidden from the entity form (checked by default)

This way the user could opt out of the automatic update for a given field, by just exposing the field on the entity form.

Option 2 (configurable per field)

On the bundle creation / edit form, we have a new field inside the "Field Mapping" fieldset, which would be a set of checkboxes for the existing mapping relations:

  Fields to update on every entity save
  Description: "Mappings by default will be populated only on entity creation. If you want to update the mapped value on each entity update, please select below the fields where this operation should occur. Note that in some cases this may lead to a performance decrease, specially when dealing with remote media."
  [ ] Field 1
  [ ] Field 2
  [ ] Etc..  (<-- The checkboxes element would be rebuilt by ajax each time the user selects a mapping, being initially empty / hidden and adding a new option each time a user selects a new mapping field)
 

Per-field is better solution I think. It allows us to really define what we want. I also assume that in most cases people care just about a field or two being really up to date.

UI wise... Could we add a checkbox next to the existing mapping configuration?

I have file size mapped to a field (using media_entity_document) and it works on initial upload - the field gets populated. If I replace the file though the size stays the same. I really don't understand why it's the way it is. I know there's a similar issue with thumbnails.
I see what't the problem here, we don't want to overwrite some possible manual input, but what's the purpose of those mappings in this case? Let's force all the mapped fields hidden then. Is there a good use case for manually updating the mime type / file size / width / height or whatever?

I'm working on a project that would benefit from smarter metadata update logic. I might be able to assist in this (such as contributing a patch) or doing research.

It seems that the entity edit form could have a check box called "re-scan file metadata" -- for individual media enitities. Then on the "edit-media-bulk-form" form there could be a bulk action to rescan more than one entity. There shouldn't be any performance issues with this approach.

There isn't much work done on this issue so far, and at this point no new big features are foreseen for the 1.x branch of this module. New feature requests should be done against core 8.4.x+.

Forgot to close it.

@marcoscano media_entity_image links to this issue, see https://github.com/drupal-media/media_entity_image

NOTE that this behavior (only mapping the meta-data when the drupal field is empty) may change in the future, once this issue is solved: https://www.drupal.org/node/2772045

Do you have specific pointers to the issues discussed above or is the idea to just recreate them individually against core?

media_entity was added to core in #2831274: Bring Media entity module to core as Media module, and media_entity_image will be added to core in #2831937: Add "Image" MediaSource plugin.

I don't believe the feature request from this issue being discussed in any of those, but there are some issues (for example #2882801: Review and improve the media creation form or #2836153: Improve metadata mapping UI on Media type form) that are intended to improve the UI of the metadata when media is in core. I don't know if they will end up solving entirely the problem of the metadata not being refreshed when there is content in the fields. If that is the case, a new issue should probably be opened against core to deal with that.