Cannot update to 8.7.0 because of taxonomy_post_update_make_taxonomy_term_revisionable

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

I also encountered the following error while I was trying to update my site from 8.6.15 to 8.7.0 although my case is related to this issue:

taxonomy module

Update make_taxonomy_term_revisionable

Failed: Drupal\Core\Entity\EntityStorageException: The entity update process failed while processing the entity type taxonomy_term, ID: 2. in Drupal\Core\Entity\Sql\SqlContentEntityStorageSchema->copyData() (line 216 of /var/www/html/d8/core/lib/Drupal/Core/Entity/Sql/SqlFieldableEntityTypeListenerTrait.php).

Besides the above error, also Recent log messages:

Drupal\Core\Database\IntegrityConstraintViolationException: SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'status' cannot be null: INSERT INTO {tmp_f5ed30taxonomy_term_field_data} (tid, revision_id, vid, langcode, name, description__value, description__format, weight, changed, default_langcode, content_translation_source, content_translation_outdated, content_translation_uid, content_translation_created, 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, :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); Array ( [:db_insert_placeholder_0] => 2 [:db_insert_placeholder_1] => 2 [:db_insert_placeholder_2] => tags [:db_insert_placeholder_3] => en [:db_insert_placeholder_4] => Linux [:db_insert_placeholder_5] => [:db_insert_placeholder_6] => [:db_insert_placeholder_7] => 0 [:db_insert_placeholder_8] => 1460267719 [:db_insert_placeholder_9] => 1 [:db_insert_placeholder_10] => und [:db_insert_placeholder_11] => 0 [:db_insert_placeholder_12] => [:db_insert_placeholder_13] => [:db_insert_placeholder_14] => [:db_insert_placeholder_15] => 1 [:db_insert_placeholder_16] => 2 [:db_insert_placeholder_17] => 2 [:db_insert_placeholder_18] => tags [:db_insert_placeholder_19] => ja [:db_insert_placeholder_20] => Linux [:db_insert_placeholder_21] => [:db_insert_placeholder_22] => [:db_insert_placeholder_23] => 0 [:db_insert_placeholder_24] => 1473906837 [:db_insert_placeholder_25] => 0 [:db_insert_placeholder_26] => en [:db_insert_placeholder_27] => 0 [:db_insert_placeholder_28] => 1 [:db_insert_placeholder_29] => 1460329597 [:db_insert_placeholder_30] => [:db_insert_placeholder_31] => ) in Drupal\Core\Database\Connection->handleQueryException() (line 689 of /var/www/html/d8/core/lib/Drupal/Core/Database/Connection.php).

Screenshot:

Database record in taxonomy_term_field_data:

MariaDB [XXXXX]> SELECT * FROM `taxonomy_term_field_data` WHERE `tid`=2;
+-----+------+----------+-------+--------------------+---------------------+--------+------------+------------------+----------------------------+------------------------------+-------------------------+-----------------------------+--------+
| tid | vid  | langcode | name  | description__value | description__format | weight | changed    | default_langcode | content_translation_source | content_translation_outdated | content_translation_uid | content_translation_created | status |
+-----+------+----------+-------+--------------------+---------------------+--------+------------+------------------+----------------------------+------------------------------+-------------------------+-----------------------------+--------+
|   2 | tags | en       | Linux | NULL               | NULL                |      0 | 1460267719 |                1 | und                        |                            0 |                    NULL |                        NULL |   NULL |
|   2 | tags | ja       | Linux | NULL               | NULL                |      0 | 1473906837 |                0 | en                         |                            0 |                       1 |                  1460329597 |   NULL |
+-----+------+----------+-------+--------------------+---------------------+--------+------------+------------------+----------------------------+------------------------------+-------------------------+-----------------------------+--------+
2 rows in set (0.00 sec)

@yas, in your case it seems like the data in taxonomy_term_field_data is corrupted somehow, the status 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 the status column and then try to re-run the updates.

@amateescu,

Thank you for your advice. Yes, I found that and updated all the records in that table with the value 1 for the status column.

