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_translationmigrate 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 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.ymlandcontent_translation.migrate_drupal.ymltells 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\MigrateLanguageContentTaxonomyVocabularySettingsTestwhich 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_translationalso should map this32768to 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_modeis not0or1. That will obviously include32768values!Comment #15
wim leersYay, thanks!
Comment #20
quietone commentedThe Migrate Drupal Module was approved for removal in #3371229: [Policy] Migrate Drupal and Migrate Drupal UI after Drupal 7 EOL.
This is Postponed. The status is set according to two policies. The Remove a core extension and move it to a contributed project and the Extensions approved for removal policies.
The deprecation work is in #3522602: [meta] Tasks to remove Migrate Drupal module and the removal work in #3522602: [meta] Tasks to remove Migrate Drupal module.
Migrate Drupal will not be moved to a contributed project. It will be removed from core after the Drupal 12.x branch is open.