A simple quick drupal 8.4 installed from drush, with the media_entity_image module and a single media bundle "image" with two fields "caption" and "image file" fails to upgrade to core media after upgrading to the media_entity 2.x branch. The "Revisionability" of the media bundle seems not to have an impact on whether the upgrade fails (it always fails).
drush updb
The following updates are pending:
media_entity module :
8200 - Clears the module handler's hook implementation cache.
8201 - Replace Media Entity with Media.
Do you wish to run all pending updates? (y/n): y
Performing media_entity_update_8200 [ok]
SQLSTATE[HY000]: General error: 1 no such column: revision_uid: CREATE INDEX [error]
main.media_revision_0_media_field__revision_uid__target_id ON
media_revision_0 (revision_uid); Array
(
)
Performing media_entity_update_8201 [ok]
Failed: SQLSTATE[HY000]: General error: 1 no such column: revision_uid: [error]
CREATE INDEX main.media_revision_0_media_field__revision_uid__target_id ON
media_revision_0 (revision_uid); Array
(
)
Cache rebuild complete.
afterwards adding media seems to be broken media/add/image
and running the updb again falls into the case trying to catch other weird contrib modules called "media" -- likely confused by core's media being active now...
$ drush updb
In order to run the Media Entity 2.x upgrade, please uninstall and remove from the codebase the contributed "Media" module.
Comments
Comment #2
yareckon commentedComment #3
marcoscanoComment #4
yareckon commentedComment #5
phenaproximaDoes this patch help?
Comment #6
phenaproximaBumping this to Critical priority, because it is an update path bug.
Comment #7
yareckon commentedHi @phenaproxima, thank you for your work on this and your amazingly quick response. Unfortunately I have to report the identical error is still occuring after patching the 2.x branch before drush updb. Hopefully that is what should be patched.
This is after:
The error is identical. Could it be that I should run things in a different order, or is your patch against media_entity 1.x?
Comment #8
phenaproximaIf it didn’t work for you, it behooves me to figure out what went wrong, and fix it. Thanks for testing, @yareckon!
Comment #9
yareckon commentedOne additional data point: I am starting my test site on drupal 8.4, not upgrading an actual 8.3 site, in case that makes any difference at all.
Comment #10
phenaproximaI have been unable to reproduce this locally. Here's what I did:
Under these circumstances, the update ran without flaw. Is there anything about these steps, apart from the lack of a caption field (which, to be honest, I can't imagine breaking the update path) that don't square with yours?
Comment #11
yareckon commentedHi @phenaproxima, I share your skepticism that the caption field plays a role.
I will try to reproduce using your recipe. The most obvious difference has been that I had used drush qd, which is sqlite.
Maybe this is the head slapping moment, but I didn't have media_entity_generic installed unless that gets pulled in automatically via a composer update to the 2.x branch.
Comment #12
kylebrowning commentedI am also experiencing this error.
Trying to update to 8.4.2 from 8.4.0.
media_entity moduleUpdate #8201
Failed: Drupal\Core\Database\SchemaObjectDoesNotExistException: Cannot change the definition of field media_revision.revision_uid: field doesn't exist. in Drupal\Core\Database\Driver\mysql\Schema->changeField() (line 577 of /var/www/docroot/core/lib/Drupal/Core/Database/Driver/mysql/Schema.php
This may have something to do with lightning but im guessing not.
Comment #13
berdirI'm also seeing this, thought it was because I'm not switching from media_entity to media as part of the 8.4.x update, but not sure anymore now as you do seem to have tested exactly that. You did however install media_entity on a site that was *installed* as 8.4.0 if I understand correctly.
Can you try installing 8.3.7, install media_entity 1.x, then updating to 8.4, then switch to media? I'll continue testing as well, but it's late sunday night :)
Comment #14
cman9090 commented+1 seeing same issue, website dead.
Comment #15
marcoscano@kylebrowning, @cman9090,
could you please share more details of your installations, or ideally steps to reproduce the error?
I have myself also tried to reproduce this without luck, in my case using Drupal 8.5.x-dev, installing ME 1.x, then upgrading to ME 2.x, and everything works as expected in this case...
(Note: while testing please also make sure you use the latest Mecia Entity 8.x-2.x-dev version, because it is in active development and some recent fixes were included)
Comment #16
cman9090 commented8.3.7 upgrade to 8.4.2. Had Media 1.x installed, did everything it said in instructions to upgrade. Got the error on this bug.
Comment #17
marcoscanoOK so I could finally test this also with the core upgrade as well (sorry for being skeptical before...)
Steps I performed:
- Drupal 8.3.7 + Media Entity 8.x-1.6 + Media Entity Image 8.x-1.2
- Image bundle (called
image), with an image source field calledfield_image- Created media items of this type
- Upgraded core to 8.4.2, ran core DB updates with
drush updb- Upgraded to Media Entity 2.x HEAD (and added the additional required modules to the codebase)
- Ran
drush cr,drush mecuand thendrush updbNo errors still... :(
@cman9090,
Anything I'm doing differently from you when you have the issue?
Thanks!
Comment #18
eric.guerin@ucsf.edu commentedI am also experiencing this issue, any guidelines on how to fix would be appreciated. The patch was already included in my codebase, however still getting the following errors.
After this no updatedb is completed. I am on Drupal version 8.4.4 here or at least trying to be.
Comment #19
eric.guerin@ucsf.edu commentedI have added a patch that seems to work for me, it seems like the table column names were already changed through some other process, so this is just a way to double check that those columns aren't there or ignore them if they are.
Calling this the 2918172-6-8.4.4.patch. Since it probably only applies to later version of Drupal 8.4. FYI this patch does not contain the original patch code, you would want to run both if necessary.
Comment #20
btully commentedThanks for the patch @gr8tkicks. It worked somewhat, in that I'm no longer seeing the dreaded
However, now I am seeing the following error:
Does this mean one needs to manually go into the DB config table and delete the `media.type.image` row?
When comparing values for media.type.image and media_entity_bundle.image it looks as though they differ significantly:
media.type.image
VS.
media_entity_bundle.image
Note that media.type.image uses a source_field of "field_media_image" whereas media_entity_bundle.image uses a source_field of "image" (in addition to other differences). So not sure how to get by this one. Any ideas?
Is Media Entity just not compatible with D8.44+ ?
Comment #21
btully commentedconfirmed that patch from #19 works once you delete the media.type.image row from the config table (if it already exists) if you see the Integrity constraint violation: 1062 Duplicate entry 'media.type.image' for key 'PRIMARY':... error.
Comment #22
g_miric commentedI'm also getting the "[error] SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry 'media.type.image'... " when I try to exexcute updates.
Comment #23
Ralf Eisler commentedI have the same error updating from 8.4.0 / 2.2.0 to 8.4.5 / 2.2.1 or 2.2.2 or 2.2.3.
The above patches ar already applied to my codebase or refused (2918172-6-8.4.4.patch).
Comment #24
benstallings commentedI am having this error when attempting the upgrade in Drupal 8.5.1. I haven't attempted the patches yet; just updating this thread to say that 8.5.1 is among the Drupal versions affected.
Comment #25
jasonlttl commentedI don't know exactly what is going on here, but this may help.
In my dev drupal instance, which uses sqlite, this statement fails because there is an index that refers to the column revision_uid and the sqlite driver is not smart enough to update it.
When the driver renames a field like this, it essentially recreates the table with the 0 prefix (and any existing indexes) and copies all the data then swaps out the tables. Perhaps other drivers are smarter?
So for example, if I drop the index before and recreate it after, it appears to work fine through that part.
Note, I haven't fully tested this all the way through as much later in the update I'm getting another sqlite error involving number of arguments and the cache (a pretty common sqlite problem).
Comment #26
benstallings commentedThank you for the tip, jasonlttl -- the problem turned out to be SQLite on my local as well. When I tried another local install of the same site using MySQL, the update completed without error.
Comment #27
Ralf Eisler commented@jasonlttl
Thank you for the tip, but my installations dont run on SQLite.
I am trying to got through the update-process to Lightning 3.1.0.1 several times now.
I found out, that following the procedure with Lightning strict was very helpful.
Despite of following update procedures, I have a persistent problem updating version >= 2.2.1.
I also found out, that 2918172-6-8.4.4.patch indeed works updating to core 8.4.2/Lightning 8.x-2.24, for solving the
General error: 1 no such column: revision_uidproblem.It however reveals an other problem with Media entity audio, which the update tries to transfer to Media, which of course does not work, because it does not exist in core.
As a result,
drush updatedbfails:Or with /update.php:
I’m not sure, if this is related to to this patch, or if this problem should be addressed in an other issue, which is related to Media entity audio.
Comment #28
Ralf Eisler commentedFound the solution:
composer require 'drupal/media_entity_audio:^2.0'Comment #29
ruslan piskarovThe same was for me when I was tried to update from D5.4 to D8.5 TOGETHER with media_entity v8.2.
Updates from media_entity was applied before updating system (drupal core) and as the result the same issue.
However when I tried to update as described there https://www.drupal.org/docs/8/core/modules/media/faq-transition-from-med..., works well without any patch.
Good steps:
Make backup.
Update Drupal core from D5.4 to D8.5 with media_entity v8.1.
Make backup.
Update media_entity v8.1 to media_entity v8.2.
I hope it can help.
Comment #30
hansfn commentedThe patch in comment 19 fixed the issue for me so I could run update 8201 (when upgrading to Drupal 8.6.1).
Comment #31
keopxNot works
Comment #32
chr.fritschIs this still a valid issue when you are already on D8.6+?
Older versions of Drupal are not supported, so we could close this issue.
Comment #33
chr.fritschComment #34
karenann commentedRecent updates to this module have updated the .install file in such a way that the patch in #19 no longer applies.
Here is the applicable commit https://git.drupalcode.org/project/media_entity/commit/cc4374d06afc820c6...
I can't speak to whether or not the underlying issue in this ticket is still an issue.
Comment #35
bbuchert commentedBumping into the same issue updating Thunder following these instructions: https://thunder.github.io/thunder-documentation/update-2-to-3
Thunder Version
2.49 (Drupal 8.7.7)
Comment #36
bbuchert commentedComment #37
bbuchert commentedI haven't gotten the time this is the composer.json I'm using.
Comment #38
netgeek123 commentedThis has not been fixed yet.
Comment #39
chr.fritschI am still not able to reproduce this issue. So if someone can provide exact steps to reproduce, I would like to work on it.
Comment #40
netgeek123 commentedFollowed these steps when updating Thunder.
https://thunder.github.io/thunder-documentation/update-2-to-3
Media entity 2x is installed;
I ran update from update.php;
SQLDump of the media_revision table;
There is no revision_uid it is revision_user. That is the problem.
Comment #41
chr.fritschWhich versions of Thunder and Drupal are installed before the update?
Comment #42
sershevchykI used Drupal 8.7.6 and Media Entity 8.x-2.0-beta5 and have the same problem when try to run update scripts
In logs, when I try to open node with media entity I see next error
Drupal\Core\Database\DatabaseExceptionWrapper: SQLSTATE[42S22]: Column not found: 1054 Unknown column 'revision.revision_user' in 'field list': SELECT revision.vid AS vid, revision.langcode AS langcode, revision.revision_user AS revision_user, revision.revision_created AS revision_created, revision.revision_log_message AS revision_log_message, revision.revision_default AS revision_default, base.mid AS mid, base.bundle AS bundle, base.uuid AS uuid, CASE base.vid WHEN revision.vid THEN 1 ELSE 0 END AS isDefaultRevision FROM {media} base INNER JOIN {media_revision} revision ON revision.vid = base.vid WHERE base.mid IN (:db_condition_placeholder_0, :db_condition_placeholder_1); Array ( [:db_condition_placeholder_0] => 20 [:db_condition_placeholder_1] => 21 ) in Drupal\Core\Entity\Sql\SqlContentEntityStorage->getFromStorage() (line 444 of /var/www/html/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php).Comment #43
netgeek123 commentedI was updating to Thunder 3
Media Entity was version 1.2.8 upgrading to 2. The field is named incorrectly. I am not sure when the field name was changed or why.
Comment #44
netgeek123 commentedI fixed the misnamed field revision_uid... Now it barfs this error.
I am not sure why it is looking for fields that do not exist.
Comment #45
netgeek123 commentedOk, I got it to work. I had to manually revert the name of these fields and rerun the update.
The fields were changed previous to running the update at some point. Anyhow, this fixed the problem. Perhaps some if() statements in the code to work around this problem?
Comment #46
robert_t_taylor commentedSo, following the suggestion in #45 (Thanks @netgeek123!) I wrapped that $field_renames assignment, as well as the subsequent foreach in a try/catch in /modules/contrib/media_entity/media_entity.install:
This allowed me to get past the error, and I can repeat this as needed against production database dumps without the need to revert the field names.
Comment #47
rumenxI created a patch based on the solution in the previous comment. It worked for me.
Comment #48
karimbou commentedTried the upgrade media_entity path coming from 8.4 to 8.5 (media_entity 2.x needed drupal core 8.6) so I upgraded to 8.6, downloaded media_entity_generic, updated all modules (media_entity_image) removed a custom image module, then ran 8.6 drush updb and i get this :
I'm starting to not know what to do should i retry this in 8.4.8 with media_entity 2.x ? Why this documentation https://www.drupal.org/docs/8/core/modules/media/faq-transition-from-med... talks about Drupal 8.5x when you actually need 8.6.x ? When you then go to 8.6.x should you revert the codebase of media_entity 2.x and actually run drush updb for core first maybe ?
Comment #49
anybodyWe've been using the patch in #47 several times now to be able to switch to Media in Core through media_entity 2.0.
Comment #50
anybodySetting needs review as of #47 and #49
Comment #51
benstallings commented