As a result, it was successful (thanks!),

The following updates returned messages:

taxonomy module
Update make_taxonomy_term_revisionable
- Taxonomy terms have been converted to be revisionable.

menu_link_content module
Update make_menu_link_content_revisionable
- Custom menu links have been converted to be revisionable.

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

Drupal\Core\Database\DatabaseExceptionWrapper: 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->saveToSharedTables() (line 1052 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 the revision_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?

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

Hi,

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.

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

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

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

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

Hi 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

Same issue for me

Same 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:

 Do you wish to run the specified pending updates? (yes/no) [yes]:
 >
>  [notice] Update started: taxonomy_post_update_make_taxonomy_term_revisionable
>  [error]  Drupal\Core\Database\IntegrityConstraintViolationException: SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'status' cannot be null: INSERT INTO {tmp_0bd49ftaxonomy_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] => 3
>     [:db_insert_placeholder_1] => 3
>     [:db_insert_placeholder_2] => product_categories
>     [:db_insert_placeholder_3] => en
>     [:db_insert_placeholder_4] => Clothing
>     [:db_insert_placeholder_5] =>
>     [:db_insert_placeholder_6] =>
>     [:db_insert_placeholder_7] => 0
>     [:db_insert_placeholder_8] => 1532099157
>     [:db_insert_placeholder_9] => 1
>     [:db_insert_placeholder_10] =>
>     [:db_insert_placeholder_11] => 1
> )
>  in Drupal\Core\Database\Connection->handleQueryException() (line 689 of /var/www/html/drupal/web/core/lib/Drupal/Core/Database/Connection.php).
>  [error]  The entity update process failed while processing the entity type taxonomy_term, ID: 3.
>  [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.

Then I selected data where status = null and got nothing back:

MariaDB [nfb_prod_drupal]> select * from taxonomy_term_field_data where status = null;
Empty set (0.00 sec)

@m-si which table had the broken data?

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

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

Same issue here.

From 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

I have same error.
When i try update from update.php

taxonomy module

Update make_taxonomy_term_revisionable

Taxonomy terms have been converted to be revisionable.
Failed: Drupal\Core\Entity\EntityStorageException: Exception thrown while performing a schema update. Cannot rename tmp_30f55ataxonomy_term_revision to taxonomy_term_revision: table taxonomy_term_revision already exists. in Drupal\Core\Entity\Sql\SqlContentEntityStorage->wrapSchemaException() (line 1611 of \some-dir\web\core\lib\Drupal\Core\Entity\Sql\SqlContentEntityStorage.php).

If i try update from drush updb

  taxonomy   make_taxonomy_term_revisionable       post-update   Update taxonomy terms to be revisionable.
  taxonomy   remove_hierarchy_from_vocabularies    post-update   Remove the 'hierarchy' property from vocabularies.
  views      exposed_filter_blocks_label_display   post-update   Update exposed filter blocks label display to be disabled.
  views      make_placeholders_translatable        post-update   Rebuild cache to allow placeholder texts to be translatable.

>  [error]  Exception thrown while performing a schema update. Cannot rename tmp_744a50taxonomy_term_revision to taxonomy_term_revision: table taxonomy_term_revision already exists.
>  [error]  Update failed: taxonomy_post_update_make_taxonomy_term_revisionable

Some One fix this ?

Same issue when updating (without drush)

I 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

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

[error]  Drupal\Core\Database\IntegrityConstraintViolationException: SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'name' cannot be null: INSERT INTO {tmp_2bdf31taxonomy_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] => 423
>     [:db_insert_placeholder_1] => 423
>     [:db_insert_placeholder_2] => vocab_component_type
>     [:db_insert_placeholder_3] => en
>     [: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
> )

Do anyone know if we can skip this, or any workaround?

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

thank 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:

select name from taxonomy_term_field_data where tid=423 order by 1 limit 25;
Empty set (0.00 sec)

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

@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 in taxonomy_term_data but no corresponding record in taxonomy_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.

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

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

You can remove orphan records from a SQL client. Backup everything first! :)

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

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

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

