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.
Problem/Motivation
The most recent stable release of Entity Translation uses a different i18n_mode value for translated taxonomy terms. See https://git.drupalcode.org/project/entity_translation/-/blob/7.x-1.1/ent...
This means that any user trying to migrate from an up-to-date Drupal 7 instance will lose translation data.
Steps to reproduce
- With the most recent Drupal 7 release + Entity Translation, create a vocabulary which allows its terms to be translated by entity translation.
- Try to migrate the source Drupal 7 instance (e.g. with Migrate Drupal UI)
- You'll see a logged migrate exception message thrown from the migration plugin in the IT: "No static mapping found for ''32768'' and no default value provided for destination 'language_alterable'."
- You'll see that none of the term translations are migrated (
d7_taxonomy_term_translation
migrate map table contains skipped rows only)."
Proposed resolution
Update mappings to deal with the most recent i18n_mode
.
Remaining tasks
- Patch
- Test
User interface changes
Nothing
API changes
?
Data model changes
?
Release notes snippet
Comment | File | Size | Author |
---|---|---|---|
#13 | core-fix_et_mapping_of_taxonomy_terms-3219078-13.patch | 2.63 KB | Wim Leers |
#9 | core-fix_et_mapping_of_taxonomy_terms-3219078-9.patch | 3.14 KB | huzooka |
Comments
Comment #2
huzookaComment #3
huzookaComment #4
quietone CreditAttribution: quietone as a volunteer commentedAnother good discovery. Thanks.
Can the title just be 'Add support for i18n_mode 32768 in d7_language_content_taxonomy_vocabulary_settings migration.' I am not sure that it is a regression if this mode was never handled before. Or am I missing something?
Comment #5
huzookaYou cannot migrate term translation translated with Entity Translation for a year and a half – while
language.migrate_drupal.yml
,config_translation.migrate_drupal.yml
andcontent_translation.migrate_drupal.yml
tells you that you can. I strongly believe this worked in the past, but now it doesn't. That's why I evaluate this as a regression.Unfortunately, it seems that changes made in #3022137: Update migrate fixtures for remaining active issues were (at least partially) manual edits, and the database fixture is corrupted in regards of the data structure of Entity Translation settings. Or the Entity Translation update hook is wrong?
I don't think this can be fixed manually.
I added a change to
\Drupal\Tests\language\Kernel\Migrate\d7\MigrateLanguageContentTaxonomyVocabularySettingsTest
which does the same thing what the Entity Translation 7009 update hook does, so the fixed test should pass (but it fails because of the above).Anyway, the source database should be fixed. We have a test, so removing the needs test tag – it only reveals the issues of the database fixture.
Comment #7
huzookad7_taxonomy_term_translation
also should map this32768
to translatable.Comment #8
huzookaComment #9
huzookaAddressing #7, without test.
Comment #10
huzookaComment #11
Wim Leers🤯 Epic archeological work here!
Comment #12
Wim LeersComment #13
Wim LeersThis code no longer exists since #3187616: Fix TermTranslation query and add missing source plugin test got committed!
🤔
So … is this safe to delete?
Comment #14
huzookaBased on this, yes, absolutely: https://git.drupalcode.org/project/drupal/-/commit/4bc7dbb#07405c4197980...
There is a new condition which excludes source items where the
i18n_mode
is not0
or1
. That will obviously include32768
values!Comment #15
Wim LeersYay, thanks!