This document how to switch Drupal major version by upgrading from Media 7.x-1.x to Media 7.x-2.x or 7.x-3.x.

Make sure you Back Up

Before attempting to upgrade. Please backup. Follow the official Drupal documentation on how to do this.

Why back up? The upgrade path is stable but there could be something in your installation or data, that will cause the upgrade to fail. Tracking down the problem and fixing it, often require you to both restore file and database before running the upgrade again. There is no safe way of re-running the upgrade if you do not have a backup of your database.

Upgrading Media

Now that you have backed up your db and files you can safely upgrade your Media module installation. For those upgrading from 1.x to 2.3/3.0-alpha8 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.3 or 3.0-alpha8.

Upgrade by using drush

The easiest fastest way is by using drush, that is, if you have drush installed.

  1. If you are not on the last release of th 7.x-1.x branch:
    1. drush dl media-7.x-1.6
    2. drush updatedb
  2. drush dl file_entity #(pulls latest stable 7.x-2.x release.)
  3. drush dl media #(Downloads the latest 7.x-2.x branch.)
    - (Or to upgrade to the 7.x-3.x branch, "drush dl media-7.x-3.0-alpha7" This downloads the specific 7.x-3.0-alpha8 version. Find the latest 3.x version to download on the media page.)
  4. drush en file_entity
  5. drush updatedb
  6. drush cc all #(Optional: Clears all caches)

Upgrading without drush

  1. If you are not on the last release of th 7.x-1.x branch:
    1. download media-7.x-1.6
    2. Run update.php
  2. Disable media-7.x-1.6 at /admin/modules
  3. Download the latest version of file_entity 7.x-2.x
  4. Download the latest version of media 7.x-2.x or 7.x-3.x
  5. Enable file_entity module.
  6. Run update.php
  7. Clear all caches at: /admin/config/development/performance (Optional)

Additional Configuration(s) Needed

  1. Go to: /admin/people/permissions and configure all permissions for File Entity in the way that suits you
  2. stub: see #2082037-98: Document Upgrade Path from Media 1.x to Media 2.x/3.x

Known Problems

PDO exception
If you run into PDO issues about duplicate entry 1-view files, then follow this:

Fatal error
If you hit a “Fatal error: Call to undefined function {yourtheme}_form_system_theme_settings_reset() in .../includes/ on line 1520,” see: #2884164: theme no longer behaves since upgrading from media <=2.0-alpha3

Thumbnail images
If your thumbnail images are missing, see: #2486599: missing square_thumbnail causes Broken images in media browser and file/thumbnail

#97 Media___Drupal_org.png51.46 KBsteinmb
Members fund testing for the Drupal project. Drupal Association Learn more


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.

Stephen Ollman’s picture

In my steps at #43 I mention setting permissions. Here's more info on that.

Prior to setting the permissions, if you look at /admin/files you may notice that the 'edit' and 'delete' links are missing under the 'Operation's column.

In order to fix this I needed to go to the sites permission page at: /admin/people/permissions and find the 'File Entity' section. Here I set my admin roles with the correct edit and delete permissions on the various file types.

Hope that helps.

Have done steps at #43 a few times now and it seems to work without issue.

Ari Linn’s picture

Tried upgrading from Media 7.x-1.6 to 2.0 and it mostly went uneventful, no errors, my image library looked the same... until I tried uploading a new file. Here I suddenly found that image processing stopped working completely for new images. No styles generated, no thumbnails created, no nothing. Newly uploaded files are shown as blank squares: (article edit page) (image library page)

I checked my image folders and found that before the upgrade my files were created at least at 4 places (medium and my_square_thumbnail were used in articles and square_thumbnail was apparently used by Media):


After the upgrade, I'm finding my files in only one place:


I'm not seeing any drastic changes to my image styles though, they look correct: (list of image styles)

Anyone else having this weird problem with new files? Any ideas on how to get styles back to work?

steinmb’s picture

@Ari Linn - Check your drupal log. There should be hints in there to why presets are not generated.

djob’s picture

#43 did it for me. Tested on dev site then live. All worked perfectly :)
Thank you @Stephen Ollman

