Convert 'Media' fields to 'File' fields that use the 'Media file selector' widget

This looks great I've got a lot of multimedia asset fields which I hear are now deprecated. So I would like to replace these with core filefields.

Any news regarding this great life saving feature?

I also had this problem - unfortunately I didn't find this issue back then (and the existing code). So here is what I did: https://github.com/niklasf/media/blob/1349058-mediafield-upgrade/modules....

It's less complete (in that it doesn't take revisions into account), but it uses the batch API to integrate the upgrade in the field UI. The combination of both approaches would be awesome :D

Marked #1493454: Convert the field handler from a deprecated mediafield to the new file entity module as a duplicate of this issue which also contains some useful code so I'm cross-linking it in case we want to use some of it as well.

Marking as Needs Review, as there is a patch.

Niklas Fiekas, many thanks for this patch!
It applies successfully, but when I starting upgrade process - batch process is go to 6% and stops at 10% (Copying field values) and didn't continue. It successfully creates new field (or works with already created), but in SQL field table is empty.
Where can be the problem? And how I can enable debug mode for find the problem?

I have found 2 problems in this patch and my drupal configuration:
1. After count query EntityFieldQuery is broken, I fix this via changing string
$context['sandbox']['max'] = $query->count()->execute();
to:
$context['sandbox']['max'] = $count_query->count()->execute();