8.7.x a bunch of fewie.. this is the 3rd core bug im facing with this update.

$ drush updb -y
...
...
 [notice] Update started: taxonomy_post_update_make_taxonomy_term_revisionable
 [notice] Taxonomy terms have been converted to be revisionable.
 [ok] Update completed: taxonomy_post_update_make_taxonomy_term_revisionable
 [notice] Update started: taxonomy_post_update_make_taxonomy_term_revisionable
 [notice] Taxonomy terms have been converted to be revisionable.
 [ok] Update completed: taxonomy_post_update_make_taxonomy_term_revisionable
 [notice] Update started: taxonomy_post_update_make_taxonomy_term_revisionable
 [notice] Taxonomy terms have been converted to be revisionable.
 [ok] Update completed: taxonomy_post_update_make_taxonomy_term_revisionable
 [notice] Update started: taxonomy_post_update_make_taxonomy_term_revisionable
 [notice] Taxonomy terms have been converted to be revisionable.
 [ok] Update completed: taxonomy_post_update_make_taxonomy_term_revisionable
 [notice] Update started: taxonomy_post_update_make_taxonomy_term_revisionable
 [notice] Taxonomy terms have been converted to be revisionable.
 [ok] Update completed: taxonomy_post_update_make_taxonomy_term_revisionable
 [notice] Update started: taxonomy_post_update_make_taxonomy_term_revisionable
 [error]  Exception thrown while performing a schema update. Cannot rename tmp_0b7c89taxonomy_term_revision to taxonomy_term_revision: table taxonomy_term_revision already exists. 
 [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. 

Error im seeing is that it cant rename the schema.

The 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

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

Post updating layout_builder                                                                       [ok]
Failed: Drupal\Core\Entity\Query\QueryException: No revision table for taxonomy_term, invalid      [error]
query. in Drupal\Core\Entity\Query\Sql\Query->prepare() (line 98 of
/Users/andy/www/segd8.boi/public/core/lib/Drupal/Core/Entity/Query/Sql/Query.php).

After applying the patch, my update completes and the revision tables are created.

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

Thanks @amateescu solution #8 worked perfectly.

@plach:

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.

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

I'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:

[error]  Drupal\Core\Database\IntegrityConstraintViolationException: SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'name' cannot be null: INSERT INTO {tmp_b3edd9taxonomy_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] => zxx
   [: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 /mnt/www/html/optivode42/docroot/core/lib/Drupal/Core/Database/Connection.php). [7.12 sec, 45.21 MB]
[error]  The entity update process failed while processing the entity type taxonomy_term, ID: 1. [8.17 sec, 45.24 MB]
[error]  Update failed: taxonomy_post_update_make_taxonomy_term_revisionable [8.17 sec, 38.9 MB]

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.

We 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 (

My 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:

Drupal\Core\Entity\EntityStorageException: The entity update process failed while processing the entity type taxonomy_term, ID: 5. in Drupal\Core\Entity\Sql\SqlContentEntityStorageSchema->copyData() (line 216 of web/core/lib/Drupal/Core/Entity/Sql/SqlFieldableEntityTypeListenerTrait.php).

Drupal\Core\Database\DatabaseExceptionWrapper: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'tmp_db11dbtaxonomy_term_revision__content_type' doesn't exist: INSERT INTO {tmp_db11dbtaxonomy_term_revision__content_type}

My solution was to make those fields revisionable before the update, and the update itself ran without errors.

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

Hi,

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 ?

Hi,

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

I 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):

  $definition_update_manager = \Drupal::entityDefinitionUpdateManager();
  $last_installed_schema_repository = \Drupal::service('entity.last_installed_schema.repository');

  $entity_type = $definition_update_manager->getEntityType('taxonomy_term');
  $field_storage_definitions = $last_installed_schema_repository->getLastInstalledFieldStorageDefinitions('taxonomy_term');
  $name_definition = $field_storage_definitions['name'];
  $name_definition->setSetting('max_length', 2048);
  $definition_update_manager->updateFieldableEntityType($entity_type, $field_storage_definitions, $sandbox);

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.

Hi,

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.

Hi,

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.

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

@arafalov, you mention a module and a tool I have never use, do you care to explain in more detail?

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

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

Now that all the specific issues are split into dedicated bug reports, I'm going to move this to a support request for now.

This 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

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

I 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 a drush 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 :)

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