Ari Linn’s picture

@steinmb , checking /admin/reports/dblog was literally the first thing I did, and as far as I can see the log is crystal clear. No errors at times of file uploads, no php notices or warnings on top of my pages after uploading. As if the code for styles generation just stopped being called. I guess I'll need to debug it more thoroughly after all...

pavelmsokolov’s picture

#43 works for me too. However it seems it had to install file_entity prior to updating meda, otherwise i got conflicts.

drush instructions:

1. drush pm-disable file_entity; drush pm-disable media
2. drush dl file_entity (override:yes), drush dl media (override:yes)
3. drush en file_entity (this is important to install file entity before media, otherwise i got conflicts)
4. drush pm-update drupal
4* if you run into PDO issues about duplicate entry 1-view files, then follow this:
5. drush en media
6. drush pm-update drupal
7. Go to people/permissions and configure all permissions for File Entity in the way that suits you

joseph.olstad’s picture

@pavelmsokolov , yes this you have documented the correct answer, thanks.
I will update the issue summary and description.

joseph.olstad’s picture

Issue summary: View changes
joseph.olstad’s picture

Issue summary: View changes
joseph.olstad’s picture

Issue summary: View changes
Status: Needs work » Reviewed & tested by the community
joseph.olstad’s picture

Title: Document Upgrade Path from Media 1.x to Media 2.x » Document Upgrade Path from Media 1.x to Media 2.x/3.x
joseph.olstad’s picture

Issue summary: View changes
joseph.olstad’s picture

Issue summary: View changes
joseph.olstad’s picture

Issue summary: View changes
rjunction’s picture

On several sites I've used the following without error:

drush dl media (this removes the file_entity module packaged with media 1.x)
drush dl file_entity
drush updb

steinmb’s picture

Status: Reviewed & tested by the community » Needs work

1. drush pm-disable file_entity; drush pm-disable media

Not needed. Hook_update_N() run for even disabled modules.

3. drush en file_entity (this is important to install file entity before media, otherwise i got conflicts)

5. drush en media

Mention above. I see no reason to disable and by not doing so. This step is unnecessary.

4. drush pm-update drupal

6. drush pm-update drupal

Why update drupal? We should run drush updatedb or run to trigger the needed update tasks.

joseph.olstad’s picture

Issue summary: View changes
joseph.olstad’s picture

Issue summary: View changes
joseph.olstad’s picture

@steinmb , good points, I adjusted the steps accordingly.

joseph.olstad’s picture

Status: Needs work » Needs review
steinmb’s picture

Issue summary: View changes

Tried to clean up the document. I personally would like keep 7.x-3.x out of the doc. We should document 7.x-1.x to 7.x-2.x upgrade. It is this one that could be a little tricky. Keep it clean, short and sweet.

Michael-IDA’s picture

Issue summary: View changes

added "drush dl media-7.x-1.6"

Michael-IDA’s picture

Issue summary: View changes

Cleaned, clarified, and added additional instructions to the bullet lists. I got tired of formatting the bullet lists, and don’t really want to add a dozen more comments for nitpick changes, so I left the bullet list below as a replacement option. Re-write as desired...

This does needs to replace the Community Documentation, , as quickly as possible though.