2. My old mediafield have language dependency, so data is located in 'ru' array instead of 'und'. But new field have no language dependency, so data is located in 'und' array. I can't find how to detect language type for field, so fix this via changing:
$entity->{$target_instance['field_name']}[$lang][$key] = $value + array(
to:
$entity->{$target_instance['field_name']}[LANGUAGE_NONE][$key] = $value + array(

3. Entities in result are not ordered by entity_id, but have random order, so part ->entityCondition('entity_id', $context['sandbox']['current_entity'], '>') works bad.
I have remove this line and change line ->range(0, 10)
to ->range($context['results'][0], 10)

After those modifications all process finished successfully.
I have attached patch with my changes.

Sorry, forgot to remove line, here is right patch.

@Niklas @Murz Have you had a chance to re-visit this patch and get it working? Any updates, when you have time, would be appreciated!

This might work?

The patch from #11 missed the new file.

Yes, from a strict bare functionality POV this works because the data is transferred over. However, it needs further work:

• The Allowed File Extensions value should be copied over.
• The widget type should be set to Media File Selector.
• All widget settings should transfer over.

Updated patch with the following changes:

• The field settings should be copied over, specifically the number of items allowed.
• All widget settings are copied over, inc the description, 'required' status, and all "Media file selector" settings.
• The field's label may now be changed directly on the upgrade form.
• The field's name is now a machine name autogenerated from the label field, just like the normal Field UI widget.

Doh. This is the correct patch.

This version of the patch includes another message for after the upgrade has finished as a reminder to delete the old field.

A slight updated version that clarifies some of the code in mediafield_upgrade_form_submit().

One question for the group: should the upgrade process automatically delete the old field or should it be left for the visitor to manually remove it? If the field isn't to be removed, should the old data be detached?

Ooops, #17 didn't change the widget type, this patch will.

Might it be worth adding a hook_requirements note that provides a status message indicating all fields that need to be upgraded?

I think its better to leave the field and its data as is.
Or even better provide an option? eg a checkbox?

This is an updated version of #19 that adds a hook_requirements display listing all of the fields that should be upgraded, along with a link to do the upgrade.

This fixes the URL that the admin is given for the items in the hook_requirements message.

Another question: shouldn't the change be made to the field in place, i.e. change the *existing* field?

So, the outstanding questions are:

1. Shouldn't the existing field be changed rather than the data being copied to a new field?
2. If the current plan of creating a new field is kept, should there be an option to remove the old field after the conversion?

1 - Is it possible to just change the field rather than prompt to copy to new field? New fields might require adjustments of associations elsewhere.
2 - If a new field is created, keeping the old field rather than auto deleting might be preferred in instances of where the user needs time to update the content displays, etc. If the old field is removed automatically, dependencies will break instantly.

The latest patch worked in my testing. Pending further feedback as to direction to take, looks good as-is.

Seems this breaks stuff if field_group module is enabled (see screenshot)
Copying fields over seems to work as well for me, but i think what most users would want is to directly upgrade the existing field, not copy it over somewhere else..If they have views or custom code depending on this fieldname they would have to rewrite everything.

I think maybe the correct approach is writing an update_N function with this, but instead of copying field over, directly transforming it, maybe with temporary tables, like das-peter's patch.
And in the same time removing completely the mediafield module.

Or, another approach: transfer the module with the patch above to a separate project, so we dont have all this dead weight to media.

I dont know but we need to discuss this first a bit more imo.
What is the goal here? Killing the field type or keep it there and give option to update?

Lets refocus it on what many of us agree to be the main goal: to convert any existing 'media' fields to the 'file' field & 'media file selector' widget, keeping all existing settings.

I ran into the same issue where existing media fields used in field groups are just not updated when switching to the file_entity. I don't know if it is field_group's task to write the hook_update or if it's media's task.

This hook should update the field_group's identifier, group_name and entity type for each field_group that has media as entity type. When this has happened all fields will return to the right entity...

I used the latest patch against media head, and I confirm it works. I don't use field group so didn't test the (edge imho) use case presented.

This conversion feature is important for those who bet on media 1.x and want to move forward.

Has there been any development with this? I would like so much to be able to switch over but I am sure I am not the only early adopter of media module who has gotten trapped by this.

I am currently using 7.x-2.0-alpha1 as there is a note that says "there are still major WYSIWYG issues with the current code and are working hard to resolve them. Upgrade to alpha2/3 at your own risk." If I want to try the patch in #23, will it work? Do I need to update to alpha3 first, or to dev? Or should I run the patch first and then upgrade? Or was this patch incorporated into one of the alphas? Or do I have to still sit tight, getting more and more nervous that every time I update other modules that something will no longer play nice with alpha1 and my site will break?

What is the recommended workflow?

Agreed, das-peter's code needs to be reviewed again and improved upon.

Seems like this thread has been abandoned, is there a newer process that I can use? I hope it doesn't involve upgrading to media-2, because the last time I tested that upgrade process, it definitely did not work well enough for production.

I don't understand how to use this patch, my install of media-7.x-1.4 doesn't include the mediafield module, and the patch can't be applied. Also, how do I use the compressed php file? Do I put it in my drupal root and access it as user 1?

@safetyrpin This patch (#23) is to be applied to 7.x-2.x -branch of the media module. Have a look at https://www.drupal.org/patch/apply of how to use a patch. You prob. now this but do not attempt testing this patch in production. Run it in you private developer sandbox.

How does the move_media_to_file_field.php file play into the migration? Do I need to have a custom module that I can use to run it? The function name seems to indicate that I need to rename it for both my custom module and something else "N". Is this an individual media asset field name? Because, when I look at the code, it appears to be loading all media fields, and then doing something with all of them.

Is this file an alternative to the mediafield patch?

Ah, the zip-file. If you want to test that one, yes, it should go in a custom module, or you can run it from drush. Drush is able to bootstrap Drupal and run a stand alone php -file. N is the update number you want it to run as. More details on this in https://api.drupal.org/api/drupal/modules!system!system.api.php/function...

Reading patch #23 I do not think you need move_media_to_file_field.php. #23 should contain all you need to test this, I would start applying only this.

So, I setup local git working copy of the media module, applied the patch, and then created a symbolic link in my development environment to the patched version of the media module. When I look at the old media asset fields, I now see an upgrade link, but when I click that, and I get what appears to be the normal field editing page, but when I save the settings, nothing happens. Am I supposed to define a new field first?

Patch #23 works for me. Thank you!

Have rerolled patch #23 and added better upgrade links to ALL bundles using the field to the hook_requirements() messages.

Recent versions of media have resolved most of peoples concerns and is compatible with entity translation, multilingual and various advanced configurations. Due to the high volume of inactive and most often irrelevant issues we are Closing this as (outdated). If for whatever reason this issue is important to you AND you still have issues after checking the media recipe documentation, then let us know and we will review your concerns.

Otherwise, see the recipe documentation for how to configure media and for troubleshooting tips OR refer to the media_dev distribution if you want to see a working media setup.

As mentioned, feel free to make some noise in this issue if you still feel it is important to you or someone else.

Thanks,

Media team

I am going to re-open this issue. I see nothing in either documentation or latest Media 7.x-2.x branch that provide a migration path for old D7 sites with media field type "mediafield" (Multimedia asset) to file field. Feel free to correct me on this.