/**
 * Sets published status for terms, where "status" is NULL.
 */
function MYMODULE_update_8601(&$sandbox) {
  // There can be terms with NULL status after "taxonomy_update_8601".
  // Force them to be published.
  /** @var \Drupal\taxonomy\TermStorageInterface $term_storage */
  $term_storage = \Drupal::entityTypeManager()->getStorage('taxonomy_term');

  // Prepare sandbox.
  if (!isset($sandbox['total'])) {
    $terms_with_null_status = $term_storage
      ->getQuery()
      ->notExists('status')
      ->count()
      ->execute();

    $sandbox['total'] = $terms_with_null_status;
    $sandbox['current'] = 0;
  }

  // Do not continue if no broken terms.
  if (empty($sandbox['total'])) {
    $sandbox['#finished'] = 1;

    return t('No terms with NULL status is found.');
  }

  $limit = 50;

  $term_ids = $term_storage
    ->getQuery()
    ->notExists('status')
    ->range($sandbox['current'], $limit)
    ->execute();
  $term_entities = $term_storage->loadMultiple($term_ids);
  /** @var \Drupal\taxonomy\TermInterface $term */
  foreach ($term_entities as $term) {
    $term->set('status', TRUE);
    $term->save();

    $sandbox['current']++;
  }

  $sandbox['#finished'] = ($sandbox['current'] / $sandbox['total']);

  return t('@count terms statuses processed.', ['@count' => $sandbox['current']]);
}

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.

Seems 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:

• taxonomy_term_data: revision_id
• taxonomy_term_field_data: revision_id, revision_translation_affected

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:

ALTER TABLE `taxonomy_term_data` 
ADD `revision_id` INT(10) UNSIGNED NOT NULL AFTER `tid`,
ADD UNIQUE `taxonomy_term__revision_id` (`revision_id`); 

UPDATE `taxonomy_term_data` SET `revision_id` = `tid` WHERE 1;

ALTER TABLE `taxonomy_term_field_data`
ADD `revision_id` INT(10) UNSIGNED NOT NULL AFTER `tid`,
ADD `revision_translation_affected` TINYINT(4) NULL DEFAULT NULL AFTER `langcode`,
ADD UNIQUE `taxonomy_term__revision_id` (`revision_id`); 

UPDATE `taxonomy_term_field_data`
SET `revision_id` = `tid`, `revision_translation_affected` = 1
WHERE 1;

And Table Mapping is not updated to, so I manually fill up it with right values:

  public function getTermIdsWithPendingRevisions() {
    $table_mapping = $this->getTableMapping();
    $id_field = $table_mapping->getColumnNames($this->entityType->getKey('id'))['value'];
    $revision_field = $table_mapping->getColumnNames($this->entityType->getKey('revision'))['value'];
    $rta_field = $table_mapping->getColumnNames($this->entityType->getKey('revision_translation_affected'))['value'];
    $langcode_field = $table_mapping->getColumnNames($this->entityType->getKey('langcode'))['value'];
    $revision_default_field = $table_mapping->getColumnNames($this->entityType->getRevisionMetadataKey('revision_default'))['value'];

    $revision_field = 'revision_id';
    $revision_default_field = 'revision_default';
    $revision_table = 'taxonomy_term_revision';
    $revision_data_table = 'taxonomy_term_field_revision';
    $rta_field = 'revision_translation_affected';

    $query = $this->database->select($revision_data_table, 'tfr');
    $query->fields('tfr', [$id_field]);
    $query->addExpression("MAX(tfr.$revision_field)", $revision_field);

    // $query->join($this->getRevisionTable(), 'tr', "tfr.$revision_field = tr.$revision_field AND tr.$revision_default_field = 0");
    $query->join($revision_table, 'tr', "tfr.$revision_field = tr.$revision_field AND tr.$revision_default_field = 0");

    $inner_select = $this->database->select($revision_data_table, 't');
    $inner_select->condition("t.$rta_field", '1');
    $inner_select->fields('t', [$id_field, $langcode_field]);
    $inner_select->addExpression("MAX(t.$revision_field)", $revision_field);
    $inner_select
      ->groupBy("t.$id_field")
      ->groupBy("t.$langcode_field");

    $query->join($inner_select, 'mr', "tfr.$revision_field = mr.$revision_field AND tfr.$langcode_field = mr.$langcode_field");

    $query->groupBy("tfr.$id_field");

    return $query->execute()->fetchAllKeyed(1, 0);
  }

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 with devel_entity_updates module I can't update tables because of error:

In DevelEntityDefinitionUpdateManager.php line 169:
                                                                                         
  The entity schema update for the taxonomy_term entity type requires a data migration.  

I 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:

[mysqld]
wait_timeout = 600
connect_timeout = 600

2. Manually delete sql-tables from database (if already exists):

taxonomy_term_revision
taxonomy_term_field_revision
taxonomy_term_revision__parent
taxonomy_term_revision__*

3. Remove info about installed taxonomy updates in Drupal database via drush:

drush eval "drupal_set_installed_schema_version('taxonomy', 8701);"

drush eval '$updates = \Drupal::keyValue("post_update")->get("existing_updates");
if (($key = array_search("taxonomy_post_update_make_taxonomy_term_revisionable", $updates)) !== false) {
   unset($updates[$key]);
}
\Drupal::keyValue("post_update")->set("existing_updates", $updates);'

4. Repeat installing of Taxonomy updates:
drush updb
with output:

$ drush updb
 ---------- ------------------ --------------- -------------------------------- 
  Module     Update ID          Type            Description                     
 ---------- ------------------ --------------- -------------------------------- 
  taxonomy   8702               hook_update_n   Sets published status for       
                                                terms, where "status" is NULL.  
                                                                                
  taxonomy   make_taxonomy_te   post-update     Update taxonomy terms to be     
             rm_revisionable                    revisionable.                   
 ---------- ------------------ --------------- -------------------------------- 


 Do you wish to run the specified pending updates? (yes/no) [yes]:
 > 

>  [notice] Update started: taxonomy_update_8702
>  [notice] No terms with NULL status is found.
>  [notice] Update completed: taxonomy_update_8702
>  [notice] Update started: taxonomy_post_update_make_taxonomy_term_revisionable
>  [notice] Taxonomy terms have been converted to be revisionable.
>  [notice] Taxonomy terms have been converted to be revisionable.
>  [notice] Taxonomy terms have been converted to be revisionable.
>  [notice] Taxonomy terms have been converted to be revisionable.
>  [notice] Taxonomy terms have been converted to be revisionable.
>  [notice] Taxonomy terms have been converted to be revisionable.
>  [notice] Taxonomy terms have been converted to be revisionable.
>  [notice] Taxonomy terms have been converted to be revisionable.
>  [notice] Taxonomy terms have been converted to be revisionable.
>  [notice] Taxonomy terms have been converted to be revisionable.
>  [notice] Taxonomy terms have been converted to be revisionable.
>  [notice] Update completed: taxonomy_post_update_make_taxonomy_term_revisionable
 [success] Finished performing updates.

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!

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

#65 worked for me. ie increasing timeout on mysql

Following #65 worked for me as well. Thank you.

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

While 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 table taxonomy_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:

$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;
  }
}

@sgurlt the same happens to me with the column name.
Your script works like a champ. Thanks!

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

Hi All,

On upgrading drupal core from 8.6.17 to 8.7.4 on drush updb I am getting the below error.

