Problem/Motivation
If a site has rows in the menu_link_content
table with no equivalents in menu_link_content_data
, then menu_link_content_post_update_make_menu_link_content_revisionable()
will fail with an error like:
Failed: Drupal\Core\Entity\EntityStorageException: The entity update process [error]
failed while processing the entity type menu_link_content, ID: 3. in
Drupal\Core\Entity\Sql\SqlContentEntityStorageSchema->copyData() (line
216 of
D:\FILES\REPOS\detroitmi-test\docroot\core\lib\Drupal\Core\Entity\Sql\SqlFieldableEntityTypeListenerTrait.php).
Reports of this case:
Proposed resolution
Add a hook_requirements() that runs a query to see if this condition exists, and if so returns an error, pointing to a change record with instructions on how to fix/delete the data.
A similar hook_requirements() was added in #3052147: comment_update_8701 fails if there are comments without field_name.
Remaining tasks
User interface changes
API changes
Data model changes
Release notes snippet
If you were unable to update to 8.7 due to issues with menu link or taxonomy term data, Drupal 8.8.4 now adds instructions for resolving this issue. Try installing 8.8.4 and running update.php again. If you see an error that there are "Integrity issues detected" for your site data, follow the instructions in the change record to attempt to repair the data so that updates can be run.
Comment | File | Size | Author |
---|---|---|---|
#160 | 3052318-160.patch | 7.1 KB | andypost |
#166 | 3052318-166.patch | 7.2 KB | jungle |
#175 | 3052318-8.x.patch | 7.17 KB | catch |
#181 | reroll_diff_175-180.txt | 4.07 KB | AndyF |
#181 | 3052318-180.8.7.patch | 7.07 KB | AndyF |
Comments
Comment #2
cilefen CreditAttribution: cilefen as a volunteer commentedComment #3
xjmSetting critical until proven otherwise for update path bugs. :)
@jedgar1mx, can you provide some more information? A backtrace, specific errors in the logs or shell output, installed modules, etc.? Thanks in advance!
Comment #4
alexpottLooks likely to occurring during
menu_link_content_post_update_make_menu_link_content_revisionable()
Comment #5
jedgar1mx CreditAttribution: jedgar1mx commentedNot much on the logs other than what I originally posted
Comment #6
jedgar1mx CreditAttribution: jedgar1mx commentedIt seems there was some issues with
menu_link_content
table. Row with id 3 had no pair inmenu_link_content_data
. Once I deleted the row, the database update works. I will run some test and post my findings 😁Comment #7
amateescu CreditAttribution: amateescu commentedThat sounds really weird, I'm curios to see if you manage to figure out how that happened.
Comment #8
vuilI have the same issue somewhere in menu_link_content.post_update with the following error:
And, after execute:
I need to find where in menu_link_content.post_update is the problem...
Comment #9
vuilI found a similar issue https://www.drupal.org/project/drupal/issues/3052204 but for file_entity.
Comment #10
vuilComment #11
mixerowsky CreditAttribution: mixerowsky at Codexsto commentedI have same issue on
drush updb
. I'm getting:Comment #12
amateescu CreditAttribution: amateescu commented@mixerowsky, your problem seems to come from the Menu Item Extras contrib module. Is it currently installed on the site or was it installed at some point and then uninstalled?
Comment #13
azovsky CreditAttribution: azovsky commentedHave the similar issue on `drush updb`:
Comment #14
amateescu CreditAttribution: amateescu commented@azovsky, can you post the full backtrace for that error?
Comment #15
azovsky CreditAttribution: azovsky commentedSure, here is:
Comment #16
amateescu CreditAttribution: amateescu for Pfizer, Inc. commented@azovsky, thanks, that was very helpful. Your error does not come from the menu_link_content update path, but from Layout Builder. Opened a separate issue for it: #3052431: layout_builder_post_update_make_layout_untranslatable() still attempts to query all revisions for non-revisionable entities
Comment #17
vuilComment #18
jedgar1mx CreditAttribution: jedgar1mx commentedI did see #3039586, but the suggestion was to delete all the data that was there already
Seems like a multiple try error, I did multiple database imports but still was getting this error.
Comment #19
waverate CreditAttribution: waverate commentedComment #20
rshafakian CreditAttribution: rshafakian commentedI'm getting a similar error: Ran composer update for core and then on updatedb i get the following:
I then have old_menu_link tables, but no tmp tables. If i run updatedb again then i get the tmp tables and i get the error
Cannot rename tmp_57da5fmenu_link_content_revision to menu_link_content_revision: table menu_link_content_revision already exists.
Comment #21
waverate CreditAttribution: waverate commented@rshafakian. The table menu_link_content_revision already exists error comes from re-running updb a second time.
I would recommend either deleting the tmp_/old_ tables or restoring your db from backup and trying again to troubleshoot the root cause.
It looks like it is in:
Comment #22
rshafakian CreditAttribution: rshafakian commented@waverate Yeah that comes from running it a second time. I've tried deleting the old/tmp tables (in all combinations, once just old, once just tmp, once both) and I still get errors. I've even tried emptying the tables to no avail. Any other suggestions?
Comment #23
amateescu CreditAttribution: amateescu for Pfizer, Inc. commented@rshafakian, you need to find the backtrace of the error that you posted in the other issue:
That's the real problem that needs to be fixed in order to be able to run the updates properly.
Comment #24
Matombo CreditAttribution: Matombo commentedI have the same issue,
i already tried deleting every entry in menu_link_content and menu_link_content_data as well as all colums exept the primary ones
still get the same error
Comment #25
amateescu CreditAttribution: amateescu for Pfizer, Inc. commented@Matombo, that means the problem is most likely not caused by the conversion of
menu_link_content
entities to revisionable, but by some other code which reacts to an entity type update. Can you post the full output of the first time you ran the update?Comment #26
amateescu CreditAttribution: amateescu for Pfizer, Inc. commented@rshafakian, can you put this code in
\Drupal\Core\Database\Connection
on line 735, before the exception is thrown?print_r(\Drupal\Core\Utility\Error::formatBacktrace(debug_backtrace()));
And paste the resulting backtrace here so we can try to figure out what's going on.
Comment #27
crifi CreditAttribution: crifi as a volunteer commentedI also have this issue in two of my twenty multisite installations. The first PHP error is the following:
The update procedure is for make_menu_link_content_revisionable.
Comment #28
amateescu CreditAttribution: amateescu for Pfizer, Inc. commented@crifi, can you try the debugging steps from #26 and post the backtrace for that error?
Comment #29
crifi CreditAttribution: crifi as a volunteer commentedHere is the backtrace as suggested by @amateescu:
Comment #30
waverate CreditAttribution: waverate commented@crifi, @matombo, @i.vochkof and @rshafakian:
As noticed in #44 here #3039586: Cannot rename tmp_2362aemenu_link_content_revision to menu_link_content_revision, is your site in a non-English language without English enabled?
It seems that could be behind the
Placeholders must have a trailing [] if they are to be expanded with an array of values.
errors.Comment #31
sallakane CreditAttribution: sallakane at NeoLynk for Carrefour commentedHi all,
I have the same problem, I deleted all tables tmp / old it did not change anything. I got backups of the menu_link_content tables and menu_link_content_revision still have the same problem. Other ideas to get us out of there?
Comment #32
Matombo CreditAttribution: Matombo commented@waverate
The workaround from that thread worked like a charm, thanks for pointing it out.
To repeat the solution in this thread:
1. If you had a previous failed update attempt and did not backup your database to roll back to: Delete the menu_link_content_revision and menu_link_content_field_revision tables and the corresponding tmp... and old... tables from your database.
2. Add english as a language to your site and make it the default language.
3. Run the database update
4. Change back the language settings
Comment #33
plach@crifi:
Could you post the export of your
views.view.watchdog
and the list of installed modules? Also, could you specify whether the site is monolingual or multilingual? Isde
the main language or a secondary language?Comment #34
plachComment #35
crifi CreditAttribution: crifi as a volunteer commentedSee the attachments for the needed informations.
Comment #36
crifi CreditAttribution: crifi as a volunteer commentedThe language de is the primary language. There is no secondary one.
Comment #37
crifi CreditAttribution: crifi as a volunteer commentedCould this related to #2998103: dblog_update_8600() breaks views.view.watchdog config entity, leading to PHP warning on admin/reports/dblog and configuration import errors and the view was already corrupt since a while?
Comment #38
crifi CreditAttribution: crifi as a volunteer commentedSorry. In #35 I uploaded the files already in 8.7.0 after using the workaround of #32. So here are the files in the state of 8.6.15
Comment #39
plach@crifi:
Thanks for the additional info! I was finally able to reproduce the
Placeholders must have a trailing [] if they are to be expanded with an array of values.
error, although while importing the config rather than during the update. However this shouldn't be relevant because in both cases we would be saving that config, so fixing the issue in the former case will work also in the latter. I think you're correct and the failed update is actually a combination of #2998103: dblog_update_8600() breaks views.view.watchdog config entity, leading to PHP warning on admin/reports/dblog and configuration import errors and #3052492: ViewsEntitySchemaSubscriber should not make an entity update fail if a view cannot be resaved. The patch posted in the latter issue should allow you to complete your upgrade successfully.Tomorrow I will dig deeper into the error, but I suspect that this will turn out to be a "duplicate" of the two issues mentioned above.
Comment #40
VladimirAusHere's what I get when running
./vendor/bin/drush -l site1 -y updatedb --debug
Comment #41
VladimirAus@plach applying patch and cleaning up the views as per 2 issues you mentioned didn't help.
In addition
getOutputAsJson()
inProcessBase
getsComment #42
cilefen CreditAttribution: cilefen as a volunteer commented@VladimirAus Does the class that is missing in the exception not exist? This seems like a separate issue.
Comment #43
plach@VladimirAus:
That indeed seems another issue wrt what we were troubleshooting here, can you check whether the
menu_item_extras
module is enabled and exists in the file system?Comment #44
VladimirAus@plach @cilefen - module is not enabled on my site.
Comment #45
VladimirAusProbably related
menu_item_extras
issue: https://www.drupal.org/project/menu_item_extras/issues/3052746Comment #46
VladimirAusComment #47
VladimirAusSeems like
MenuItemExtrasMenuLinkContent
definition is invalue
column ofkey_value
tableComment #48
mixerowsky CreditAttribution: mixerowsky at Codexsto commented@amateescu currently it's not installed, not even files of it (not in composer). It was installed for some reason but removed right after.
Comment #49
sklompar CreditAttribution: sklompar commentedI'm having the same issue. Menu Item Extras was installed and removed. Getting the same error when trying to update the database after upgrading to 8.7.0.
Comment #50
rshafakian CreditAttribution: rshafakian commented@waverate thanks for the help! your help in comment #30 did the trick! I made english the default language and then ran the update and everything worked as it should!
Comment #51
Suvikki CreditAttribution: Suvikki as a volunteer commentedThe workaround in #32 worked for me too, but I restored the old database from backup after deleting menu_link_content_revision and menu_link_content_field_revision tables and the corresponding tmp tables.
Comment #52
oukjweather CreditAttribution: oukjweather commentedI'm also having issues with the update to Drupal 8.7.0 from Drupal 8.6.15. My update runs alright, but I'm experiencing other issues:
So as best as I can tell that works out ok. Not seeing any errors from it. However, when I load a page, I get an error:
So inspected the twig template and found that when I commented out: {{ page.navigation_collapsible }}, I can get the page to render. So I go to the admin and try to look at the menu configuration and get this:
So I think there must be some sort of error with what is in the database and what the code is expecting. Something that is not migrating well perhaps?
Comment #53
sklompar CreditAttribution: sklompar commented@mixerowsky, a workaround for your issue is here: https://www.drupal.org/project/menu_item_extras/issues/3052746#comment-1...
Comment #54
marcus0263 CreditAttribution: marcus0263 commentedOK I'm also running into the issue when upgrading from v8.6.15 > v8.7.0 with it blowing up with this error -
I've run the patch no luv ..
My site is also default English, I don't have multilingual core module installed
Comment #55
flocondetoileAlso running in this issue when upgrading 8.6.15 > 8.7.0 on a french only site.
The error
Placeholders must have a trailing [] if they are to be expanded with an array of values.
broke the update and then can not anymore apply pending updates.Applying the patch #13 from #3052492: ViewsEntitySchemaSubscriber should not make an entity update fail if a view cannot be resaved solved the issue.
Edit: Of course I have to start from a clean DB (drop everything and reimport a clean DB) on the dev environment, apply the patch and then run the updates.
Comment #56
Mars0test CreditAttribution: Mars0test at Niji commentedHi
Comment #55 work for me.
Thanks @flocondetoile
Comment #57
John_B CreditAttribution: John_B commentedMaybe that is worth putting that in bold to save others time, since it another of many D8 gotchas whose cost my non-profit client cannot afford and I must absorb. Rolling back code and re-importing a db which previously worked is not sufficient to repair the site, unless all tables have been dropped first.
Comment #58
ifrikI get the same issue on a site installed in German, with English as a second language.
Admin toolbar module and Admin toolbar extra tools module was installed initially, but has been uninstalled. There are no custom menu items anymore.
Uninstalling the Menu Content link module worked, but then a similar error happens with making the taxonomy terms revisionable #3052464: Cannot update to 8.7.0 because of taxonomy_post_update_make_taxonomy_term_revisionable.
Comment #59
jenger1965 CreditAttribution: jenger1965 commentedGot the same error with D8.7.1.
Here the watchdog output:
Comment #60
calbasiI run in this issue and fix from #32 does the trick.
My site is part of a multisite. And I have found this error only in the default site (it has Spanish as the only language). But one of the other 2 sites has Spanish as the only language, and don't run into this issue.
Comment #61
aerozeppelin CreditAttribution: aerozeppelin commented@Matombo, thank you for the listing the steps in #32, it fixed the issue on my end.
Comment #62
Tritof CreditAttribution: Tritof commentedI have the same error on 2 sites. It may be the dumbest observation of all time, but I noticed that the 7 db updates not working are the ones without numeric ids. The 5 other updates stating with a numeric ids are passing through the update process:
system module
file module
node module
taxonomy module
menu_link_content module
views module
Comment #63
tzsl CreditAttribution: tzsl as a volunteer commentedI have the same problem with 1 of my 4 sites. It.s the site I have updated from D7 to D8. The other sites are build in D8.
menu_link_content-module
make_menu_link_content_revisionable bijwerken
Mislukt: InvalidArgumentException: Placeholders must have a trailing [] if they are to be expanded with an array of values. in Drupal\Core\Database\Connection->expandArguments() (regel 735 van /var/www/html/mv8/core/lib/Drupal/Core/Database/Connection.php).
13-5-2019 patch 3052492-13.patch solved the problem for me.
Comment #64
ru.bsv CreditAttribution: ru.bsv commentedHello!
Comment #55 work for me.
Thanks a lot @flocondetoile
Comment #65
alfonsotem CreditAttribution: alfonsotem as a volunteer commentedHello!
I have same issue on drush updb.My error is "[error] Update aborted by:
menu_link_content_post_update_make_menu_link_content_revisionable"
I tried to change default language but don't work.
i tried to delete the tmp_/old_ tables but I have the same issue.
thanks to everyone!
Comment #66
idanse CreditAttribution: idanse commentedMay be interesting for others too. For me the solution was:
uninstalling Database Logging, as suggested in #31 of
https://www.drupal.org/project/drupal/issues/3052542
Comment #67
flocondetoile@idanse Yes because the view dblog generate an error during the update process. But it can have some others views with similar errors on a project. The best is then to apply the patch from #3052492: ViewsEntitySchemaSubscriber should not make an entity update fail if a view cannot be resaved or wait for 8.7.2
Comment #68
saganakat CreditAttribution: saganakat commentedHello!
I have the same issue, when I tried update 8.6.15 to 8.7.1. I execute updatedb and my error is "[error] Update aborted by:
menu_link_content_post_update_make_menu_link_content_revisionable the table already exists"
I tried drop the tables and I have the same error.
I tried to change default lenguage and don't work for me.
Thanks to everyone.
Comment #69
alfonsotem CreditAttribution: alfonsotem as a volunteer commentedHello!
Applying the patch https://www.drupal.org/project/drupal/issues/3052492 work for me.
Comment #70
saganakat CreditAttribution: saganakat commentedThanks! The comment #69, the patch work for me
Comment #71
slashrsm CreditAttribution: slashrsm at Tag1 Consulting commentedPatch mentioned in #70 fixed the issue for me as well.
Comment #72
vinyl_roadsSame problem, can't rename table, table exists (it seems to be the same issue here)
I've restored a back up, deleted manually the tables but still have issue.
Finally, thanks to this answer, I've installed English language and set it as defaults language (the website was in French). I've successfully updated DB with Drush and then delete English and restore French as default language.
Comment #73
renderfreak CreditAttribution: renderfreak commentedIf this can help anyone... Comment #6 here worked like a charm for me... I had to rollback my database to 8.6.15... But once i ran the update... No errors!!
Comment #74
VladimirAusIf you are getting
> [error] Error: Class 'Drupal\menu_item_extras\Entity\MenuItemExtrasMenuLinkContent' not found in Drupal\Core\Entity\Sql\SqlContentEntityStorage->mapFromStorageRecords()
I had to delete all menu items and then run
drush updb
to fix it.Comment #75
SivaRam89 CreditAttribution: SivaRam89 commentedI was trying to update from 8.6.16 > 8.7.1. The patch at https://www.drupal.org/project/drupal/issues/3052492 did not work for me unfortunately, may be because I am using php 7.2. I had to manually drop the following tables and its corresponding temp ones to run the database update completely.
menu_link_content_revision
menu_link_content_field_revision
taxonomy_term_revision__parent
taxonomy_term_revision
taxonomy_term_field_revision
taxonomy_term_revision__field_order
The temp tables will look something like "tmp_8458d9menu_link_content_revision".
Note: These tables are not present in 8.6.* versions. So, for this approach to work, you have to wait until it fails during the DB update and drop the corresponding table and its temp ones. For example, when the update fails with an error regarding 'menu_link_*' tables, drop both the above mentioned menu_link tables and its temp ones and try running the update. Then, if it fails later in the 'taxonomy_term_*' tables, drop all the above mentioned taxonomy_term tables and its temp ones and run the update again.
Use this approach only if #55 does not work. I am still testing the application and looks good so far. Will update if I run into any issues because of this workaround.
Comment #76
davo20019 CreditAttribution: davo20019 commentedI got the same problem because the VBO contrib module is in my repo and it needed to be updated before running the drush updb -y command (update.php). Steps to fix:
composer require 'drupal/views_bulk_operations:2.x-dev'
If you don't use composer in your project, you can update the module manually.
drush sql-query "DROP TABLE menu_link_content_revision"
drush sql-query "DROP TABLE menu_link_content_field_revision"
After the steps above I was able to run:
drush updb -y
Comment #77
baltazarz3 CreditAttribution: baltazarz3 commentedI faced same issues, the only way I could make this to work is similar procedure as posted on #75.
- run db update
- delete the tpm table that just failed ( ex: tmp_dca0aftaxonomy_term_field_revision )
- delete the main table ( ex: taxonomy_term_field_revision )
- delete the previous main table that failed ( ex: taxonomy_term_revision )
- run db update again to check next failure
The latest release 8.7.2 didn't help here because the problem comes from v 8.7.0 (I was upgrading from 8.6.x).
About "drush entup" being deprectaed, I used the devel_entity_updates module that helped me with pending entities updates.
Comment #78
marcus0263 CreditAttribution: marcus0263 commentedI was banging my head with this, here's what worked for me finally following this solution from another thread
https://www.drupal.org/project/drupal/issues/3052542#comment-13112594
I finally was able to upgrade 8.6.16 > 8.7.2
Comment #79
FirstSanny CreditAttribution: FirstSanny commentedIf your database is located in a different scheme, than 'website', then maybe you should read my comment here.
With this you probably can run the update successfully, but most of the tables are going in the wrong scheme. So i wouldn't recommend to update now.
Comment #80
vuilThat works for us (Drupal core 8.6.16 update to 8.7.2, main language DE + second EN):
drush sql-query "DROP TABLE menu_link_content_revision"
drush sql-query "DROP TABLE menu_link_content_field_revision"
drush updb -y
Thanks @davo20019 (#76)!
Comment #81
Erso CreditAttribution: Erso commentedHad same issue, #76 / #80 worked for me too. But i hope this solution won't make another problem in future patches. ( Main language: English , there are 4 more languages)
Comment #82
hs@henrikstrindberg.se CreditAttribution: hs@henrikstrindberg.se commentedUpdated successfully from 8.6.16 to 8.7.2 after simply changing the default language from Swedish to English.
But before that I tried #80 without changing the default language and update failed:
I rolled back the database, changed the default language to English and successfully run
drush updb -y
Comment #83
psf_ CreditAttribution: psf_ at SDOS commented#82 don't work for me :(:
Comment #84
SIPS CreditAttribution: SIPS as a volunteer commentedTry this (after backup) :
Go to https://xxxxx.xxx/update.php, don't touch anything.
drop table dp_menu_link_content_field_revision, dp_menu_link_content_revision;
drop table dp_tmp_xxxxxmenu_link_content_field_revision, dp_tmp_xxxxxxmenu_link_content_revision;
refresh https://xxxxx.xxx/update.php and finish the update process.
Comment #85
catchMoving back to active since there's no patch to review here yet.
Comment #86
vuilComment #87
vuilComment #88
FMB CreditAttribution: FMB commentedHow can this be fixed? There might be workarounds, but no patch has been pushed yet.
Comment #89
cilefen CreditAttribution: cilefen as a volunteer commentedComment #90
hs@henrikstrindberg.se CreditAttribution: hs@henrikstrindberg.se commented#84 That's very good if you have already run the update process. But those tables are created during the update process. I haven't seen them in any D8.6.x database.
Comment #91
joegl CreditAttribution: joegl commentedWe had this issue on a site we started building a few years ago with Drupal 8.2. What happened (and I don't know how) is we had two rows in the menu_link_content table that weren't in the menu_link_content_data table. The menu items didn't exist "on-site" as far as pulling them up by ID. I dropped the two rows from the menu_link_content table and was able to upgrade successfully after. I'm not sure how it happened though.
Comment #92
joelseguinI was waiting for another 8.7 release to see if this was addressed because I ran into the same issue with 8.7's first release.
I have tried locally to update from 8.6.16 to 8.7.3 just now ... and it just worked! I did run into some composer issues while updating ended up removing vendor directory and core directory to get composer to update without errors.
So far so good. I'll be deploying to our server shortly and would assume that I'll get the same results since I pulled in the latest version of our database when doing this locally.
Comment #93
stevieb CreditAttribution: stevieb commentedjoelseguin you should test in a dev environment first. just to be safe..
Comment #94
joelseguinstevieb - just deployed on staging without any real issues. The only thing I noticed was that my primary home link has been deleted. All of my other nav items are there though. I just recreated my home menu item and back to normal.
Comment #95
yuseferi CreditAttribution: yuseferi commentedafter tried
faced " [error] Update aborted by: menu_link_content_post_update_make_menu_link_content_revisionable"
any solution or patch?
this issue is preventing us to update from 8.6.14 to 8.7.3
Comment #96
mlhyyl CreditAttribution: mlhyyl commentedI managed to "solve" it by uninstalling the module "Custom Menu Links" and then updating the database via the UI. The drawback, you will/might lose most menu links.
Comment #97
joegl CreditAttribution: joegl commentedWe also had the Custom Menu Links module installed when we got this issue. See my original comment here (#91): https://www.drupal.org/project/drupal/issues/3052318#comment-13142344
I wonder the Custom Menu Links module is related.
Comment #98
jedgar1mx CreditAttribution: jedgar1mx commentedIt is possible that any other modules that affect menus could break this update.
Comment #99
John_B CreditAttribution: John_B commentedFWIW I was seeing this problem when trying to run updates before ensuring that all my entities were updated: there were mismatched entity definitions. drush entup would not run. Dropping an index on users table as per https://drupal.stackexchange.com/questions/221930/mismatched-entity-and-... allowed me to run drush entup *before* updating code, after which I updated code then drush updb worked. That particular small D8 core update cost me several days debugging the issue (as well as multiple composer bugs) and a phpStorm licence :-)
Why sorting out my other updates problems apparently cured the menu_link_content update error is not clear.
Comment #100
blink38 CreditAttribution: blink38 commentedI have the same error when trying to update database on drupal 8.7.3.
The reason was I had an entry in the menu_link_content table with ID = 12 but no entry in the menu_link_content_data.
After removing all entries in menu_link_content which have no entry in menu_link_content_data, drush updb work perfectly.
This SQL will give you all entries to remove :
select m.id as id from menu_link_content m where m.id not in ( select id from menu_link_content_data);
Comment #101
vuilComment #102
mr_fenix CreditAttribution: mr_fenix commentedAdded a patch that will remove problem tables
Comment #103
vuilComment #104
catchComment #105
catchComment #106
RedLucas25 CreditAttribution: RedLucas25 as a volunteer and at Advisor Websites commentedI'm battling with this similar problem. Tried to patch and for whatever reason am getting
Failed: Drupal\Core\Entity\EntityStorageException: Exception thrown while performing a schema update. Cannot rename menu_link_content_revision to old_3c3aa8menu_link_content_revision: table menu_link_content_revision doesn't exist. in Drupal\Core\Entity\Sql\SqlContentEntityStorage->wrapSchemaException() (line 1607 of /var/aegir/platforms/dev2-lucas/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php).
Going to be investigating further, since I really need this fixed, but if anyone has any ideas... Ya, I'll keep y'all posted as well.
And yes, in the DB this table does indeed exist.
Comment #107
q__nt_n#102 Thanks for your patch but it didn't work the first time. I had to modify it by updating the list of tables to be deleted.
This is specific to each project so I don't propose a patch.
FYI : I add tables like
taxonomy_term_r__*
and all tables liketaxonomy_term_revision__
Comment #108
prsnjtbarman CreditAttribution: prsnjtbarman as a volunteer commentedI got an error while running "drush updb"
[error] It is not possible to change the entity type schema outside of a batch context. Use EntityDefinitionUpdateManagerInterface::updateFieldableEntityType() instead.
The module "menu_link_extras" which is not getting uninstalled with below command,
drush pm-uninstall menu_item_extras
Shows error like,
In SqlContentEntityStorageSchema.php line 408:
It is not possible to change the entity type schema outside of a batch context. Use EntityDefinitio
nUpdateManagerInterface::updateFieldableEntityType() instead.
Comment #109
AbdeI CreditAttribution: AbdeI commentedHello,
Thanks to #102 for the patch, however ive had to update it as well. Here it is.
Comment #110
q__nt_nHi Abdel,
Could you add an interdiff please ?
And as I said in #107, your tables in
taxonomy_post_update_make_taxonomy_term_revisionable_patched
method are specific to your project. For example, this is my table's list :May be we could do this dynamically ? I'll try this week-end
Comment #111
plachGuys, no point in working on a patch that's removing tables as it won't be accepted, since the update is meant to be run just once. See #3039586-103: Cannot rename tmp_2362aemenu_link_content_revision to menu_link_content_revision for more details. What we need is to figure what's causing the error reported in the IS, #100 is helpful from this POV. We need to figure out how to make sure that the
SqlContentEntityStorageSchema::copyData()
doesn't fail when dealing with corrupt entity data.Setting back to active since the current patches are going in a completely different direction and are only useful as workarounds.
Comment #112
plachComment #113
owenbush CreditAttribution: owenbush commentedI am currently seeing this upgrading to 8.7.8
All of my rows in menu_link_content have a bundle field value so I am not sure what is going on here. Also, all my menu_link_content entries have a corresponding menu_link_content_data entry.
I'll investigate a little and see if I can figure anything out.
Comment #114
John_B CreditAttribution: John_B commentedMaybe experiment with dropping index on the problem table, using a safe copy of the db, *before* any other attmept attempt at db updates? It worked for me in #99. Dropping the index is probably wrong, we should 'optimize table'. However, if dropping the index on a copy of the db allows entity update to run, it helps diagnose the cause of the issue.
Quite why D8 appears susceptible to corrupt db indexes is a bigger question.
Comment #115
owenbush CreditAttribution: owenbush commentedI think I have found what is causing my particular issue in #113. But I haven't quite figured out what to do about it.
It looks like the bundle field for menu_link_content is now an entity reference field, but the active field definition being used is a string. So when SqlContentEntityStorage::mapToStorageRecord() is called the column name it is attempting to use is 'value' (taken from the active field storage definitions), but given that the field is an entity_reference field that returns NULL. In this case it would need to use target_id rather than value.
Results in:
EDIT: I finally managed to get D8.7.8 to install and updates to run after updating the menu_item_extras module. Ugh.
Comment #117
gourav.yadav CreditAttribution: gourav.yadav commentedThanks #80 worked for me!
Comment #118
Wim Leers@gourav.yadav See @plach's explanation in #111 for why this is not considered an acceptable solution for Drupal core.
Comment #119
catchMarking #3052905: Failed while updating from 8.6.15 to 8.7.x: Update aborted by: menu_link_content_post_update_make_menu_link_content_revisionable as a duplicate of this issue.
#3052318-100: Update from 8.6 to 8.7 fails due to corrupt menu_link_content or taxonomy_term entity data is the most recent report of the actual bug here.
Comment #120
DamienMcKennaTagging as a requirement for Drupal 9.0-beta1.
Comment #121
catchUpdated the issue summary to try to make it clearer what actually needs fixing in this issue.
Comment #122
heddnPart of the issue seems from menu_item_extras
From slack:
Comment #123
AndyF CreditAttribution: AndyF at Fabb commentedThanks! I've started the ball rolling with the
hook_requirements()
code. It's my first time writing an update test so careful review welcome (: There's no interdiff as I think it's a different approach to the others.Some things I wasn't sure about:
hook_requirements
, I used an entity query testing ifenabled
is null.menu_link_content_field_revision
and/ormenu_link_content_revision
be populated in\Drupal\Tests\menu_link_content\Functional\Update\MenuLinkContentUpdateTest::testMissingDataUpdateRequirementsCheck
?We still need to write a change record with instructions IIUC. Thanks!
Comment #124
AndyF CreditAttribution: AndyF at Fabb commentedOops, reroll against 8.8.x...
Comment #125
alexpottI wonder if it is worth not only doing this on update. Like it might be nice to have this error on system status before running updates. I agree with only making the check if the
menu_link_content_post_update_make_menu_link_content_revisionable
is pending.Do we need to worry about the situation where there are no menu_link_content entities? I think we might - we could make this a count query.
I think given this is a single query I'd inline it into the test as it makes it easy to see what is going on.
Comment #126
catchDo you mean without checking if the post update has run so it's a permanent data-integrity checker? If so that seems like a good idea yeah.
Linking to a CR is the best we can do for more information.
Comment #127
catchCreated a stub CR we can link to at https://www.drupal.org/node/3117753
Comment #128
AndyF CreditAttribution: AndyF at Fabb commentedAddresses points in #125 + #126:
(:
I've updated it to check at runtime as well, but have left it checking if the post_update_hook has run for the time being.
Comment #129
catchThat will be a no-op on runtime, because every site that updates to the version with this code in, will run the post update at the same time, if they haven't run it already.
Comment #130
catchMoving to needs work for #129. If we check this outside update, we shouldn't also check for the post update having not run, otherwise that code will never get executed.
Comment #131
AndyF CreditAttribution: AndyF at Fabb commentedThanks @catch for the review!
This is I think what was suggested in #125-1. I was imagining it was a bit like the database updates check in
system_requirements()
(ie if you've done everything correctly you shouldn't really see it I don't think?). Anyway I've updated it to be a general runtime and install data integrity check. I haven't added an explicit test for the runtime check.Also still curious if we need to do anything with the query per #125-2? Thanks!
Comment #132
alexpott@catch has pointed out that the patch in #131 means if someone runs into the data integrity issue in the future, they won't be able to run any updates.
Sorry I've sidetracked things a bit but I think we should go back to checking the update hasn't run and only during updates. My bad. And thanks @AndyF for all the patches.
Comment #133
catchMaybe a follow-up for a runtime data-integrity checker? We could do this for all content entity types too.
Back to needs work again, sorry for confusion.
Comment #134
AndyF CreditAttribution: AndyF at Fabb commentedThanks both, we're getting there (:
Comment #135
catchOne more thing - we should check $phase === 'update' before we get pending update functions - this might require a nested if, but it will reduce the work we're doing for other hook_requirements() calls.
Apart from that I think this is ready.
Comment #136
plachI discussed this a bit with @catch: we agreed that it would be good to implement the exact same check also for taxonomy terms, for good measure.
@AndyF:
I'm available to work on this myself if you don't have time for it.
Comment #137
AndyF CreditAttribution: AndyF at Fabb commentedThanks @plach! Just double-checking, is that meant to be for this issue, or as part of the follow-up issue mentioned in #133?
Comment #138
plach@AndyF:
In this issue we need to apply the check for both entity types by simply duplicating the logic, while in the follow-up we will work on the generic data-integrity checker.
Comment #139
AndyF CreditAttribution: AndyF at Fabb commentedThanks @plach. Ah, I presume connected with
taxonomy_post_update_make_taxonomy_term_revisionable()
? Happy to add that: do we want to direct folk to the same CR in both situations, or does it make sense to have a more targeted one for each situation?Comment #140
plachCorrect,
taxonomy_post_update_make_taxonomy_term_revisionable()
is doing the same operation, so theoretically people can experience the same issues with missing data table records. The issue reported in #3056543: taxonomy_post_update_make_taxonomy_term_revisionable() and the menu link content equivalent fail when entities have no default translation might actually be an instance of that.I'd go with a single CR and maybe add an example for each entity type just in case.
Comment #141
AndyF CreditAttribution: AndyF at Fabb commentedCheers!
taxonomy_post_update_make_taxonomy_term_revisionable()
.Comment #142
plachCode looks great, I updated the CR to mention also taxonomy terms.
Comment #144
AndyF CreditAttribution: AndyF at Fabb commentedI think the failure for PHP 7.1 & MySQL 5.7 might be down to #3103492: Random fail in WidgetUploadTest. Rerunning...
Comment #145
catchI think this is ready to go!
Comment #146
xjmIt looks like we also need a 9.0.x-specific version of this since #141 did not apply to 9.0.x?
Comment #147
xjm(Because of the removed pre-8.8.0 upgrade paths, presumably.)
Comment #148
catchThe post updates will be removed from 9.0.x (and already don't run), so this is an 8.8/8.9-only patch.
Comment #149
xjmOne concern with the description here. A site owner isn't going to know what "The
taxonomy_post_update_make_taxonomy_term_revisionable()
function" is, or why they would care if they could run it or not. Wouldn't it be better to simply tell the user that database updates can't be run?I've also some concerns with #148, but discussing that with @catch now.
Comment #150
xjmOr, if we want to include the function name for debugging purposes:
Sorted #148 and all good on that front.
Comment #151
catch#150 looks like a good wording change. I think it's worth leaving the function name in for debugging and googling purposes. This alerts site owners to one data integrity issue, but we also have #3056543: taxonomy_post_update_make_taxonomy_term_revisionable() and the menu link content equivalent fail when entities have no default translation and potential issues with contrib modules too, so a very unlucky person might see that function name a couple of times, first time as update requirements warning, second time as backtrace for a database exception.
Comment #152
plachThe database updates report looks like this:
So for consistency we could display:
Comment #153
xjmYep, I was actually thinking of suggesting removing the parentheses, so +1.
Comment #154
mikelutzSo this?
Comment #155
mikelutzComment #156
mikelutzAnd a re-roll for 8.9?
Comment #159
xjmYep. We'll also need to update the tests to check for the new message.
Comment #160
andypostFix messages and spacing
Comment #161
xjmWe should also still remove the parentheses as suggested by @plach. (If we remove the module prefix, it's no longer a valid function name.)
Comment #162
AndyF CreditAttribution: AndyF at Fabb commentedRemove parentheses and correct the check if the post update has run, thanks.
Comment #163
AndyF CreditAttribution: AndyF at Fabb commentedAnd #162 rerolled for 8.9.
Comment #164
catchThe new message in #162 is a good improvement. Also the change record now has examples for both menu links and taxonomy terms.
Back to RTBC.
Comment #165
xjmA nitpick is that it might have been good to have a comment here something like "Insert invalid data for a non-existent taxonomy term." (And the same but "non-existent menu link" for the menu link test.)
Comment #166
jungleComments added
Comment #167
xjmThat looks great, thank you @jungle!
Comment #168
xjmComment #169
xjmSaving issue credit.
Comment #170
xjmA few more.
Comment #171
xjmWe'll want to mention this in the 8.8.4 release notes, because it's just giving them additional information on how to run their updates, rather than actually resolving the issue for them. Something like:
Comment #173
xjmMeanwhile, the test runs have passed on all three databases supported by Drupal 8, so committed and pushed to 8.9.x!
Can we get an 8.8.x version of the latest patch in #166?
Comment #174
xjmComment #175
catchApplied with patch -p1 with a bit of fuzz.
Comment #176
xjmDid a
diff -uP
locally to confirm the two patches are the same thing. Waiting on the bot, though.Comment #178
xjm..Which is done now. Committed the backport to 8.8.x. (I published the CR already.) Thanks!
Comment #179
xjmMeant to leave this open for a potential 8.7.x backport.
Comment #180
catchComment #181
AndyF CreditAttribution: AndyF at Fabb commentedRolled against 8.7, thanks.
Comment #182
plachLooks good
Comment #184
catchCommitted bc042bd and pushed to 8.7.x. Thanks!
Comment #185
jedgar1mx CreditAttribution: jedgar1mx commentedThis is awesome, great work everyone!!
Comment #186
vuilWell done! Congratulations!
#181 works perfectly on Drupal 8.7.11
(the patch will be published in the 8.7.12 stable release)
Comment #187
vuilComment #188
xjmBecause CKEditor.
Comment #189
xjmAlso putting this in the 8.9.0-beta1 release notes since that release is going to be out before 8.8.5.
Comment #191
dadderley CreditAttribution: dadderley as a volunteer and commentedHi,
This issue is marked as being fixed.
But after several days of trying, I am unable to update a site from drupal-8.6.17 to 8.7.7 (or any version)
I did patch apply this patch (#181 3052318-180.8.7.patch) to my 8.7.11 installation.
https://www.drupal.org/project/drupal/issues/3052318#comment-13495986
I also enabled the language module so the taxonomies have English set as the default language.
This is the last output when trying to update a happy 8.6.17 install to 8.7.11
I have scoured the issue pages and have not found a solution. I have spent a couple of days on this already.
And as I was about to publish this, I noticed the blurb on the top of the page:
.
So, starting with a clean 8.6.12 DB. I try to do an update to 8.8.4
When I run the update db I get this:
Same error.
I have a site with about a dozen vocabularies and hundreds of terms.
I really do not want to rebuild this from scratch.
Can someone tell me a way to make the migration work.
Comment #192
amateescu CreditAttribution: amateescu for Pfizer, Inc. commented@dadderley, the root cause for these errors is usually some field storage definitions that are not installed or updated correctly, either by a contrib module or a custom one, and the fix can be either individual for each site that experiences a problem with an entity type conversion, or a patch for a contrib module.
If you can send me a copy of your codebase and a sanitized database dump (e.g. all the nodes/users/etc. deleted), feel free to contact me in the Drupal slack or using drupal.org's personal contact form, and I can try to help out. This worked out well for a similar issue with the Entityqueue module, where it turned out the problem was in another contrib module, see #3128057-37: Error updating to v1.0 and #3126343-11: Scheduler needs to maintain its base fields properly.