Document Upgrade Path from Media 1.x to Media 2.x/3.x

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

file_type
file_metadata

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?)

@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 - https://www.drupal.org/project/schema

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.

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.

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/media.types.inc)."

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.

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

Works.

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

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.

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 - https://www.drupal.org/node/250790

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).

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

If using drush...it 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

Thnx Alauddin. #10 worked for me perfectly.

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

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

Just added a documentation on the upgrade process: https://www.drupal.org/node/2481421

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.

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

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?

@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).

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.

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 https://www.drupal.org/node/2481421 . 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.

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.

See post #21 these look better after all.

Thanks,
Steve

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?

Thank you everyone for contributing to this documentation!

After following some older documentation (and failing), I started following instructions in https://www.drupal.org/node/2082037#comment-11205249.

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: https://www.drupal.org/node/2073317#comment-9422587

joseph.olstad,

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.

Thanks!

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').

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.

Perhaps we can start by replace/moving https://www.drupal.org/node/2481421 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 https://www.drupal.org/node/250790 - We should not duplicate a standard module upgrade.

@capysara 7.x-1.6 (https://www.drupal.org/project/media/releases/7.x-1.6) contains https://www.drupal.org/commitlog/commit/698/70a089ea3366122864b4aed1f3ae... that I think might cause some grief to old installation during upgrade.

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.

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.

@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.

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: https://www.drupal.org/node/2021439

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

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

https://screencast.com/t/vNrTfX2aRK
https://screencast.com/t/SbKLs5WH4

I cleared the cache. Any suggestions?

@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.

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!

@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?

@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?

• https://screencast.com/t/InHkkkbbzr
• https://screencast.com/t/pvyTAoyNoNUn

Any other suggestions on how to make this work?

@Stephen Ollman

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

@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.

Thanks

@joseph.olstad - Thanks for the follow up.

• I went to the link, and confirmed my settings were already set that way: https://screencast.com/t/en4y87UTbP0
• 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?

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.

@steinmb

Here's the page you mentioned, there are no thumbnails for any file at all: https://screencast.com/t/APTLZjBhoYJ

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: http://www.drupal.dev/admin/content/file/thumbnails?page=4
File does not exist: /pathto/sites/default/files/styles/square_thumbnail/public/statue_of_liberty_scroller2.jpg, referer: http://www.drupal.dev/admin/content/file/thumbnails?page=4
File does not exist: /pathto/sites/default/files/styles/square_thumbnail/public/statue_of_liberty_scroller.jpg, referer: http://www.drupal.dev/admin/content/file/thumbnails?page=4
File does not exist: /pathto/sites/default/files/styles/square_thumbnail/public/pipe of liberty_0.jpg, referer: http://www.drupal.dev/admin/content/file/thumbnails?page=4

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.

@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/

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?

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

@joseph.olstad

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:
https://www.drupal.org/project/registry_rebuild

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?

@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.

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.

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:

http://i65.tinypic.com/24g53ys.jpg (article edit page)
http://i64.tinypic.com/2rp9x91.jpg (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):

sites\default\files\article_images\old_file.jpg
sites\default\files\styles\medium\public\article_images\old_file.jpg
sites\default\files\styles\square_thumbnail\public\article_images\old_file.jpg
sites\default\files\styles\my_square_thumbnail\public\article_images\old_file.jpg

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

sites\default\files\article_images\new_file.jpg

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

http://i68.tinypic.com/2u41sau.jpg (list of image styles)

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

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

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

@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...

#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: https://www.drupal.org/node/2073317#comment-9565043
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

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

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

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 example.com/update to trigger the needed update tasks.

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

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.

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

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, https://www.drupal.org/node/2481421 , 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

<ol>
  <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>
</ol>

* replace codex with code

The instructions needed one last tweak.

Works for me.

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

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

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.

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

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.

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
https://www.drupal.org/node/2481421

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?

Best,
Michael

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>
</div></a></p><p style="margin-bottom: 0in; line-height: 100%">Links/Notes

@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.

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

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.

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 , 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.

Best,
Michael

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.

@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.

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
https://www.drupal.org/node/2281631
https://www.drupal.org/node/2283057
Path: /admin/people/permissions

- Fix thumbnails (Preview) are no longer generated.
https://www.drupal.org/node/2486599
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 "http://download.cksource.com/CKEditor/CKEditor/CKEditor%204.6.2/ckeditor_4.6.2_full.zip"
unzip ckeditor_4.6.2_full.zip
rm ckeditor_4.6.2_full.zip

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

"CKEditor (Expected version: 4.6.1.580bcaf but found 4.6.2.20af917.)"

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.

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.

Stein,

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.

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.

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?

It is here, and makes no sense at all. https://www.drupal.org/node/2835705

Here is the discussion, it makes no sense to me.
https://www.drupal.org/node/2835705/discuss

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/form.inc on line 1520”

Future resolution will be added to this documentation as appropriate.

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

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.

@Michael, please follow up in #2884164: theme no longer behaves since upgrading from media <=2.0-alpha3

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

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 findermodule , 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.

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.

@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.

Thanks commonpike,

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

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...

Edit:

Argh!!!

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

@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.

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!

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?

Thanks
Mathew

@powysm - Pls. open e separate support issue.

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

to

• Administer media browser
• Use the media browser

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

#11 worked for me -- thanks for the details

To add to @Michael-IDA's checklist in #98:

Besides the square_thumbnail issue that's been documented extensively elsewhere #2486599: missing square_thumbnail causes Broken images in media browser and file/thumbnail, I found after upgrading from 7.x-1.6 to 7.x-2.19 that the node view for image files (e.g. `/file/[filename]`) was missing the full size image.

Turned out that on default display for "image" file-type - /admin/structure/file-types/manage/image/display - everything was hidden except the caption; the file field needed to be dragged back into place. (Fixed immediately but suggestions of cause welcome.)

hi @wturrell, I was pretty sure that the square thumbnail thing should have been fixed, but may be a regression there was a fairly recent change to the media_wysiwyg.install file, if you do a git log on media_wysiwyg.install you'll see the most recent changes at the top.

If you cloned media and checked out the previous commit on media_wysiwyg.install , after having restored your media 1.x database and re-running the upgrade

see what that does?
pretty sure that square thumbnail issue was resolved but it's tough to say because people report issues, but they could have been caused by untagged releases or alpha releases of 1.x or somewhere between. There,s been a lot of people having upgraded to 2.x, most of the issues are worked out, the procedure is pretty good, but if we can make it better, there's still 40000 or more that haven't yet upgraded to 2.x

@joseph.olstad - Hi, yep don't worry too much about square_thumbnail as it was trivial to fix myself (not sure if I'll have much spare time soon, but if I do I'll try rolling it back again). Mainly wanted to mention the file-type thing as I hadn't seen anyone else with that problem.

I hate to be the hater here, but (what should be a simple update) creates insanity via the Drupal way. Issues like this are commonplace across many modules. Drupal is going to have a tough time hanging on to a wider audience because of these unnecessary, site-breaking headaches. Common users must spend hours researching solutions to a module update. Yikes.

@Drew Oslo, with all due respect, a lot of perseverance and collaboration has went into making the upgrade path from 1.x to 2.x relatively painless. There's over 50000 people since I became maintainer that have upgraded from 1.x to 2.x. There's also a fairly straight forward quick install guide for 2.x fresh installs that works quite well.

When you see one or two reported issues, there's probably thousands that followed the upgrade instructions had no issues.
I've personally responded to thousands of issues in this queue since 2016 and I can assure you with confidence that if you follow the instructions in this issue description summary you will have great success in your media 1.x to 2.x upgrades 99 times out of 100.

Kaare from the university of Oslo has done significant work on the 4.x branch and there is a very easy upgrade path to 4.x from 2.x. We're not yet recommending 4.x for the masses, however it has a much improved tokenizer , has various subtle improvements and has a batch upgrader for upgrading 2.x tokens to 4.x wysiwyg embedded tokens.

Eventually we hope to one day be able to recommend 4.x, however until then stick with 2.19.

If you want an easy way to try out the media module you can download the latest media_dev distribution 2.x/3.x or 4.x and try it out.

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