[notice] Update started: system_update_8701
>  [notice] Update completed: system_update_8701
>  [notice] Update started: comment_update_8700
>  [notice] Update completed: comment_update_8700
>  [notice] Update started: media_library_update_8701
>  [notice] Update completed: media_library_update_8701
>  [notice] Update started: system_update_8702
>  [notice] Update completed: system_update_8702
>  [notice] Update started: comment_update_8701
>  [notice] Update completed: comment_update_8701
>  [notice] Update started: file_update_8700
>  [notice] Update completed: file_update_8700
>  [notice] Update started: media_update_8700
>  [notice] Update completed: media_update_8700
>  [notice] Update started: media_library_update_8702
>  [notice] Update completed: media_library_update_8702
>  [notice] Update started: node_update_8700
>  [notice] Update completed: node_update_8700
>  [notice] Update started: taxonomy_update_8701
>  [notice] Update completed: taxonomy_update_8701
>  [notice] Update started: comment_post_update_add_ip_address_setting
>  [notice] Update completed: comment_post_update_add_ip_address_setting
>  [notice] Update started: media_library_post_update_add_media_library_image_style
>  [notice] The Media Library (220x220) image style has been created successfully.
>  [notice] Update completed: media_library_post_update_add_media_library_image_style
>  [notice] Update started: media_library_post_update_display_modes
>  [notice] Media Library form and view displays have been created for the following media types: Audio, Document, Image, Video.
>  [notice] Update completed: media_library_post_update_display_modes
>  [notice] Update started: media_library_post_update_table_display
>  [notice] Update completed: media_library_post_update_table_display
>  [notice] Update started: media_post_update_enable_standalone_url
>  [notice] Update completed: media_post_update_enable_standalone_url
>  [notice] Update started: menu_link_content_post_update_make_menu_link_content_revisionable
>  [notice] Custom menu links have been converted to be revisionable.
>  [notice] Update completed: menu_link_content_post_update_make_menu_link_content_revisionable
>  [notice] Update started: system_post_update_add_expand_all_items_key_in_system_menu_block
>  [notice] Update completed: system_post_update_add_expand_all_items_key_in_system_menu_block
>  [notice] Update started: system_post_update_clear_menu_cache
>  [notice] Update completed: system_post_update_clear_menu_cache
>  [notice] Update started: taxonomy_post_update_make_taxonomy_term_revisionable
> Error: Call to a member function setRevisionable() on null in /var/www/cgicom/docroot/core/modules/taxonomy/taxonomy.post_update.php on line 170 #0 /var/www/cgicom/vendor/drush/drush/src/Commands/core/UpdateDBCommands.php(308): taxonomy_post_update_make_taxonomy_term_revisionable(Array)
> #1 /var/www/cgicom/vendor/drush/drush/includes/batch.inc(251): Drush\Commands\core\UpdateDBCommands::updateDoOnePostUpdate('taxonomy_post_u...', Object(DrushBatchContext))
> #2 /var/www/cgicom/vendor/drush/drush/includes/batch.inc(196): _drush_batch_worker()
> #3 /var/www/cgicom/vendor/drush/drush/includes/batch.inc(99): _drush_batch_command('17')
> #4 /var/www/cgicom/vendor/drush/drush/src/Commands/core/UpdateDBCommands.php(166): drush_batch_command('17')
> #5 [internal function]: Drush\Commands\core\UpdateDBCommands->process('17', Array)
> #6 /var/www/cgicom/vendor/consolidation/annotated-command/src/CommandProcessor.php(257): call_user_func_array(Array, Array)
> #7 /var/www/cgicom/vendor/consolidation/annotated-command/src/CommandProcessor.php(212): Consolidation\AnnotatedCommand\CommandProcessor->runCommandCallback(Array, Object(Consolidation\AnnotatedCommand\CommandData))
> #8 /var/www/cgicom/vendor/consolidation/annotated-command/src/CommandProcessor.php(178): Consolidation\AnnotatedCommand\CommandProcessor->validateRunAndAlter(Array, Array, Object(Consolidation\AnnotatedCommand\CommandData))
> #9 /var/www/cgicom/vendor/consolidation/annotated-command/src/AnnotatedCommand.php(302): Consolidation\AnnotatedCommand\CommandProcessor->process(Object(Symfony\Component\Console\Output\ConsoleOutput), Array, Array, Object(Consolidation\AnnotatedCommand\CommandData))
> #10 /var/www/cgicom/vendor/symfony/console/Command/Command.php(255): Consolidation\AnnotatedCommand\AnnotatedCommand->execute(Object(Drush\Symfony\DrushArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
> #11 /var/www/cgicom/vendor/symfony/console/Application.php(987): Symfony\Component\Console\Command\Command->run(Object(Drush\Symfony\DrushArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
> #12 /var/www/cgicom/vendor/symfony/console/Application.php(255): Symfony\Component\Console\Application->doRunCommand(Object(Consolidation\AnnotatedCommand\AnnotatedCommand), Object(Drush\Symfony\DrushArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
> #13 /var/www/cgicom/vendor/symfony/console/Application.php(148): Symfony\Component\Console\Application->doRun(Object(Drush\Symfony\DrushArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
> #14 /var/www/cgicom/vendor/drush/drush/src/Runtime/Runtime.php(118): Symfony\Component\Console\Application->run(Object(Drush\Symfony\DrushArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
> #15 /var/www/cgicom/vendor/drush/drush/src/Runtime/Runtime.php(49): Drush\Runtime\Runtime->doRun(Array, Object(Symfony\Component\Console\Output\ConsoleOutput))
> #16 /var/www/cgicom/vendor/drush/drush/drush.php(72): Drush\Runtime\Runtime->run(Array)
> #17 /var/www/cgicom/vendor/drush/drush/includes/preflight.inc(18): require('/var/www/cgicom...')
> #18 phar:///usr/local/bin/drush/bin/drush.php(141): drush_main()
> #19 /usr/local/bin/drush(10): require('phar:///usr/loc...')
> #20 {main}
>  [warning] Drush command terminated abnormally. Check for an exit() in your Drupal site.

