For those upgrading from 1.x to 2.0 or newer, please FIRST upgrade your media module 1.x to the latest 1.6 release, then once you have done that THEN upgrade to 2.0.

note, these instructions are out of date and refer to a pre release version of media 2.0, the upgrade path should be much smoother with the latest 2.0 release I noticed a few places where people are requesting instructions for upgrade from Media 1 to Media 2. I did this today and I've written up some short documentation (below). Please let me know if there is a better place for me to save this documentation for others to see.

I successfully upgraded to Media 2.0-alpha2 on an enterprise level site. This is somewhat tricky to execute, since there it requires an update of File Entity, too. File entity must be upgraded first. Then, a cron job is required to allow File Entity to classify the site's existing files into its file types (image, video, etc). Then, we can proceed to enable media and related modules.

Here is a step-by-step outline of what I did to accomplish this cleanly. I also cleared caches between many of the steps below (for example, after enabling a module).

1- Disable media and file entity modules (this will disable brightcove_media, media_internet, and so on).
2- Uninstall media and file entity modules.
3- Remove, download, and enable the newest version of File Entity (2.0-alpha2).
4- Run cron via drush elysia-cron.
5- Remove, download, and enable Media 2.0-alpha2.
6- Enable each sub-module of Media one by one.
7- There were no updates listed when I ran drush updb. What's important is enabling the File Entity module first, running cron, then moving onto the Media module. Otherwise, drush started throwing missing DB table errors and my site crashed.

*** EDIT ***
For simpler upgrades, see comment 21 by @ChaseOnTheWeb


sheldonkreger’s picture

Title: Document Upgrade Path from Media 1 to Media 2 » Document Upgrade Path from Media 1.x to Media 2.x

There are actually several DB updates which need to take place after you finish the steps above. For Media 2.0-alpha2, you will need this patch in order to run the DB updates successfully:

sheldonkreger’s picture

In some cases, I've also had to manually remove the SQL tables associated with Media and File Entity 1.x. That list includes:


This can be accomplished with 'drush sql-cli' for those who aren't familiar. Then, you use the MySQL interface to remove them, for example, 'DROP TABLE file_display;'

All of the tables needed for Media and File Entity 2.x are created by their respective install and update hooks. I suspect that these tables ought to be removed by the 1.x uninstall hooks (but they are not). The cron job for File Entity successfully loads my old files from the file system, and they are still attached to appropriate nodes and visible in all the same places I expect them to be.

idiaz.roncero’s picture

In my case, I had to drop the following tables:


groovedork’s picture

At what point in the proces did you delete them?

And will a non-drush cron work too? Not everyone has access to Drush.. (and wasn't the cool thing about Drupal it's gui-based approach?)

Alauddin’s picture

@sheldonkreger thanks for the post..came in handy even though I have updated a few times before.

Just a few helpful tips.

1) file entity ver1 - comes built into Media 1x, so you will find the folder there.

2) schema module will help to find the orphaned files -

3) after the update, if you had media_youtube - thumbnails dont work..need to configure the Structure >File Type > Video > Preview settings
Also, old media_youtube content did not work, which makes sense since I did disable/uninstall and did'nt try disable/upgrade to 7.2

Old Content > Files were missing the 'video' type (admin/content/file)
fortunately I only had a few to update.

Mile23’s picture

So the original post says: "Uninstall media and file entity modules."

That means, in effect, remove all Media-based fields from all entities.

That's not an upgrade path.

Is there any *better* step-by-step for this process? Because I can't find it.

sheldonkreger’s picture

Sorry Mile23, as far as I know, this 'upgrade path' did not have much development effort put into it. At the time, everybody was racing to get 2.x released ASAP.

IIRC, you can leave your media fields in place, but they will have to be re-configured after the upgrade. If you have Features which contain config for those fields, you will have to update them. You may also have to temporarily disable those Features during the upgrade. Note that disabling the Feature won't change any config on your site, because Features always writes settings to the DB. Those settings will stay in place in the DB until you turn the Features back on. Note if you have added custom module code inside your Feature - obviously that will stop running.

Believe me, I feel your pain on this one.

Teresa_’s picture