==== Edit ====
'doh, now I'm editing this comment a dozen times :(

I followed these instructions upgrading from 7.x-1.5 to 7.x-2.3 and while most things work, inline colorbox-load is completely broken. Not that it was that easy to get 1.x to do colorbox-load in the first place. I’ll add a link here if/when I find a solution to make inline colorbox work in media 2.x.

  1. drush dl media-7.x-1.6
    - If you are not on the last release of th 7.x-1.x branch.
  2. drush dl file_entity
  3. drush dl media
    - Downloads the latest 7.x-2.x branch.
    - (Or to upgrade to the 7.x-3.x branch, "drush dl media-7.x-3.0-alpha7" This downloads the specific 7.x-3.0-alpha7 version. Find the latest 3.x version to download on the media page.)
  4. drush en file_entity
  5. drush updatedb
  6. drush cc all
    - Optional: Clears all caches
  7. Go to /admin/people/permissions and configure all permissions for File Entity in the way that suits you
  <li>drush dl media-7.x-1.6<br> - If you are not on the last release of th 7.x-1.x branch.</li>
  <li>drush dl file_entity</li>
   <li>drush dl media<br> - Downloads the latest 7.x-2.x branch.<br> - (Or to upgrade to the 7.x-3.x branch, "drush dl media-7.x-3.0-alpha7" This downloads the specific 7.x-3.0-alpha7 version.  Find the latest 3.x version to download on the media page.)</li>
  <li>drush en file_entity</li>
  <li>drush updatedb</li>
  <li>drush cc all<br> - Optional:  Clears all caches</li>
  <li>Go to <codex>/admin/people/permissions</codex> and configure all permissions for File Entity in the way that suits you</li>

* replace codex with code

joseph.olstad’s picture

Status: Needs review » Needs work

The instructions needed one last tweak.

joseph.olstad’s picture

Issue summary: View changes
joseph.olstad’s picture

Status: Needs work » Reviewed & tested by the community
joseph.olstad’s picture

Issue summary: View changes
Michael-IDA’s picture

Issue summary: View changes

Works for me.

Changed all drush database updates to "drush updatedb" for consistency.

PS: Good call on adding a database update prior to starting!

steinmb’s picture

I'm not happy with docs. that explicit say download a version number. The documentation quickly fall out of sync as new versions comes out.

joseph.olstad’s picture

imho , the version numbers are a point of reference , and it's probably important if upgrading from 1.x to first upgrade to 1.6 , as there's quite a few 1.x versions and the upgrade path is really 1.x to 1.6 then from 1.6 to 2.3 or newer

Michael-IDA’s picture

Issue summary: View changes

I agree Stein, but like Joseph points out the only hard coded version number is 1.6, which has to be. I did re-write the comment you are referring for better clarity.

Michael-IDA’s picture

Status: Reviewed & tested by the community » Needs work

Unfortunately after further testing, this isn’t all that’s needed for the upgrade path.

  • Prior content that used the media button in line with a link in WYSIWYG, comes through correctly.
  • New content that uses the media button in line with a link in WYSIWYG, now produces garbage HTML that includes H2 elements inside of the image code. Example at bottom.
  • If you edit an existing in line image in any way it breaks as well.

Looking through,

Upgrading Media 7.x-1.x to 7.x-2.x

doesn’t seem to have anything that pertains to what makes the media button work. Does any of what’s on that page still apply in any way? If so, it should be captured in these new instructions.

# # #

Any thoughts on where to look for media button snafu’s?


Example of raw page source (straight copy/paste):

continuous high plasma level (blood concentration) of Vitamin C will strongly inhibit, and possibly kill, many forms of cancer.</p><p style="margin-bottom: 0in; line-height: 100%"><a class="colorbox-load" href="/sites/default/files/public/RF1010x.jpg"><div class="media media-element-container media-preview media-wysiwyg-align-left"><div id="file-171" class="file file-image file-image-jpeg">

        <h2 class="element-invisible"><a href="/file/171">RF1010x.jpg</a></h2>
  <div class="content">
    <img alt="AltText" title="TitleText" class="media-element file-preview" data-delta="1" src="http://d7pat.localhost/sites/default/files/public/styles/square_thumbnail/public/RF1010x.jpg?itok=Dr_z-Ex9" /></div>

</div></a></p><p style="margin-bottom: 0in; line-height: 100%">Links/Notes
joseph.olstad’s picture

@Michael-IDA , are you using the recipe?

Either way, see if there's an open ticket for this issue you describe and mention your configuration.

joseph.olstad’s picture

@Michael-IDA, have you tried 7.x-3.0-alpha7?

steinmb’s picture

Status: Needs work » Reviewed & tested by the community
DeveloperChris’s picture

At step 5 when running drush updatedb an error occurs
SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '1-view files' for key 'PRIMARY'

To get around this error after step 4 and before step 5 go to the permissions tab and remove the view files permission which is auto created when the module is installed

I do not know if this has a material effect on the updatedb command. if the error is ignorable then perhaps a note above to say something to this effect would be an idea.

joseph.olstad’s picture

Issue summary: View changes
joseph.olstad’s picture

Regarding comment #92
That should be fixed for fresh upgrades from 7.x-1.6 to 7.x-2.4
if not then please report it on this issue:
#2871153: Upgrade from 1.x breaks at update_7203 with duplicate entry 1-view files for primary key

Michael-IDA’s picture

Status: Reviewed & tested by the community » Needs work

> Michael-IDA , are you using the recipe?

No, didn't know it existed...

At first glance that recipe is hugely beyond just tying to upgrade from one version to another as its first step is to check for, and install, Drupal core. It’s also so recommended patch heavy, there’s no way someone could use that to create a production site, besides which:

“Media CKEditor: This project is not covered by Drupal’s security advisory policy.”

Really that doc needs a huge disclaimer, “For development uses only!”

A reference to that does does need to be added to this documentation, but it definitely shouldn't be a “must-do” step.

# # #

As a note, the site I’m working on will be in production use, with financial transactions, so I don’t have the option of using sandbox, dev, uncommitted patches, or anything not covered by the security advisory policy.

Which brings up an assumption I’m making, that this doc is for production use?

Really that needs to be explicitly clarified on all of these docs, so...

Please add explicit declarations to all these docs as to whether they are written for “Production” use or for “Development” testing.

# # #

I did get the inline colorbox to finally work (and kept notes), but it’s a completely different method than was used in 1.x. It took digging through half a dozen other documents to find the configuration differences between 1.x and 2.x.

As well, I’ve either not found all the config differences, or there seems to be something hugely broken in 2.x related to trying to get links to work with the media button. e.g. after upgrading I’ve found NO way to add a link using the actual media button form. Whatever these configs differences are, they also need to be added here, or if they are truly outright bugs, then the issue needs to be linked to.

The notes are in developer pidgin. I’ll check them against the recipe above and then do a write up. But that won’t be this weekend.

Moving this back to “Needs works” as there are too many things that aren’t addressed that need to be, and just using what’s currently written would leave a normal user completely stranded.


joseph.olstad’s picture

The recipe is a drush make file that anyone with drush can run. It is easy to use. It is also a point of reference.

The media module can work with or without some of the modules and libraries and patches, with either or neither of media_ckeditor, or wysiwyg or multiform or plupload.

Media can work with ckeditor or tinymce or other wysiwyg editors or without them

Media is feature rich and integrates with many other modules. It is covered by the Drupal security team, however some of these other optional modules are not.

many have thanked us for the recipe , but this recipe is just one of many. We propose this one because it is feature rich and allows easy to use gui functionality such as bulk uploading and wysiwyg integration and more.

While this is easy stuff for your content people, it does require some skill level to set up.

If you want an easy recipe then install the module as any other and just use the basic widget functionality and for the media browser.

Or try D8 media in 8.4.x, it is in core for 8.4.x. For D7 we are doing our best to support the installed base of over a quarter million, so if we only have a few issues per day or week out of 280000 then I would say we are doing a pretty good job.

steinmb’s picture

Status: Needs work » Reviewed & tested by the community
51.46 KB

@joseph.olstad the doc is OK. As maintainer of Media. Could you add it to Media project page as a official upgrade doc? And we could then close this issue. Support and new issues should go into separate issues.

media doc

Michael-IDA’s picture

Status: Reviewed & tested by the community » Needs work

No, this document does not fully upgrade a site from Media 1.x to 2.x, reseting to 'needs work.'

As written, people are left with multiple broken parts of Media to go fix.

The latest 'bug' I've found is that thumbnails are no longer generated.

My developer pidgin to date, all of these need to be mentioned in this document...

Edit: Cleaned up, with better sectioning.

:: Media

Admin Config: /admin/config/media/browser

- Verify appropriate “Enabled browser plugins” are selected.

- (Re)Enable "Use the media browser" permission
Path: /admin/people/permissions

- Fix thumbnails (Preview) are no longer generated.
Path: /admin/config/media/image-styles/add

Style name: Square Thumbnail
Machine name: square_thumbnail
Scale and crop 100x100

- Fix directory permissions as needed.

cd /sites/default/files
find . -type d -exec chmod o+x {} \;

Note: Do this if you get a “403 Forbidden or 401 Unauthorized” HTTP response code when trying to access a file known to exist on your file system.

:: Colorbox

Admin Config: /admin/config/media/colorbox

- Follow instructions in Colorbox README.txt
- Verify Colorbox is using the correct Library
- Verify "Load content in a Colorbox: is enabled
- Verify "Load inline content in a Colorbox: is enabled

Additional Config: /admin/structure/file-types/manage/image/file-display

- Verify "Colorbox" is checked for either "Default" for "Link"

- New method to add a pop up colorbox link:

A) Click the "Media Browser" button.
B) Add your file from the site "Library" or "Upload" as needed.
C) Change "Display as" to "Link" [1]
D) Add Alignment, Alt Text, and Title Text as desired.
E) Click Submit