@jbfelix

drush scr myfile.php

#65 worked for me.

i had to remove two additional tables

taxonomy_term_r__*

thanks!

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

We 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 not taxonomy_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.

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

The 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

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

Hi All,

Trying to update core from 8.6.16 -> 8.7.5 and i'm running into this issue:

 [error]  Drupal\Core\Database\IntegrityConstraintViolationException: SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'name' cannot be null: INSERT INTO {tmp_ac3654taxonomy_term_field_data} (tid, revision_id, vid, langcode, name, description__value, description__format, weight, changed, default_langcode, rh_action, rh_redirect, rh_redirect_response, 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, :db_insert_placeholder_12, :db_insert_placeholder_13, :db_insert_placeholder_14); Array
> (
>     [:db_insert_placeholder_0] => 17
>     [:db_insert_placeholder_1] => 17
>     [:db_insert_placeholder_2] => program_type
>     [:db_insert_placeholder_3] => zxx
>     [: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] => 1
> )
>  in Drupal\Core\Database\Connection->handleQueryException() (line 689 of C:\Users\adaraev\Sites\ddev\njcudrupal8\docroot\core\lib\Drupal\Core\Database\Connection.php).
>  [error]  The entity update process failed while processing the entity type taxonomy_term, ID: 17.
>  [error]  Update failed: taxonomy_post_update_make_taxonomy_term_revisionable

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

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

>  [error]  Drupal\Core\Database\DatabaseExceptionWrapper: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'drupal.tmp_28c950taxonomy_term__48ebc0df3e' doesn't exist: INSERT INTO {tmp_28c950taxonomy_term__48ebc0df3e} (entity_id, revision_id, bundle, delta, langcode, field_hide_from_landing_page_value) 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] => 806
>     [:db_insert_placeholder_1] => 806
>     [:db_insert_placeholder_2] => themes
>     [: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 /docroot/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php). 
>  [error]  The entity update process failed while processing the entity type taxonomy_term, ID: 806. 

