Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Hi, When I try to update Drupal 8.7.0 db br drush updb I get the following error.
> [notice] Update started: taxonomy_post_update_make_taxonomy_term_revisionable
> [error] Drupal\Core\Database\IntegrityConstraintViolationException: SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'name' cannot be null: INSERT INTO {tmp_d305d9taxonomy_term_field_data} (tid, revision_id, vid, langcode, name, description__value, description__format, weight, changed, default_langcode, status, revision_translation_affected) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5, :db_insert_placeholder_6, :db_insert_placeholder_7, :db_insert_placeholder_8, :db_insert_placeholder_9, :db_insert_placeholder_10, :db_insert_placeholder_11); Array
> (
> [:db_insert_placeholder_0] => 1
> [:db_insert_placeholder_1] => 1
> [:db_insert_placeholder_2] => tags
> [:db_insert_placeholder_3] => tr
> [:db_insert_placeholder_4] =>
> [:db_insert_placeholder_5] =>
> [:db_insert_placeholder_6] =>
> [:db_insert_placeholder_7] =>
> [:db_insert_placeholder_8] =>
> [:db_insert_placeholder_9] =>
> [:db_insert_placeholder_10] =>
> [:db_insert_placeholder_11] => 1
> )
> in Drupal\Core\Database\Connection->handleQueryException() (line 689 of /var/www/drupal8/web/core/lib/Drupal/Core/Database/Connection.php).
> [error] The entity update process failed while processing the entity type taxonomy_term, ID: 1.
> [error] Update failed: taxonomy_post_update_make_taxonomy_term_revisionable
[error] Update aborted by: taxonomy_post_update_make_taxonomy_term_revisionable
[error] Finished performing updates.
Comment | File | Size | Author |
---|---|---|---|
#63 | fix_term_statuses-3052464-61.patch | 1.81 KB | Niklan |
#48 | composer.json_.zip | 1.13 KB | kazajhodo |
#15 | tge_0_7_2019-05-06.sql_.zip | 6.84 KB | m-si |
Comments
Comment #2
salihcenap CreditAttribution: salihcenap as a volunteer commentedComment #3
arnoldbird CreditAttribution: arnoldbird commentedComment #4
xjmComment #5
salihcenap CreditAttribution: salihcenap as a volunteer commentedComment #6
amateescu CreditAttribution: amateescu for Pfizer, Inc. commented@salihcenap, do you have a backup of the database before running the updates? If so, can you look at the
taxonomy_term_field_data
table and post its contents for the term with id 1?Comment #7
yasI also encountered the following error while I was trying to update my site from
8.6.15
to8.7.0
although my case is related to this issue:Besides the above error, also Recent log messages:
Screenshot:
Database record in
taxonomy_term_field_data
:Comment #8
amateescu CreditAttribution: amateescu for Pfizer, Inc. commented@yas, in your case it seems like the data in
taxonomy_term_field_data
is corrupted somehow, thestatus
column should never value NULL values.If your site doesn't require some taxonomy terms to be unpublished, I think you should update all the records in that table with the value
1
for thestatus
column and then try to re-run the updates.Comment #9
yas@amateescu,
Thank you for your advice. Yes, I found that and updated all the records in that table with the value
1
for thestatus
column.As a result, it was successful (thanks!),
However when I tried to edit my existing article (node), it gives the following errors:
Drupal\Core\Entity\EntityStorageException: SQLSTATE[42S22]: Column not found: 1054 Unknown column 'revision_timestamp' in 'field list': INSERT INTO {node_field_data} (nid, vid, type, langcode, title, uid, status, created, changed, promote, sticky, revision_timestamp, revision_uid, revision_log, revision_translation_affected, default_langcode, content_translation_source, content_translation_outdated) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5, :db_insert_placeholder_6, :db_insert_placeholder_7, :db_insert_placeholder_8, :db_insert_placeholder_9, :db_insert_placeholder_10, :db_insert_placeholder_11, :db_insert_placeholder_12, :db_insert_placeholder_13, :db_insert_placeholder_14, :db_insert_placeholder_15, :db_insert_placeholder_16, :db_insert_placeholder_17), (:db_insert_placeholder_18, :db_insert_placeholder_19, :db_insert_placeholder_20, :db_insert_placeholder_21, :db_insert_placeholder_22, :db_insert_placeholder_23, :db_insert_placeholder_24, :db_insert_placeholder_25, :db_insert_placeholder_26, :db_insert_placeholder_27, :db_insert_placeholder_28, :db_insert_placeholder_29, :db_insert_placeholder_30, :db_insert_placeholder_31, :db_insert_placeholder_32, :db_insert_placeholder_33, :db_insert_placeholder_34, :db_insert_placeholder_35); Array ( [:db_insert_placeholder_0] => 68 [:db_insert_placeholder_1] => 68 [:db_insert_placeholder_2] => article [:db_insert_placeholder_3] => en [:db_insert_placeholder_4] => Bash: Numbering the processing command [:db_insert_placeholder_5] => 1 [:db_insert_placeholder_6] => 1 [:db_insert_placeholder_7] => 1555633799 [:db_insert_placeholder_8] => 1556921580 [:db_insert_placeholder_9] => 1 [:db_insert_placeholder_10] => 0 [:db_insert_placeholder_11] => [:db_insert_placeholder_12] => 1 [:db_insert_placeholder_13] => [:db_insert_placeholder_14] => 1 [:db_insert_placeholder_15] => 0 [:db_insert_placeholder_16] => ja [:db_insert_placeholder_17] => 0 [:db_insert_placeholder_18] => 68 [:db_insert_placeholder_19] => 68 [:db_insert_placeholder_20] => article [:db_insert_placeholder_21] => ja [:db_insert_placeholder_22] => Bash で、処理に番号をつける(採番する) [:db_insert_placeholder_23] => 1 [:db_insert_placeholder_24] => 1 [:db_insert_placeholder_25] => 1555633524 [:db_insert_placeholder_26] => 1555694739 [:db_insert_placeholder_27] => 1 [:db_insert_placeholder_28] => 0 [:db_insert_placeholder_29] => [:db_insert_placeholder_30] => 1 [:db_insert_placeholder_31] => [:db_insert_placeholder_32] => 1 [:db_insert_placeholder_33] => 1 [:db_insert_placeholder_34] => und [:db_insert_placeholder_35] => 0 ) in Drupal\Core\Entity\Sql\SqlContentEntityStorage->save() (line 847 of /var/www/html/d8/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php).
Looks failing the update for
node_field_data
table? (I checked that table in the database but it couldn't find therevision_timestamp
column) Should it be another issue such as Cannot convert custom entity types from non-revisionable to revisionable with pre-8.7.x compatible methods?Comment #10
amateescu CreditAttribution: amateescu for Pfizer, Inc. commented@yas, a new issue for that would be great. It looks like there's some corrupted data in the last installed entity definitions, and the Node entity type doesn't have the values for
revision_metadata_keys
set properly.Comment #11
salihcenap CreditAttribution: salihcenap as a volunteer commented@amateescu unfortunately I have no backup. I started over by a brand new installation. Thanks.
Comment #12
Gib... CreditAttribution: Gib... commentedHi,
Got the same error:
"Integrity constraint violation: 1048 Column 'status' [error] cannot be null".
I looked into taxonomy_term_field_data with phpMyadmin.
Seems there is no status column at all. Here are the fields I see in the structure :
tid , vid , langcode, name, description__value, description__format, weight, changed, default_langcode
What could I do ? I don't know what the parameters of that field should be.
Comment #13
m-si CreditAttribution: m-si commentedHi, I got the same Issue. Afte reading the thread I checked in my backup DB the taxonomy_term_field_data status and it showed for all of the status entries 1 but I found some strange devel generate terms which I couldn´t see via the web ui...so I examined those entries (and found out that they have despite the other terms the lang_code set to 0...the others had 1) and after finding them unesful killed their entries in taxonomy_term_field_data, taxonomy_term_data and taxonomy_term__parent. Updating after that operation via drush updb was sucssesfull...
Comment #14
amateescu CreditAttribution: amateescu for Pfizer, Inc. commented@Gib..., what version of Drupal are you updating from? If you are updating from 8.6.x, you should have the status field (and the table column) installed by
taxonomy_update_8601()
. If you somehow didn't run that update function, you can execute it manually with Drush, using this command:drush eval "module_load_install('taxonomy'); taxonomy_update_8601();"
@m-si, I'm glad you were able to fix the problem :)
Comment #15
m-si CreditAttribution: m-si commentedJust for the records I made an sql dump of the table (taxonomy_term_field_data, taxonomy_term_data, taxonomy_term__parent) attached. I have been updating from 8.6.15 to 8.7.0. The fields that have been killed have the TID 2 und 3...altough the aportion of the update process was made for TID 2...May be this helps in further examination...
Comment #16
arnoldbird CreditAttribution: arnoldbird commentedThe solution in #8 seems to have worked for me, though I haven't tried it on my production site yet.
PS -- Short URLs are no longer working in my staging site, but this may be an unrelated problem.
PPS -- Clearing the Drupal performance cache got short URLs to work again. Odd, I've never had to do that before following an upgrade.
Comment #17
arjun@pennywisesolutions CreditAttribution: arjun@pennywisesolutions commentedHi Every One I have also got same issue. I saw some taxonomy term data which is not showed in the administrator section. if i could delete which ever the items not visible in administrator section i am able to run the drush updatedb.
I have done this steps in drupal version update from 8.6.15 to 8.7.0
Comment #18
charly71 CreditAttribution: charly71 commentedSame issue for me
Comment #19
RealityBitesYou CreditAttribution: RealityBitesYou as a volunteer commentedSame issue. I cloned my production vm and updated drupal in the clone with the same result as the others. Manually updating taxonomy_term_field_data.status=1 had no effect on drush updb:
Then I selected data where status = null and got nothing back:
Comment #20
RealityBitesYou CreditAttribution: RealityBitesYou as a volunteer commented@m-si which table had the broken data?
Comment #21
RealityBitesYou CreditAttribution: RealityBitesYou as a volunteer commentedThis worked for us:
Reinstall the drupal codebase from scratch then run the db updates against your database. Copy your themes, modules, files etc in.
This worked for us on a production duplicate vm.
The database updates would not finish before, now they do with drupal 8.7.0 against same database... I still haven't found the actual issue but at least there's a workaround :-)
Naturally your mileage may vary: run on a copy of production.
UPDATE: Tried this again, and it failed the second time....
Comment #22
m-si CreditAttribution: m-si commented@RealityBitesYou In taxonomy_term_field_data the two entries with TID 2 and TID 3 and the corresponding entries 2 and 3 in taxonomy_term_data, taxonomy_term__parent...for sur not the best way to kill them in the database, but well...
Comment #23
RenrhafSame issue here.
Comment #24
RealityBitesYou CreditAttribution: RealityBitesYou commentedFrom https://www.drupal.org/project/drupal/releases/8.7.0:
Custom menu links and taxonomy terms are now revisionable, which allows them to be used in editorial workflows (similarly to nodes, media, and custom blocks). These changes involve an upgrade path and updates to the respective entity storages. Custom code updating these entities programmatically may need to update to take account revision creation. This may also impact API clients, exported default content, and custom database queries. See the change records for details:
Custom menu links are revisionable
Taxonomy terms are revisionable
We had taxonomy_menu installed. Uninstalling this module (which has no data for us) allowed the upgrade to proceed with no issues. It was installed in our setup by a contractor, but never used. Check your third party modules! If that's not the issue there's a lot of stuff in those release notes to research.
Stuff like this is another great reason to get rid of any modules you are not using and clean things up!
Cheers!,
Neil
Comment #25
AnnaPalm CreditAttribution: AnnaPalm commentedI have same error.
When i try update from update.php
If i try update from drush updb
Some One fix this ?
Comment #26
Tritof CreditAttribution: Tritof commentedSame issue when updating (without drush)
Comment #27
zanvidmar CreditAttribution: zanvidmar as a volunteer commentedI got same issue because I had terms generated with devel/drupal console. In table "taxonomy_term_field_data" in column "default_langcode" the values were 0. After I change the "0"s to "1"s the update script was successful. Even doe it does not solve the initial issue it may help someone.
The similar situation is also described at #13
Comment #28
afeijoI'm have a similar problem, the error with with the taxonomy_term_field_data.name field, saying that it cannot be null, although I have no record with null name, naturally.
Do anyone know if we can skip this, or any workaround?
Comment #29
plach@AnnaPalm:
Can you try #3052318-55: Update from 8.6 to 8.7 fails due to corrupt menu_link_content or taxonomy_term entity data?
@Tritof:
Can you try #13?
@afeijo:
The error should also report the ID of the term that's making the update fail: can you export its records in the various term tables and post them here? Unfortunately you cannot skip this update, but it may be possible to manually correct your DB to make the update succeed (see #8 or #13 for two examples).
Comment #30
afeijothank you for your reply @plach
but my problem is not with the status field but with the name field.
I naturally have no records without name since that field is required (not null) :)
and I did try checking the content for record 423, but:
Comment #31
andrew_l CreditAttribution: andrew_l commentedHad the same problem here. The error message when updating was referring to Term ID 27. There were no records in 'taxonomy_term_field_data' relating to this id.
I found that in the 'taxonomy_term_data' table, there was a record with 'tid' = 27, which had a 'vid' of 'test_vocab'. This vocabulary no longer existed on the site, and presumably was leftover from some old dev work.
I deleted the record from taxonomy_term_data table, and the update subsequently worked for us.
Comment #32
plach@afeijo:
You should check all the
taxonomy_term_*
tables for records with the problematic IDs: the reason why the update fails seems to be orphan or corrupt data in those tables. For instance you may have a record with TID 423 intaxonomy_term_data
but no corresponding record intaxonomy_term_field_data
, which would of course break any attempt of resaving such an entity.In such scenario the easiest thing to fix the update is removing the orphan records, if at all viable.
Comment #33
plach@amateescu:
I'm wondering whether it would make sense to perform some kind of data integrity validation on the entity before restoring it and skip it if it does not pass. Or maybe we could catch storage exceptions if
$entity->validate()
returns any violation.Comment #34
robbdavis CreditAttribution: robbdavis commentedSame issue here. Update to 8.7 breaks because the taxonomy db update fails. It is trying to process an old term that was generated by the devel module. So this is the same issue as #13.
Is there a way to delete these via the ui? Or another way around this without sending up code?
Or do I need to send up an update hook to delete these before I do the update to 8.7?
Comment #35
plachYou can remove orphan records from a SQL client. Backup everything first! :)
Comment #36
andyg5000I'm seeing the same thing updating from 8.6.15 to 8.7.1. I also show entity update mismatches below. Running entity-updates shows that it completes successfully, but does not actually run the updates. I don't see any orphaned or corrupted terms as others have mentioned, but we do have about 13,000 terms from a big migration.
Taxonomy term
The Taxonomy term entity type needs to be updated.
The Revision ID field needs to be installed.
The Revision create time field needs to be installed.
The Revision user field needs to be installed.
The Revision log message field needs to be installed.
The Default revision field needs to be installed.
The Revision translation affected field needs to be installed.
Custom menu link
The Custom menu link entity type needs to be updated.
The Revision ID field needs to be installed.
The Revision create time field needs to be installed.
The Revision user field needs to be installed.
The Revision log message field needs to be installed.
The Default revision field needs to be installed.
The Revision translation affected field needs to be installed.
Comment #37
robbdavis CreditAttribution: robbdavis commentedThanks @plach. Because this was a pantheon site, I didn't think there was a client. But it turns out there is connection info in the UI. I connected with sequel pro, deleted the problem term id's (TID) in taxonomy_term_field_data, taxonomy_term_data and taxonomy_term__parent. Update worked after that.
Comment #38
robbdavis CreditAttribution: robbdavis commented@andyg5000 I'd bet your problem is with some of those terms. The offending terms for me had the default_langcode set to 0. Maybe you could do a search for that?
Comment #39
lathan8.7.x a bunch of fewie.. this is the 3rd core bug im facing with this update.
Error im seeing is that it cant rename the schema.
Comment #40
lathanThe error reported in https://www.drupal.org/project/drupal/issues/3048595 is similar, but not the same as we do not swop out the SqlContentEntityStorage backend.
Also here we are reviving an exception from Renaming the temp table to taxonomy_term_revision which already exists
Comment #41
andyg5000Hey Y'all,
If you had layout builder installed before 8.7.x, I recommend checking out #3052431: layout_builder_post_update_make_layout_untranslatable() still attempts to query all revisions for non-revisionable entities. After applying the patch in #7 of that issue, I was able to run updatedb successfully. Without it, I would get the error below and the taxonomy and menu updates would never complete because of it.
After applying the patch, my update completes and the revision tables are created.
Comment #42
m-si CreditAttribution: m-si commented@andyg5000 I tested layout builder as well in that installation. but it was uninstalled via drush already some composer updates before (via drush pmu and composer remove...) taxonomy_menu was also tested in that installtion...im still exmine to narrow the source...
Comment #43
Sbonder CreditAttribution: Sbonder commentedThanks @amateescu solution #8 worked perfectly.
Comment #44
amateescu CreditAttribution: amateescu for Pfizer, Inc. commented@plach:
I like that idea! We could log all the entities that couldn't be migrated to the new storage and tell the site owner that they need to be restored manually from the
old_...
tables.That would resolve most problems for sites that couldn't restore one or a few terms, like the ones mentioned in this issue, but it would be a bit problematic for sites that couldn't restore anything, like most of the
menu_link_content
upgrade issues..Comment #45
mydoglixu CreditAttribution: mydoglixu commentedI'm having the exact same issue, but my database doesn't seem to have any bad entries, nor is the data shown in the output even relevant to my own database.
Here is the output:
I checked `taxonomy_term_field_data` and there are no records where `name` is NULL, nor do I even have any records with langcode `zxx`, so I'm a bit at a loss now. Seems like there's nothing I can delete to fix this like in the answers above.
Comment #46
divined CreditAttribution: divined as a volunteer commentedWe have 300k of terms. We got 14400 session timeout for drush command and mysql timeout for this operation.
Each iteration of converting spend more and more time.
It starts from 1000 terms per one second, and after 2000 iterations it spends 3 seconds for 1 term ((
And the main problem: we can't continue to work after break (
Each time it creates new temp tables (
Comment #47
Kate Heinlein CreditAttribution: Kate Heinlein as a volunteer commentedMy taxonomy_post_update_make_taxonomy_term_revisionable was failing because I had fields on the terms which I created via hook_entity_field_storage_info / hook_entity_bundle_field_info.
SqlFieldableEntityTypeListenerTrait was then failing because it didn't had a temporary table created to copy the field items:
My solution was to make those fields revisionable before the update, and the update itself ran without errors.
Comment #48
kazajhodo CreditAttribution: kazajhodo commentedAfter a bunch of struggling with this update, I've been able to consistently update. I'm not sure the original drupal version, but it was an older site, so likely 8.5ish. This is what I did— before getting this to work I ran into allllllll of the issues devs have been posting.
The media isssue, the taxonomy issue, the paragraphs issue.... pretty sure I hit them all. Try the following. This worked for me, but keep in mind its at your own risk. At the very least this will likely get you further down the road.
Delete whatever database you've been using, meaning specifically delete all of the tables so you are clean. Use your original db before update attempts.
In your web root, delete composer.lock and your vendor folder. Check that your composer.json is similar to the file i've attached. Yours may be different, this is a pantheon hosted site, so composer doesn't control modules in our case. I know I know, its just how it works.
Make sure you have the drupal/core line, the drush/drush, drupal/paragraphs(if you use it), drupal/devel_entity_updates module. The devel_entity_updates will allow up to run entity updates, as that was removed in 8.7.1. Meaning drush entup no longer does anything... even though it looks like it does. However you can just run it indefinitely, it does nothing. This is in the update notes.
Once you all that squared up, run composer install.
Get into terminal.
Run 'drush en devel_entity_updates'
Run 'drush updb'
Once it completes, run it again, take note of where it fails. If you use paragraphs, its likely there. Open up the paragraphs module, the paragraphs.install file. Comment out the interior of the 'paragraphs_update_8016' hook. Meaning leave the function, just comment the contents.
Run 'drush updb'.
Now it should finish, if you run it again it should say nothing to update.
Uncomment the paragraphs_update_8016. This did do its job and for future no longer matters. It had done its job on the initial run, but then gets hung up for some reason. There is likely something deeper here.
Now lets run 'drush entup -y'. The -y just automatically answers the prompt.
This will fail if you use paragraphs. Key parts are 'Column not found: 1054 Unknown column 'revision_uid'', and the table 'paragraphs_item_field_data'. Get our your db editor and open up that table. Take a look at the structure, there is no 'revision_uid' column, hense the error. Add it. It can be similar to the 'revision_id', but at least in sequal pro the default column addition worked fine for me.
Run entup again. Now it will find the column, and do what it needs to do. Refresh your table, note that the column you added is now deleted by the update script. All good.
If you now run dbup or entup, both will complete, for real, just fine.
There may of course be other complications beyond this depending on your install, but this resolved the database media, taxonomy issues, entity update issues.
Comment #49
Gib... CreditAttribution: Gib... commentedHi,
Was updating from 8.6.15 to 8.7.0 - did not tried 8.7.1 yet since this issue isn't solved.
Again, from this error :
SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'status' [error]
cannot be null: INSERT INTO {tmp_ddd0c3taxonomy_term_field_data} (tid, revision_id, vid, langcode, name, description__value,
description__format, weight, changed, default_langcode, status, revision_translation_affected) VALUES (:db_insert_placeholder_0, etc...
:db_insert_placeholder_11);
My limited understanding is that the table should have 12 columns in the table. I cannot see the temp_ddd0c3 table.
But in the table taxonomy_term_field_data, I can see in phpMyAdmin that the table has only 9 columns.
The three missing columns are : revision_id, status and revision_translation_affected.
I can see in the error that :
[:db_insert_placeholder_0] => 16
[:db_insert_placeholder_1] => 16 Revision_id is set in the tmp_dddc3 table to the same value as tid
...
[:db_insert_placeholder_10] => Seems trying to be set status to NULL and status doesn't exist.
[:db_insert_placeholder_11] => 1 this value might come from code but revision_translation_affected doesn't exists
#14 , drush eval "module_load_install('taxonomy'); taxonomy_update_8601();"
didn't changed anything. No error, nothing after running it, but drush updb gave the same error.
So seems like the update.php tries to insert values in a temp table with 3 missing columns because they don't exist in the real table.
My questions :
Can I add the 3 missing columns with phpMyAdmin ?
If yes, what should be the values of those fields (revision_id, status and revision_translation_affected)
in the structure ( type, interclassment, attributes,null, default values ?
Comment #50
Gib... CreditAttribution: Gib... commentedHi,
I decided to give a try to something else. I restored 8.6.15. When I ran drush updb I got this :
The following updates are pending:
menu_link_content module :
Update custom menu links to be revisionable. Ok yes run it then I got this other message
Error: Call to undefined method Drupal\Core\Entity\EntityDefinitionUpdateManager::updateFieldableEntityType() in
menu_link_content_post_update_make_menu_link_content_revisionable()
So something was already wrong in 8.6.15 ?
I usually use Softaculous UI to upgrade Drupal then I run update.php from the Drupal UI ..... Maybe that's the problem.
Restoring to 8.6.14 ....
Same error...
Found many related posts by searching updateFieldableEntityType
Gets more and more complicated...
Comment #51
arafalov CreditAttribution: arafalov as a volunteer commentedI am hitting a similar on in 8.7.1, which - I am sure - is because I have an entity change code that redefined 'name' field length in the DB. So, it crashes on field length during the copy to the temp table.
So, I am trying to fix it by updating the field definition and it still crashes with field length.
My code is (possibly wrong but just in case):
BUT this makes me wonder on HOW the temporary tables are created? Is it possible that those temp tables are created from an original rather than last installed schema definition? That would explain different possible crashes, as there might be schema inconsistencies.
Comment #52
Gib... CreditAttribution: Gib... commentedHi,
I tried to go back to 8.6.12 and use Drush to update to 8.7.1.
Never had problems before from 8.4.0.... I upgraded from a 7.6.X which I don't want to redo (much work later).
Core was updated to 8.7.1 but I'm stock with these updates :
The following updates are pending:
taxonomy module :
Update taxonomy terms to be revisionable.
Remove the 'hierarchy' property from vocabularies.
views module :
Update exposed filter blocks label display to be disabled.
Rebuild cache to allow placeholder texts to be translatable.
The taxonomy_term_field_data stopping the update because of the error described above, #49
Options ??
I have only about 20 taxonomy terms but a few hundreds node using them.
Comment #53
akhepra CreditAttribution: akhepra commentedHi,
I had this problem and try infinite ways to solve it. I try updating core first and the problem appear. I revert to 8.6.1 and the error was not there. I updated everything I could before retrying updating to 8.7.1. I even learn and did a composer installation and the error still appear.
The I read the #13 comment and check my db and found some Devel Generated Taxonomy terms. I couldn't delete it via phpMyAdmin because everything broke. So I did a fresh reinstall of 8.6.1 version and created a view for taxonomy terms showing ID.
I found the two terms with id but without name. I try to delete the via Views Bulks Operation but it didn't react to delete operation. So I went directly to the term via url and I after I open the term, that was completely empty, I delete them inside edit.
After that I try the core update without any problem, event though the db update gave a message, it was purely informative. The taxonomy terms where now revisionable.
So I suggest you check your taxonomy terms thoroughly, you may find some ghost term.
I hope this helps.
Comment #54
arafalov CreditAttribution: arafalov as a volunteer commented@akhepra, I found a combination of structure_sync module and config export/import is a nice way to eyeball and even hand-fix some of the taxonomy issues.
Comment #55
akhepra CreditAttribution: akhepra commented@arafalov, you mention a module and a tool I have never use, do you care to explain in more detail?
Comment #56
arafalov CreditAttribution: arafalov as a volunteer commented@akhepra,
structure_sync module will push/pull your taxonomy, menus, and/or blocks into simple configuration under structure_sync.data key. Which you can then see using Configuration Management shipped in the latest Drupal (and maybe before). It is under: /admin/config/development/configuration or under Drush cex/cim commands.
You can import and export single items too via UI, so don't have to do full export/import.
Comment #57
catch#46 and #47 look like two very separate issues so I've opened #3056539: Updating an entity type from non-revisionable to revisionable fails if it has non-revisionable fields stored in dedicated tables and #3056540: taxonomy_post_update_make_taxonomy_term_revisionable() timeouts with large numbers of terms for them.
Also #3056543: taxonomy_post_update_make_taxonomy_term_revisionable() and the menu link content equivalent fail when entities have no default translation for empty term names as confirmed in #53.
Comment #58
catchNow that all the specific issues are split into dedicated bug reports, I'm going to move this to a support request for now.
Comment #59
gnikolovskiThis just happened to me while I was trying to update my personal site from 8.6.15 to 8.7.2.
I fixed it and then wrote a blog post. Figured it might help somebody.
https://gorannikolovski.com/blog/taxonomy-post-update-make-taxonomy-term-revisionable-fails
Comment #60
Gib... CreditAttribution: Gib... commentedHi everyone,
Remember that my problem seemed to be that I did not had any Status column in the taxonomy_term_field_data table.
Here is what I did.
I added the column with phpMyAdmin, using the details I found in :
#3056543: taxonomy_post_update_make_taxonomy_term_revisionable() fails when term name or status is NULL
I have only 20 taxonomy terms, so I manually changed the status from 0 to 1.
And then tried again running update in Drush :
The following updates are pending:
taxonomy module :
Update taxonomy terms to be revisionable.
Remove the 'hierarchy' property from vocabularies.
views module :
Update exposed filter blocks label display to be disabled.
Rebuild cache to allow placeholder texts to be translatable.
Do you wish to run all pending updates? (y/n): y
After update of taxonomy [ok]
After update of taxonomy [ok]
After update of views [ok]
After update ofviews [ok]
After update of views [ok]
After update of views [ok]
After update of views [ok]
After update of views [ok]
Cache rebuild complete. [ok]
Finished performing updates.
Then I updated 8.7.1 to 8.7.2.
No database updates required
No problem.
All my taxonomy terms show up in the UI.
So all I needed was the column specification for taxonomy_term_field_data:
| Field | Type | Null | Key | Default | Extra |
| status | tinyint(4) | NO | MUL | NULL | |
Now
revision_id is a column present in taxonomy_term__parent and taxonomy_term_data
status is a column present in taxonomy_index and taxonomy_term_field_data
revision_translation_affected is a column present in taxonomy_term_field_data
Bye
Gib...
Comment #62
rmafat CreditAttribution: rmafat commentedI updated multiple Drupal site from 8.6.15 to 8.7.2. For some sites, there was no problems, but for some others, a lot, and I can't explain why...
But I found solutions, you need to access mysql command :
/!\ You can retry
drush updb
command after each point, but sometimes, it's necessary to execute adrush cr
command before.1. Check if there is data with status = NULL in the taxonomy_term_field_data table.
SELECT * FROM taxonomy_term_field_data;
If there is null status, update with a boolean value.
UPDATE taxonomy_term_field_data SET status = 1 WHERE status IS NULL;
2. Foreach taxonomy table, check if strange data exists, like very long and incomprehensible string, or langcode column value like und, or zxx. Delete these data, it's not yours.
DELETE FROM taxonomy_term__parent WHERE langcode IN('und', 'zxx');
3. During the
drush updb
, temporary tables are created. But when the command crash, these table are not always deleted properly. If there is table starting with tmp... or taxonomy table containing revision string, DROP the table.4. Finally, if the
drush updb
still doesn't work, alter the table and set the status column nullable.ALTER TABLE taxonomy_term_field_data MODIFY status TINYINT(4) NULL;
After the
drush updb
, reset the status to non nullable.ALTER TABLE taxonomy_term_field_data MODIFY status TINYINT(4) NOT NULL;
Please, be careful when your alter your database...
I hope it can help some of you :)
Comment #63
NiklanLooks like ppl having a problem initially provided by
taxonomy_update_8601()
as mentioned in #8 - this update adds status field to the taxonomy terms. On existed sites, the value for this field is not set during the update and leaved as NULL. This cause problem with displaying terms via default views, which got a new filter "published = true", and now is here.I write a simple update hook that fixes statuses, after it
taxonomy_post_update_make_taxonomy_term_revisionable
applied without any problems.
If you want to test my patch, backup database before applying it, and clear the cache.
The better way is it helps you, to split up this process:
0. Backup everything.
1. Create hook_update_N() for your custom module with the same code.
2. Apply it.
3. Deploy it to production BEFORE upgrading Drupal. Just this update to make sure, it updates all values in DB.
4. Update Drupal as usual and all updates will pass.
5. Deploy to production.
The main reason is to not use this patch as a solution because later on here can be real taxonomy_update_8702, and by using this patch, it will be skipped, because it will be marked as complete in DB.
Comment #64
MurzSeems the source of my problem is mysql timeouts on update process with
PHP Fatal error: Uncaught PDOException: SQLSTATE[HY000]: General error: 2006 MySQL server has gone away
In my situation the source of this problem is missing fields in some tables (compared with fresh clean 8.7 install) after update:
Repeating
taxonomy_post_update_make_taxonomy_term_revisionable
function don't solve the problem, so I create missing fields manually and filled up with values via queries:And Table Mapping is not updated to, so I manually fill up it with right values:
After this fatal error is disappear, and I can normally see taxonomy term lists in vocabulary overview pages!
Notices are still here:
Notice: Undefined index: value in Drupal\taxonomy\TermStorage->getTermIdsWithPendingRevisions() (line 381 of core/modules/taxonomy/src/TermStorage.php).
How can I repeat table mapping update after manually creating fields?
Via
drush entup
together withdevel_entity_updates
module I can't update tables because of error:Comment #65
MurzI successfully solve this issue on already upgraded from 8.6 to 8.7 database on working site, that shows fatal error, via those steps:
1. Increase mysql timeouts in mysql.conf:
2. Manually delete sql-tables from database (if already exists):
3. Remove info about installed taxonomy updates in Drupal database via drush:
4. Repeat installing of Taxonomy updates:
drush updb
with output:
After this step - the fatal error on taxonomy overview page is disappear, and seems all works well on my site without any errors and notices!
Comment #66
NiklanLooks like we have two different problems with this update, which results in the same problems:
1. The update fails to apply if terms have NULL status. Which will stop update in the middle of the process, as a result, tables are messed up.
2. The update fails to apply if there is a lot of terms and it falls into server restrictions and timeouts, which will end up with broken tables.
The first problem can be solved by code as an example see #63.
The second problem heavily depends on a server where the update is executed and it limits. I guess there is nothing we can do from the code. I think it is good to write about how to solve the problem if it happens. The solution described in #65.
Comment #67
ainsofs CreditAttribution: ainsofs as a volunteer commented#65 worked for me. ie increasing timeout on mysql
Comment #68
nikolakakis CreditAttribution: nikolakakis commentedFollowing #65 worked for me as well. Thank you.
Comment #69
MurzNiklan, yes, we have different source of same problem, but with same error output :) So let's fix your problem with
status = NULL
in this issue, and with timeout errors - in my issue #3060639: Fatal error on Taxonomy overview page after upgrade Drupal from 8.6 to 8.7Comment #70
sgurlt CreditAttribution: sgurlt as a volunteer and at Bright Solutions GmbH commentedWhile updating another project from 8.6.x to 8.7.3, I have faced the error:
Integrity constraint violation: 1048 Column 'name' cannot be null:
During my investigation I have found out that in the table
taxonomy_term_data
data existed for taxonomy terms, which did not exist in the tabletaxonomy_term_field_data
. Please don't ask me how that happened ...So I've written a small cleanup script, maybe someone else could us it:
Comment #71
milopca CreditAttribution: milopca commented@sgurlt the same happens to me with the column name.
Your script works like a champ. Thanks!
Comment #72
jbfelix CreditAttribution: jbfelix as a volunteer commentedHow to run this script ?
I have created a php file, but i get the error "Uncaught Error: Class 'Drupal' not found in... myfile.php"
Any help ?
Comment #73
Jancy Christopher CreditAttribution: Jancy Christopher commentedHi All,
On upgrading drupal core from 8.6.17 to 8.7.4 on drush updb I am getting the below error.
Comment #74
cilefen CreditAttribution: cilefen commentedComment #75
Niklan@jbfelix
drush scr myfile.php
Comment #76
divbox CreditAttribution: divbox commented#65 worked for me.
i had to remove two additional tables
taxonomy_term_r__*
thanks!
Comment #77
Syntapse CreditAttribution: Syntapse commentedsubscribing. i've reverted to 8.6.x because updated (8.7) site is unusable and it seems too risky to rely on a patch to fix.
are there any updates on integrating a fix into official 8.7.x release so it works without patches?
thanks
Comment #78
catchWe just committed #3066439: Stop invoking pre-save methods in EntityStorageInterface::restore() to 8.7.x, and it will be in the next patch release. This will help sites experiencing timeouts during the update which seems to be the cause of a lot of the reports here. It would be useful if people experiencing problems here could test the latest dev of 8.7 on their upgrade path to see if it resolves the issue for you (obviously best to test on a not-upgraded 8.6 database).
Sites with corrupted taxonomy term data on 8.6.x (i.e. records in
taxonomy_term_data
but nottaxonomy_term_field_data
) won't be helped by that change, and will need something like the clean-up script in #70.We can add a hook_requirements() to detect this condition and inform site administrators that they need to fix the data prior to update, this would be similar to what we added in #3052147: comment_update_8701 fails if there are comments without field_name.
#3056543: taxonomy_post_update_make_taxonomy_term_revisionable() and the menu link content equivalent fail when entities have no default translation would be the place to work on adding that hook_requirements() check.
Comment #79
James T CreditAttribution: James T commentedI upload my files through FTP (no git) and after reading #15 I fixed it by updating from drupal-8.6.10, to drupal-8.6.17, and then updating to drupal-8.7.5.
This is the issue I received after trying to update from 8.6.10 to 8.7.5 directly:
"taxonomy module Update #8701 SqlContentEntityStorage.php taxonomy_term__parent' doesn't exist"
I have a host using a shared server with mainly FTP, MyPHPAdmin and the standard control panel access. I wanted to share in case my experience helps someone else.
Comment #80
Syntapse CreditAttribution: Syntapse commentedThe cleanup script has introduced more problems than it fixes on my system. Please can you advise us when a working upgrade path is available from 8.6.x to 8.7.5+. I see this is still a critical issue after 3 months if its not yet available is there any idea of timescales for integration into the main release.
Thanks
Comment #81
catch@Syntapse this is a support issue for people experiencing problems with the update. There are other bug reports against core which have been fixed already since 8.7.0, such as #3066439: Stop invoking pre-save methods in EntityStorageInterface::restore() which will be in the next patch release.
Comment #82
buuza CreditAttribution: buuza commentedHi All,
Trying to update core from 8.6.16 -> 8.7.5 and i'm running into this issue:
Comment #83
catch@buuza: Can you re-test with Drupal 8.7.6? At least one problem with this update has been fixed by that release, but if you're able to reproduce the error even with that version, it might help us narrow down what else could be going on.
Comment #84
Adam_MoulsdaleI am receiving an issue updating core to 8.7 with taxonomy terms - it isn't exactly the same issue as the original, so should I create a new ticket?
I don't have revision tables so I can't follow comment #65 - but as I said, it is a different error.
Does anyone have an idea how to fix this?
Happy to create a new ticket if needs be, but help would be appreciated.
Thanks.
Comment #85
afeijoI fixed my problem which is the error of this issue with 3 sql commands:
First I investigated all related missing tid, off course, and all were old unimportant records. The revision for menu doesn't matter for my case too.
Comment #86
Adam_MoulsdaleCreated a separate issue for my error above. #3075774: Consider replacing EntityLastInstalledSchemaRepositoryInterface with EntityFieldManager in taxonomy_post_update_make_taxonomy_term_revisionable
Comment #87
vuilComment #88
vuilComment #89
Nrp CreditAttribution: Nrp commentedAny Update on this?
I am unable to upgrade from Drupal 8.6.15 to 8.7.5. When I try to run "drush updb" this is what I am getting:
[notice] Update started: taxonomy_post_update_make_taxonomy_term_revisionable
> [error] Drupal\Core\Database\DatabaseExceptionWrapper: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'DBNAME.tmp_b912b4taxonomy_term__parent' doesn't exist: INSERT INTO {tmp_b912b4taxonomy_term__parent} (entity_id, revision_id, bundle, delta, langcode, parent_target_id) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5); Array
> (
> [:db_insert_placeholder_0] => 1
> [:db_insert_placeholder_1] => 1
> [:db_insert_placeholder_2] => tags
> [:db_insert_placeholder_3] => 0
> [:db_insert_placeholder_4] => en
> [:db_insert_placeholder_5] => 0
> )
> in Drupal\Core\Entity\Sql\SqlContentEntityStorage->saveToDedicatedTables() (line 1415 of /web/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php).
> [error] The entity update process failed while processing the entity type taxonomy_term, ID: 1.
> [error] Update failed: taxonomy_post_update_make_taxonomy_term_revisionable
[error] Update aborted by: taxonomy_post_update_make_taxonomy_term_revisionable
[error] Finished performing updates.
Also with Drupal 8.7.5 I am unable to create/edit/list Taxonomy Terms. When I try to do that I am getting this:
Drupal\Core\Entity\Sql\SqlContentEntityStorageException: Column information not available for the 'parent' field. in Drupal\Core\Entity\Sql\DefaultTableMapping->getFieldColumnName() (line 430 of /web/core/lib/Drupal/Core/Entity/Sql/DefaultTableMapping.php).
any thoughts on what is causing these issues and how to fix them?
Thanks.
Comment #90
catch@Nrp https://www.drupal.org/project/drupal/releases/8.7.7 was released a couple of weeks ago and includes several upgrade path fixes. Please ensure when you upgrade, you do so from your original 8.6.15 database, rather than trying to re-run updates on a partially updated 8.7.7 database.
After that, if you're still getting the same error, please report back here - the specific error you're getting is different to most of the ones other people reported.
Comment #91
Nrp CreditAttribution: Nrp commentedThanks @catch for replying. I don't have access to original 8.6.15 database. Update was done few months back. I noticed the bug recently and after digging into it I found what's actually causing issues. is there any workaround to fix things with partially updated 8.7.7 database?
Comment #92
heni_deepak CreditAttribution: heni_deepak commentedMost Simple way to remove this error. try something new with me. First, get back up and do the same as before after uncheck revision option in taxonomy. clear caches and upgrade code by command line.
on this way when you upgrade this table dependency was removed already.
Comment #93
Nrp CreditAttribution: Nrp commented@heni_deepak I am not seeing "uncheck revision option in taxonomy". not exactly sure where I should be unchecking that option?
Comment #94
swetaranjan CreditAttribution: swetaranjan commented@Nrp Did you find the checkbox for 'unchecking revision option in taxonomy'?
Comment #95
Nrp CreditAttribution: Nrp commented@swetaranjan no.
Comment #96
heni_deepak CreditAttribution: heni_deepak commented@Nrp content-type "Entity reference" create a revision taxonomy for the whole content type.
find the content type, Where use "Entity reference" and uncheck revision on particular content type and check.
like if i have automobile content type and also have a taxonomy automobile and when i have add Entity reference "taxonomy automobile" for automobile content type. then revision table add Entity reference value.
Comment #97
heni_deepak CreditAttribution: heni_deepak commentedComment #98
vuilIt seems that the issue can not be Fixed. Revert the status back to Needs work.
Comment #99
vibrasphere CreditAttribution: vibrasphere commentedDeleting the default Tags vocabulary solved the issue for us. (the only vocab available on the site and not used)
Comment #100
plach@vibrasphere:
Did it contain any existing tag or was it empty?
Comment #101
vibrasphere CreditAttribution: vibrasphere commentedCan't remember now, probably empty because like I said never used. But we did get same exact error like posted here "The entity update process failed while processing the entity type taxonomy_term, ID: 2." etc. when trying to update manually or via Drush.
Comment #102
vuil@plach @vibrasphere
I confirm that the issue exists when we have taxonomies with parent.
Comment #103
aperedos CreditAttribution: aperedos commentedI have the same issue,
I have tried to upgrade 8.6.15 to 8.7.8 with composer and i had the same error Drupal\Core\Database\IntegrityConstraintViolationException: SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'name' cannot be null
I have tested a lot of patches, and remove tables...but it still not working.
Thanks,
Comment #104
aperedos CreditAttribution: aperedos commentedFinally i could resolve the problem with the comment #70.
1- drush php-eval '$database = \Drupal::database();
$term_storage = \Drupal::entityTypeManager()->getStorage("taxonomy_term");
$results = $database
->select("taxonomy_term_data", "ttd")
->fields("ttd", ["tid"])
->execute()
->fetchAllKeyed();
foreach($results as $id => $result) {
$results_field_data = $database
->select("taxonomy_term_field_data", "ttfd")
->condition("ttfd.tid", $id)
->fields("ttfd", ["tid"])
->execute()
->fetchAllKeyed();
if (empty($results_field_data)) {
$term = $term_storage->load($id);
$term->delete();
echo "Deleted term" . $id . PHP_EOL;
}
}'
2 - drush updb -y
Comment #105
james.williams CreditAttribution: james.williams at ComputerMinds commentedI ran into the same issue as in comment 86, where a database error is thrown because the table doesn't exist.
I suspect that the suggested fix in #3075774: Consider replacing EntityLastInstalledSchemaRepositoryInterface with EntityFieldManager in taxonomy_post_update_make_taxonomy_term_revisionable would resolve the issue for me, and possibly for many others here who have mismatches between their current field config and their recorded last installed schema. This was why I ran into the error, because the UUID for some of my fields in the last_installed_schema.repository did not match the UUIDs that my fields actually had.
(This was probably due to some unwise configuration management from a long time ago in the project's lifetime, which used to ignore UUIDs to allow updating config rather than deleting & re-creating. I believe the contrib config_update may facilitate that kind of thing too? Our tool built on the back of that.)
As I'd identified the very specific bit of my config that didn't match what was recorded as being last installed, I wrote an update hook to surgically fix that:
But I can imagine the more general fix from #3075774-4: Consider replacing EntityLastInstalledSchemaRepositoryInterface with EntityFieldManager in taxonomy_post_update_make_taxonomy_term_revisionable might be more generally useful for more people here.
Comment #107
Tentaculitis CreditAttribution: Tentaculitis commentedWas running into an error while running drush updb. Error is detailed in the code snippet below.
Column default_langcode in table taxonomy_term_field_data had 0 values so I updated them all to 1 as advised in #27
To update values I used:
drush sql-query "update taxonomy_term_field_data set default_langcode=1"
Updb command worked fine afterwards.
Comment #108
dpagini CreditAttribution: dpagini as a volunteer commentedI am facing issues with this post_update hook, but my problems are differing from most of the posts in this thread. I have just become the maintainer of an existing site that uses the drupaldeploy.org suite (multiversion, workspace, deploy, replication, etc). This site is on an early 8.6 release and badly in need of an update. When I get to this post_update hook, I enter an infinite loop, and the update will not finish. I am slightly stumped on what to do here...
So here is a description of my problem... this all comes from SqlFieldableEntityTypeListenerTrait::copyData(), and is even "predicted" via a comment in that class. I'm wondering if there can be tweaks to accommodate this problem? So when this post_update is run, there's a SQL query that goes directly against the table to get revisions, and gets a batch of results, let's call it 2000 rows. Now I have 2 workspaces, so half of my current revisions are in workspace 1, and there is a matching revision in workspace 2 when they got migrated there. So this update hook works fine for my default workspace. When it encounters a revision in workspace 2, about 1000 entries, the call to
$this->storage->loadMultipleRevisions($entity_identifiers)
around line ~176 will not return any revisions, since via the multiversion/workspace module, they are excluded from entity loads/queries. When the$entities
variable is empty, the update hook will enter an infinite loop. I think this can probably be addressed... but looking for help.ideas/suggestions on what could change here?I believe "multiversion" has made my taxonomy terms revisionable before core got around to it, so I am also wondering if this hook is needed? If not, I'm wondering if there is convenient way to skip this update...? I tried disabling the hook in a standard update hook, but when I run `$ drush updb` (our standard release process), it collects both my update hook to disable AND this hook that I'm disabling, and runs them all at once. Any thoughts?
Comment #109
janmejaya CreditAttribution: janmejaya commentedI faced the same issue but before executing config-import I executed the below query to fix the issue.
UPDATE taxonomy_term_field_data SET default_langcode = '1' WHERE taxonomy_term_field_data.tid = 1 AND taxonomy_term_field_data.langcode = "en";
Comment #110
vuilComment #111
subson CreditAttribution: subson as a volunteer commentedI didn't get the same integrity constraint error but "taxonomy_post_update_make_taxonomy_term_revisionable" function fails for me as well when trying to upgrade from 8.6.x to 8.7.x and the problem seems to be related to the field definitions stored in key_value table.
Sometimes field definitions are changed in config/ but they are not get copied over to key_value table collection - 'entity.storage_schema.sql' individual field definitions, so when you are on drupal 8.6 or lower run
drush entup
first to update field definitions or fix the problem on lower version first, and then switch to 8.7 and run drush updates (drush updb) to see if that fixes the issues for you.Comment #112
catchThis should now have been fixed via a combination of #3052318: Update from 8.6 to 8.7 fails due to corrupt menu_link_content or taxonomy_term entity data, #3056539: Updating an entity type from non-revisionable to revisionable fails if it has non-revisionable fields stored in dedicated tables, and #3056543: taxonomy_post_update_make_taxonomy_term_revisionable() and the menu link content equivalent fail when entities have no default translation.
New releases of 8.7, 8.8 and the 8.9 beta will be released next week, which should include fixes for all three issues. Downgrading but leaving this open until those releases are out, after which it would be great if people with this issue could retest their updates.
Comment #113
smanhoff CreditAttribution: smanhoff commentedStill experiencing this issue after updating to 8.8.5 from 8.6.18.
Updates fail on:
While also experiencing https://www.drupal.org/project/drupal/issues/3040129:
Answer #111 got me looking in the right direction.
After applying following update_hook, above updates run without issues.
Comment #117
cilefen CreditAttribution: cilefen commentedI am closing this support request because there have been no recent comments.