[1] In line images that link to an original or colorbox pop-up must now use the "Link" display. It is the only one that works to pop up a colorbox.

:: Wysiwyg

Admin Config: /admin/config/content/wysiwyg

- Follow instructions in Wysiwyg README.txt
- Verify Text formats are set up correctly

This is my Filter processing order, yours may differ:

Ensure that embedded Media tags are not contained in paragraphs
Convert Media tags to markup
Correct faulty and chopped off HTML
Convert URLs into links*

- Verify your Wysiwyg profile is using the correct Library

For CKEditor:

cd sites/all/libraries
rm -fr ckeditor
wget -c ""

If you load the Admin Config page and get an error message like:

"CKEditor (Expected version: but found"

Edit the profile and “Save.”

:: Other Clean Up

Path: /admin/content/file

- Remove any broken images created during the upgrade process.
- Cleanup Nodes shown using broken images.

steinmb’s picture

Status: Needs work » Reviewed & tested by the community

Please stop changing status. This is not a support issue (even if it some time looks like it). It is a document covering how to best switch media major version in Drupal 7. It's scope is not to cover the multiple media related modules out there that people might have turned on. Instructions related to extra media modules should go into a separate documents. Let us keep this short and sweet.

Michael-IDA’s picture

Status: Reviewed & tested by the community » Needs work