Does anyone have an idea how to fix this?

Happy to create a new ticket if needs be, but help would be appreciated.

Thanks.

I fixed my problem which is the error of this issue with 3 sql commands:

drop table menu_link_content_field_revision;
drop table menu_link_content_revision;
delete from taxonomy_term_data where tid not in (select tid from taxonomy_term_field_data f) limit 50;

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.

Created a separate issue for my error above. #3075774: Consider replacing EntityLastInstalledSchemaRepositoryInterface with EntityFieldManager in taxonomy_post_update_make_taxonomy_term_revisionable

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

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

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

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

@heni_deepak I am not seeing "uncheck revision option in taxonomy". not exactly sure where I should be unchecking that option?

@Nrp Did you find the checkbox for 'unchecking revision option in taxonomy'?

@swetaranjan no.

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

It seems that the issue can not be Fixed. Revert the status back to Needs work.

Deleting the default Tags vocabulary solved the issue for us. (the only vocab available on the site and not used)

@vibrasphere:

Did it contain any existing tag or was it empty?

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

@plach @vibrasphere
I confirm that the issue exists when we have taxonomies with parent.

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

Finally 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

I 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:

function MYMODULE_update_8701() {
  /** @var \Drupal\Core\Entity\EntityLastInstalledSchemaRepositoryInterface $last_installed_schema_repository */
  $last_installed_schema_repository = \Drupal::service('entity.last_installed_schema.repository');
  $last_installed_definitions = $last_installed_schema_repository->getLastInstalledFieldStorageDefinitions('taxonomy_term');

  /** @var \Drupal\Core\Entity\EntityFieldManagerInterface $field_manager */
  $field_manager = \Drupal::service('entity_field.manager');
  $current_definitions = $field_manager->getFieldStorageDefinitions('taxonomy_term');

  // Iterate over each existing field, and ensure the UUID in the last installed 
  // definition is up to date.
  foreach ($current_definitions as $field_name => $definition) {
    if (isset($last_installed_definitions[$field_name])) {
      $old_definition = $last_installed_definitions[$field_name];
      if ($old_definition instanceof \Drupal\field\Entity\FieldStorageConfig) {
        if ($last_installed_definitions[$field_name]->getUniqueStorageIdentifier() !== $definition->getUniqueStorageIdentifier()) {
          $old_definition->set('uuid', $definition->getUniqueStorageIdentifier());
        }
      }
    }
  }

  $last_installed_schema_repository->setLastInstalledFieldStorageDefinitions('taxonomy_term', $last_installed_definitions);
}

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.

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

 [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_067fdetaxonomy_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] => en
    [: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/html/monids/web/core/lib/Drupal/Core/Database/Connection.php). 
 [error]  The entity update process failed while processing the entity type taxonomy_term, ID: 1.

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

I 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";

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

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

Still experiencing this issue after updating to 8.8.5 from 8.6.18.

Updates fail on:

Update aborted by: taxonomy_post_update_make_taxonomy_term_revisionable

The entity update process failed while processing the entity type taxonomy_term, ID: 1.

While also experiencing https://www.drupal.org/project/drupal/issues/3040129:

Column not found: 1054 Unknown column 'base_table.revision_id' in 'field list': SELECT base_table.revision_id AS revision_id, base_table.id AS id

Answer #111 got me looking in the right direction.

After applying following update_hook, above updates run without issues.

function hook_update() {
  $definition_update_manager = \Drupal::entityDefinitionUpdateManager();
  $entity_types = ['menu_link_content', 'taxonomy_term'];
  foreach ($entity_types as $entity_type_id) {
    $entity_type = $definition_update_manager->getEntityType($entity_type_id);
    \Drupal::entityDefinitionUpdateManager()->installEntityType($entity_type);
    \Drupal::entityDefinitionUpdateManager()->updateEntityType($entity_type);
  }
}

I am closing this support request because there have been no recent comments.