Pretty sure I am in the same problem area. Although I am updating from the 7-2-unstable7 to current. Maybe that's the first issue. Should I stick with alpha1 release? I am getting this error:

"base table or view not found: 1146 Table database.media_type SELECT mt.* FROM {media_type} mt ORDER BY weight ASC; Array() in media_type_get_types() (line 134 of ~/modules/media/includes/"

I did the file_entity update, updatedb, then media update and media_youtube update together, then updatedb. Not sure if this is correct and I don't understand the cron comment mentioned above. Does the cron automatically do the update or do I have to write a script?

Any help greatly appreciated. My goal is to get away from the unstable version that I inherited.

upunkt’s picture

I just upgraded

Media 7.x 1.4 -> Media 2.0-alpha4
File Entity 7.x 1.4 -> 2.0-beta1
plus File Entity Paths 7x 2.0-alpha3

I did not have to drop tables manually. Indeed, upgrading has been quite straightforward. This is what I did:

  • disable Media 1.4 and File Entity 1.4 without uninstalling
  • remove both folders from modules-folder
  • put Media 2.0 and File Entity 2.0 in modules-folder
  • enable Media 2.0, Media Field 2.0 and File Entity 2.0 (and Media WYSIWYG/WYSIWYG view mode if you need it)
  • there will be errors thrown from File Entity module, ignore them
  • run database update (45 pending patches for me)
  • clear caches


Alauddin’s picture

I just upgraded

media 7.x 1.4 to media 2.0

followed comments from #12 but I had other modules that needed to be disabled as well.

media file_entity media_internet emfield media_soundcloud media_vimeo media_youtube

1) disabled all of the above
2) deleted media folder (with contains file_entity 1x and media_internet)
3) downloaded Media 2x & file_entity 2x
4) enabled ALL the modules once again
5) ran db update
all the patches applied fine, no errors...schema shows no orphaned tables

rcodina’s picture

I successfully upgraded two sites using following steps (very similar to initial post from @sheldonkreger ):

1) Disable media and file entity modules
2) Uninstall media and file entity modules.
3) Remove old media module (which contains old file_entity and media_onternet)
4) Download new File Entity (7.x-2.x) and new Media (7.x-2.x) modules
5) Enable newest version of File Entity (7.x-2.x)
6) Clear cache and run cron
7) Enable newest version of Media (7.x-2.x)
8) Enable all submodules of Media (you can do it all at once)
9) Run update.php (optional: there will be no media module updates because we have uninstalled all media modules on step two)
10) Set up Media permissions for your roles
11) Checkout the rendering of every media field. You may need to change the formatter. Also look at admin/structure/file-types.
12) Clear cache and run cron

All file fields which you had configured with media module will remain intact because the widget configured for each field won't be deleted in any step. Also, the previous uploaded contact will remain intact too. The only thing you may have to reupload will be the videos.

steinmb’s picture

Version: 7.x-2.0-alpha2 » 7.x-2.x-dev
Priority: Minor » Normal

We should get information out of this issue and into a documentation page if there is anything special about this compared to the official doc -

There exist a normal migration/upgrade —path taking us from 7.x-1.x to 7.x-2.x that running update.php (drush updatedb) will take care of. Uninstalling before upgrading is not upgrading, it is reinstalling and could (should) result in loss of data and settings. Any bugs found upgrading should end up as separate issues and not in a list of work-around(s).

Alauddin’s picture

My previous comment #14 does upgrade...not uninstall and then reinstall ...which will result in data loss.

If using much faster.

#drush dis media -y

This will give you something like this - disabling all dependent modules
The following extensions will be disabled: media, media_internet, emfield, md_slider, media_vimeo, media_youtube

#rm -rf media
#drush dl file_entity
#drush en file_entity -y

now enable all the modules that were disabled above
#drush en media, media_internet, emfield, md_slider, media_vimeo, media_youtube
#drush updb

that should update your media 1x to media 2x while keeping your content

devad’s picture

Thnx Alauddin. #10 worked for me perfectly.

Media upgrade 7.x 1.4 to 7.x 2.0 alpha 4

jprstoney’s picture

#9 upunkt / #10 Alauddin worked for me. No error messages, no format/field data loss. Excellent. Thanks!

dokumori’s picture

Status: Active » Needs review

Just added a documentation on the upgrade process:

I've recently updated the Media module from 1.x to 2.x and documented the process. Since the site was moderately complex and configs were managed through Features, it was a lot more involved than just changing values in the DB tables.

If anyone is planning on upgrading the module to 2.x, please follow the doc and report back if it worked. If it did, then this issue can be closed.

BTW I have a lot more information in relation to the process, but it has more to do with deployment processes and best practices so I did not include it in the handbook. I'll probably make that into a blog post.

steinmb’s picture

@dokumori thanks for getting the ball rolling :) One quick question: Step 1 ( is this really necessary? I mean the media browser widget works on both images and file - field types?

safetypin’s picture

I've attempted to upgrade from media 1 to 2 a couple of times on a web site without success. In these times, I haven't even attempted to disable media, or the file_entity modules, I just replaced the code, and ran DB update, since this is the process I've used in the past to update modules. However, when I attempted to follow the instructions here to disable those modules, I got an error: media is a required module and can't be disabled. Reason: Field type(s) in use - see Field list. Is disabling media really necessary? Why am I getting this error and noone else has mentioned it? I just did a quick google search, and didn't see any results mentioning this error/problem. Is there a way for me to get around it?

steinmb’s picture

@safetypin no need to disable any of the modules when upgrading but make sure you download a new version of both media and file_entity module before attempting and upgrade (db update).

lanceh1412’s picture

When upgrading I got the following message:
Notice: Undefined index: undefined in _field_ui_bundle_admin_path() (line 325 of /var/www/mysite/htdocs/modules/field_ui/field_ui.module).

I needed to enable media_migrate_file_types and then go to admin/structure/file-types/upgrade and transfer all the undefined types to image.

ChaseOnTheWeb’s picture

I did a test run of upgrading our code base from 1.5 to 2.0-beta1, and things generally went pretty smooth.

1. Did not disable old media or file_entity modules (and couldn't because of fields being in use)
2. Deleted old module directories and downloaded new versions
3. Ran upgrade script. It seemed to go smooth and even enabled the modules that now need to be on because of refactoring (media_field, media_wysiwyg, etc).
4. Tweaked some hook implementations that changed between major versions (in my case media_token_to_markup_alter changed its name and render array structure)
5. Changed media_wysiwyg configuration to use legacy rendering
6. Figured out the new permissions and rebuilt feature so that users can still upload files

As best as I can tell, everything just works.

I didn't need to convert any file fields to image fields as mentioned in . I don't know where that step came from as I don't see any changes in the code from 1.x to 2.x that would have necessitated that.

The one screwy thing the upgrade did that I can't figure out is that it changed the image style named square_thumbnail to media_thumbnail, but the preview in the media_wysiwyg upload dialog is still trying to use the machine name square_thumbnail so I'm getting 404s. That machine name isn't hardcoded in Media module anywhere that I see so I'm not sure where it's coming from. For now, I just recreated the square_thumbnail image style.

koffer’s picture

Issue summary: View changes
koffer’s picture

Issue summary: View changes
joseph.olstad’s picture

Issue summary: View changes
Status: Needs review » Needs work
joseph.olstad’s picture

Issue summary: View changes
joseph.olstad’s picture

7.x-2.0 was released April 2017.

This issue is for reference purposes. The actual upgrade path should be far easier now than it was when this issue was created.

Before upgrading, please make a copy of your installation / site and perform the upgrade on a test environment first.

skessler’s picture

See post #21 these look better after all.


steinmb’s picture

Hi @skessler. I do not understand why you choose to uninstall Media 7.x-1.x before "upgrading". Care to share with us why you opted for a re-installation instead of a regular upgrade?

joseph.olstad’s picture

Issue summary: View changes
joseph.olstad’s picture

Issue summary: View changes
capysara’s picture

Thank you everyone for contributing to this documentation!

After following some older documentation (and failing), I started following instructions in

When I tried to apply pending database updates ("3. Ran upgrade script.") , I got SOME of the pending updates, but then I received an error and I couldn't get the rest: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '1-view files' for key 'PRIMARY'. It's because of my previous failed attempts, but this helped me resolve it:

joseph.olstad’s picture

Issue summary: View changes
capysara’s picture


I'm not sure if I'm getting my wires crossed because I keep undoing and redoing things or if I'm missing something that I need. I just noticed the change to the issue summary that says "update to 1.6 first." Why do we need to to that? I tried restoring my site from a backup, then updated from 1.5 to 1.6, then followed instructions in #21, and now I'm getting an error when I'm updating the db: Table field_data_field_file_image_alt_text already exists.

It looks like the database update that occurred when I updated to 1.6 (7021 - Rerun media_update_7002() due to a typo that would prevent table creation) was included when I just jumped straight to 2.0.


Update: I tried it again, but this time I dropped my tables before I did the database import, updated to 1.6, and then updated to 2.0. It updated with no errors. I also did not get the error from my previous comment (SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '1-view files' for key 'PRIMARY').

skessler’s picture

Hi @steinmb. I did what I did because I did not look at 21 just the main post and it worked for me. That you to whoever crossed out the instructions in the issue summary and pointed out the instructions in #21.

steinmb’s picture

Perhaps we can start by replace/moving with the simple one line note in this issue summary about minimum 7.x-1 release to have before attempting a upgrade to 7.x-2.x - And then point to the Drupal official doc - We should not duplicate a standard module upgrade.

steinmb’s picture

@capysara 7.x-1.6 ( contains that I think might cause some grief to old installation during upgrade.

joseph.olstad’s picture

Seems like few are actually does a backup of schema before upgrading. If someone happened to do a backup, could they retest the upgrade following the steps going to 1.6 and updb then going to 2.0 and confirm for us which is the easiest, error free way to upgrade.

note the square_thumbnail image style that probably needs to be manually created after the upgrade so that the media browser thumbnail items have thumbnails, as a manual step (again, see comment #21) (would be nice to have a patch for this, checking for the missing image style , or figure out why after upgrading the new image style media_thumbnail is not used.

arnoldbird’s picture

Following an upgrade from 1.4 to 2.0, I can no longer upload files. I did not first upgrade to 1.6 because I didn't think that release was available anymore, since it isn't displayed on the project page.

ChaseOnTheWeb’s picture

@arnoldbird Have you reviewed the permissions for File Entity and Media modules? The permission are structured quite differently from 1.x to 2.x and you will need to add upload permission to the desired roles.

arnoldbird’s picture

The solution in my case was to upgrade pathauto to version 1.3.

In my PHP error log I was seeing the "Call to undefined function pathauto_entity_language()" error mentioned in this bug:

After upgrading pathauto and running update.php, I am now able to upload files again.

TimDix’s picture

After an upgrade, I'm not seeing any files in the media browser.

The procedure I followed:

  • Upgrade from Media 7.x-1.5 to 7.x-1.6
  • update.php
  • Upgrade from Media 7.x-1.6 to 7.x-2.0
  • Install File Entity module 7.x-2.0-beta3
  • update.php

I cleared the cache. Any suggestions?

joseph.olstad’s picture

@Timdix, please see comment 21 about creating the missing square_thumbnail image style 180px x 180px

If I have time I will try to make a new release fixing this, but for now it is a manual step in the upgrade.

Stephen Ollman’s picture

Upgraded from: Media 7.x-1.6, File Entity: 7.x-1.6
Upgraded to: Media 7.x-2.0, File Entity 7.x-2.0-beta3

  1. I disabled the two modules first, then updated the code base.
  2. Re-enabled the two modules and ran update.php (46 updates, no errors)
  3. IMPORTANT!!: Set permissions for file types and media elements
  4. Cleared cache and rebuilt permissions

Worked like a charm with no errors!

joseph.olstad’s picture

@Stephen Ollman , good to hear, I am wondering however, did you happen to notice missing thumbnails in the media browser as documented near the bottom of comment #21?

TimDix’s picture

@joseph.olstad I appreciate the help. It looks like square_thumbnail is already set, I didn't have to recreate it, perhaps it isn't setup correctly?

Any other suggestions on how to make this work?

TimDix’s picture

@Stephen Ollman

Step 3, Set permissions, can you elaborate on what you needed to do to make this work?

joseph.olstad’s picture

@TimDix , please try this

also, make sure sites/XYZ_or_default/files/styles is writable by the server. (check permissions)

Let us know if these two suggestions helps.


TimDix’s picture

@joseph.olstad - Thanks for the follow up.

  • I went to the link, and confirmed my settings were already set that way:
  • Also, sites/default/files/styles was 775, and is owned by the apache user. For testing, on local dev, I switched it to 777 and confirmed no difference.

Any further suggestions?

steinmb’s picture

Go to /admin/content/file/thumbnails how to does this look like? If broken, check your log after visiting /admin/content/file/thumbnails - There should be errors and warnings.

TimDix’s picture


Here's the page you mentioned, there are no thumbnails for any file at all:

Examples of the types of errors I see in the error log.

File does not exist: /pathto/sites/default/files/styles/square_thumbnail/public/statue_of_liberty_scroller3.jpg, referer:
File does not exist: /pathto/sites/default/files/styles/square_thumbnail/public/statue_of_liberty_scroller2.jpg, referer:
File does not exist: /pathto/sites/default/files/styles/square_thumbnail/public/statue_of_liberty_scroller.jpg, referer:
File does not exist: /pathto/sites/default/files/styles/square_thumbnail/public/pipe of liberty_0.jpg, referer:

joseph.olstad’s picture

Hi TimDix , can you run these two commands:
1) cd /pathto/sites/default/files
2) find -name statue_of_liberty_scroller2.jpg


What you can do is try deleting the contents of the 'styles' folder , it gets recreated after a cache clear and subsequent page loads

however if the original file does not exist then the image style 'square_thumbnail' will not be able to create the thumbnail.

If you think this should work and are not missing the original files but doesn't work for some reason , try a registry rebuild.

joseph.olstad’s picture

@TimDix, the file statue_of_liberty_scroller2.jpg in your case should be in the root of the files folder. Is it not present?

The path to the styles image has enough information to determine the path of the original file. square_thumbnail/public means the original is supposed to be in files/

latin_miracle’s picture

Issue summary: View changes

I finally was able to install 2.0 with out errors, but now whenever I click on any item link or edit option in "Administration » Content » Files" I get an ERR_EMPTY_RESPONSE message.

I have all errors messages enabled and am not seeing anything tracking in the error logs.

Here's what I've done so far:
- Updated from 7.x-1.4 to 7.x-1.6
- Removed the following tables from DB:
-- field_data_field_file_image_alt_text
-- field_revision_field_file_image_alt_text
-- field_data_field_file_image_title_text
-- field_revision_field_file_image_title_text
-- file_metadata
-- media_view_mode_wysiwyg
-- media_restrict_wysiwyg
- Replaced Media 7.x-1.6 with Media 7.x-2.0 and file_entity 7.x-2.0-beta3
- Ran update script
- Ran cron
- Flushed all caches
- Enabled permissions for Media module

After all that I also tried to convert the existing file types via "Administration » Structure » File Types" with no luck.

I also figured it was an issue with the existing images, so I uploaded a new JPG to see if I could access it once uploaded. Turns out the file uploaded fine, but I keep getting the ERR_EMPTY_RESPONSE when trying to view or edit it.

Any idea what could be causing this problem?

latin_miracle’s picture

Issue summary: View changes

First time posting and deleted issue summary. Oops. Re-adding.

TimDix’s picture


1/2) The file is there, as are all the rest.

I deleted the styles folder, and did a drush cache-clear all, the styles directory was not recreated. I tried going to several pages, and launching the media browser, but the styles directory was not created.

permissions on the file directory:
drwxrwsr-x 9 apache timdix 20480 Apr 26 14:09 files

So, server should be able to write no problem.

I attempted to rebuild the registry using the instructions here:

With the following output:

[default] $ drush rr
The registry has been rebuilt via registry_rebuild (A). [success]
The registry has been rebuilt via registry_rebuild (A2). [success]
All caches have been cleared with drush_registry_rebuild_cc_all. [success]
The registry has been rebuilt via drush_registry_rebuild_cc_all (B). [success]
All caches have been cleared with drush_registry_rebuild_cc_all. [success]
All registry rebuilds have been completed. [success]

Does any of this help shed any light onto the issue?

joseph.olstad’s picture

@TimDix , did you find anything helpful in the watchdog (report logs) ?

also, try going to reports status , see if there's any recommendations in there that might help.