Provide an optional migration path for sites using files/images to media entities

While technically a migration actually makes sense, it imples your data is moved, which as far as I understand and how media works in contrib is *not* what is happening at all.

This also only partially the right issue, but wanted to post it somewhere

Right now, the structure looks like this for an Article with images:

[Node] -> {ImageField with Image Widget] -> [File]

With Media, this is how it works right now in Contrib (usually):

[Node] -> {EntityReference with IEF/EntityBrowser Widget] -> [Media] -> {ImageField with ImageWidget} -> [File]

So nothing is *replaced*, we only add more things in between. You still use image fields, you still use the image widget (although that is often replaced with Dropzone in EntityBrowser, but that's optional, adding a new media through /media/add or editing it shows the ImageWidget)

Core will not add IEF/EntityBrowser/Dropzone in the near future but will instead implement its own new widget that will basically do the same, create a Media Entity that references a File in an ImageField/ImageWidget. You don't see that when editing the Article with the fancy new Widget, but when editing the Media Element itself, we still need a normal Image Widget in a normal Image Field.

That considered, I don't see how we could actually deprecate or even remove Image/File fields/widgets, internally, we still need them just as much as we did before? There will always be the need for a field/widget on media entities and there are also valid use cases for using them on other entities, when you on purpose don't want stuff to be in your media library for example (e.g. upload fields on contact forms or on other entities that normal users can see/use).

So, this duplicates part of the scope of #2835825: Add d8 media migration (I think) but that issue includes actually adding the Migration API for Media as well. I guess we can postpone this on that.

Re: #2, seems like this discussion is coming up across a number of the child issues. There is #2862458: [META] Once media is enabled, having the File, Image and Media reference fields all listed is confusing, and then the handwavy "Eventually" section of #2825215: Media initiative: Roadmap. And regarding widgets, #2831940: Create file field widget on top of media entity.

See #2930513-6: File/image field to media field migration, where @juampynr points to contrib code doing this.

Also, what is the relation of this issue to #2930513: File/image field to media field migration? It seems like #2930513 is a duplicate of this issue?

It seems to be a duplicate, yes. I'm closing that one in favor of this one, since this issue seems to have been more active.

So #2930513 was closed as a duplicate of this. Key information that was there but not here is @juampynr's #2930513-6: File/image field to media field migration, where he pointed to #3044434: Migrate image fields to media image fields — the Media Migration contrib module has code for this!

Going to unpostpone this - I've just switched a site from old image fields to media fields, and wrote a custom post update to do it in the end. If we're not going auto-update people, and I agree we can't, then we might just need an 'official' documentation page for this.

Because any update essentially 'copies' references from one field to another, while it's possible to use migrate, a custom update or drush command with old_field and new_field arguments would also do the job.

There are a couple of solutions in contrib:

https://www.drupal.org/project/image_field_to_media

https://www.drupal.org/project/migrate_file_to_media

(Also linking https://www.drupal.org/project/convert_entity_media_embed which solves a different but related issue).

The high-level view of how my custom update worked is similar to https://www.drupal.org/project/image_field_to_media

1. Create a new media field to hold the references from the old field.
2. In the post update, take the values of the old field, create a media entity, append it to the values of the new field + save the parent entity.
3. I left the old field in place (but hidden in form/display modes) since this provides an easy way to audit before/after, it can then be deleted later manually.

One issue I realised though, is that for file fields, we don't have an equivalent of the 'list' checkboxes, this is going to be a challenge for anyone with hidden files. The 'list' checkboxes tended to be used by people uploading images to those then embedding them in the node body (before media embed and similar existed), but that old content is still out there.