Please stop changing status. This is not a support issue . It is a document covering how to upgrade Media 1.x to Media 2.x/3.x.

It's scope is to cover what is ACTUALLY needed to NOT have a broken Media module after completing the steps in this document.

Instructions related to extra media modules that upgrading Media 1.x to Media 2.x/3.x breaks, must be presented to achieve that.

Let us keep this useful, usable, accurate, and not half-baked.

joseph.olstad’s picture

I've tried to add a documentation page using the 'new and improved?' documentation system but much prefer the old book page ones.

Thinking of handing over maintainership of this module to someone else to pick up and run with it. Pass the baton so to speak.

steinmb’s picture

I've tried to add a documentation page using the 'new and improved?'

Eh, cannot find it. Did you remember to press save or am I temporary blind?

joseph.olstad’s picture

It is here, and makes no sense at all.

joseph.olstad’s picture

Here is the discussion, it makes no sense to me.

Michael-IDA’s picture

For brevity in this thread, this upgrade issue from M1.x to M2.x has been moved to:

#2884164: theme no longer behaves since upgrading from media <=2.0-alpha3

Summary of Error Found:

WSOD: “Fatal error: Call to undefined function theme1033_form_system_theme_settings_reset() in /includes/ on line 1520”

Future resolution will be added to this documentation as appropriate.

joseph.olstad’s picture

Michael, Please start a new issue. Appears to be way out of scope.

Michael-IDA’s picture

Edit: Questions and Conversation removed:

Relevant text left:
The errors in my last post are definitely related to upgrading Media from 1.x to 2.x.

joseph.olstad’s picture

commonpike’s picture

Just updated without Drush, from 1.6 to 2.6 on Drupal 7.50

You can not install file_entity as long as the old media module is installed, because 'it is already installed'. That makes the 'upgrade path' as described undoable. I managed to do this painlessly sofar by

