Conflict with token_custom

Created on 8 September 2017, almost 7 years ago
Updated 28 March 2024, 5 months ago

When using token_custom, there is an error related to content_lock, making it impossible to edit custom tokens when content_lock is installed.

Uncaught PHP Exception Drupal\Core\Database\DatabaseExceptionWrapper: "SQLSTATE[HY000]: General error: 1366 Incorrect integer value: 'token_name' for column 'entity_id' at row 1: INSERT INTO {content_lock} (entity_id, entity_type, uid, timestamp) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3); Array
(
    [:db_insert_placeholder_0] => token_name
    [:db_insert_placeholder_1] => token_custom
    [:db_insert_placeholder_2] => 1
    [:db_insert_placeholder_3] => 1504878127
)
" at ./docroot/core/lib/Drupal/Core/Database/Connection.php line 685
πŸ› Bug report
Status

Needs work

Version

2.0

Component

Code

Created by

πŸ‡ΊπŸ‡ΈUnited States bdanin

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • πŸ‡ΊπŸ‡ΈUnited States smustgrave

    Wonder if still an issue on 8.x-2.x? Checked token_custom and see last commit was 2022 so still relatively active.

  • πŸ‡ΊπŸ‡ΈUnited States smustgrave

    Checking core entity_id is an int there too.

  • Status changed to Needs work 5 months ago
  • πŸ‡¬πŸ‡§United Kingdom alexpott πŸ‡ͺπŸ‡ΊπŸŒ

    So the quick fix here is to only support entity types where the ID field is an integer. Token custom uses a string ID - which is rare but not unsupported - see https://git.drupalcode.org/project/token_custom/-/blob/8.x-1.x/src/Entit...

    So the premise of the fix is correct.

    My concern on the fix is what happens when the lock table is very large. I think what we need to do is to create a temporary table that's a copy of the current table. And then make the changes to the schema, and then copy the data in from the other table, and then then drop the table. These should be separate update functions so that they can be batched nicely by the update system.

Production build 0.71.5 2024