- disabling (but not uninstalling) all media related modules
- moving the sites/all/modules/media/file_entity folder out of the drupal tree
- install file_entity (no db updates as it is disabled)
- enable all media related modules (downloads some translations)
- update media and run the (48!) pending db updates

joseph.olstad’s picture

commonpike , there must have been a duplicate copy of media in your filesystem because the documented steps account for this. Notably because replacing 1.x media with 2.x media effectively removes the old file_entity sub module because it IS a sub module. If you had a problem here, it was very likely because you had too many copies of this module in there.

For this reason I recommend running the duplicate module finder
module , this module will help you find extra copies of modules on your filesystem. Once you locate the extra copies of modules you can decide which one should be there and which one shouldn't.

joseph.olstad’s picture

For everyone else, please do NOT respond to any messages here, instead, open a new support issue for any new questions or comments. Thank you.

commonpike’s picture

@joseph.olstad (sorry for posting it here, but my comment is only about the documentation provided here...)

The documentation for non-drush upgrades, above, reads

  1. Download the latest version of file_entity 7.x-2.x.
  2. Download the latest version of media 7.x-2.x or 7.x-3.x

In that order.

If by downloading you mean using the admin to install/upgrade the module, the first step will not work because media-1.x is at that point still sitting there and it contains file_entity.

If by downloading you mean "don't use the admin interface, use wget or something similar", that might work. I didn't read it that way.

Michael-IDA’s picture

Thanks commonpike,

I see what you mean. Yes, Media 1.x needs to be disabled first, fixing that.

Michael-IDA’s picture

Issue summary: View changes
Michael-IDA’s picture

Mostly cleaned up formatting and step logic. Added Additional Config section as part of the step logic cleanup, but it will be needed anyway to incorporate the stub material.

Added reference to square thumbnails, as I hit that problem as well. Event though its suppose to be fixed, I’d leave it as reference. Personalty I’d add all other upgrade items from the issue queue as well, closed or active, so that this is a ‘single point of reference’ document. 1 minute for us documenters saves an hour for each person trying to track down their problem...

And I wish this didn’t add a comment for each and every edit. Spams the comments for fixing periods and such :(

Known problems probably needs better formatting, I just copied what was there

All for today...



Next person to edit this, please change "Upgrade by using drush" to "Upgrading with drush"

commonpike’s picture

@Micheal-IDA thanks for that. I'm not touching the text here, just more comments ..

  • In the 'Upgrading without drush', before step3 ('Download the latest version of file_entity 7.x-2.x') I *think* it is required to actually move the file_entity subfolder of the media module out of the drupal tree. Even if the media module is disabled, drupal will still recognize the file_entity module sitting there. It's totally hacky, but I remember having to do that.
  • After enabling the new media module, legacy file types were not recognized (eg, pdf and word documents are not listed as 'documents'). The new media module installs a separate module to fix that problem at /admin/structure/file-types/upgrade, and users should (1) go and enable permissions for (likely) the admin user to manage file types, (2) go back to the module listing and see a cogwheel appeared next to the 'media migrate file types' module, and (3) click that and migrate file types.
leolando.tan’s picture

Hi guys,

I have a site that I'm updating from 7.x-1.4. I tried to update straight to 7.x-2.6. So far there were no errors or warnings from Drush. The only issue I encountered was that I had CKEditor 7.x-1.16 and I tried to edit nodes so I just needed to update it also to 7.x-1.17.

Also I just noticed that in the Module page's Media description, the File Entity module is required.

With this result, does this mean the update is good and that I just need to install the File Entity module and not need the "update first to 7.1.6 then update to 7.2.6" process?

Thank you!

powysm’s picture

Just run the steps listed at top and went off ok.
However i had audio only browser setup and now these appear to have been switched to "allowed files image"?

Is this something that i can avoid on update or am i simply going to have to go through each widget settings correct to audio?


steinmb’s picture

@powysm - Pls. open e separate support issue.

BenWrighton’s picture

It has been covered in the checklists above but just to explicitly note this update changes the Media module permissions from:

  • Administer media
  • Import media files from the local filesystem
  • View media
  • Edit media


  • Administer media browser
  • Use the media browser

Which will be de-selected for all users AFAIK after the upgrade.