Contrib.social

Vocabularies with names longer than 32 characters are not migrated correctly

Open on Drupal.org →
Created on 25 September 2023, over 1 year ago
Updated 27 September 2023, over 1 year ago

Problem/Motivation

Since https://www.drupal.org/node/2232665 → , machine names cannot be longer than 32 characters.

When migrating a D7 site with names longer than that, the machine name is truncated to 32 characters in some places, while it remains complete in some other places.

The result is an inconsistent D10 site after migrate, where fieldDefinitions are missing the correct field mapping, causing errors on fields carried by these entities, even when the fields are created after the migration itself: the name remains untruncated in some places causing mismatches and error reports on admin/reports/fields, like this:

Error message
Warning: Undefined array key "vocabulaire_de_l_horreur_et_du_malheur" in Drupal\field_ui\FieldStorageConfigListBuilder->buildRow() (line 130 of core/modules/field_ui/src/FieldStorageConfigListBuilder.php).
Drupal\field_ui\FieldStorageConfigListBuilder->buildRow(Object) (Line: 242)
Drupal\Core\Entity\EntityListBuilder->render() (Line: 88)
Drupal\field_ui\FieldStorageConfigListBuilder->render() (Line: 23)
Drupal\Core\Entity\Controller\EntityListController->listing('field_storage_config')
[...]
Warning: Trying to access array offset on value of type null in Drupal\field_ui\FieldStorageConfigListBuilder->buildRow() (line 130 of core/modules/field_ui/src/FieldStorageConfigListBuilder.php).
Drupal\field_ui\FieldStorageConfigListBuilder->buildRow(Object) (Line: 242)
Drupal\Core\Entity\EntityListBuilder->render() (Line: 88)
Drupal\field_ui\FieldStorageConfigListBuilder->render() (Line: 23)
Drupal\Core\Entity\Controller\EntityListController->listing('field_storage_config')
[...]

Steps to reproduce

  • Create a D7 site
  • Add a vocabulary named e.g. "'a vocabulary with a name that is much too long"
  • Its machine name will be "'a_vocabulary_with_a_name_that_is_much_too_long" (46 characters)
  • Add a configurable field to it, e.g. field_value
  • Migrate to D10 using migrate:upgrade and migrate:import
  • The migrated vocabulary is now called "'a vocabulary with a name that is"
  • Navigate to admin/reports/fields
  • Observe the error message

Proposed resolution

Just an idea without debugging it yet: we may need to change multiple migration plugins, not just the one for the field, but the (dynamic_)entity_reference(_revisions) ones too, to ensure the same normalization is applied to the referenced entities

Remaining tasks

  • Reproduce on a minimal setup
  • Analyze the process
  • Develop a fix

User interface changes

None.

API changes

None.

Data model changes

Possibly more column changes at the constraint level.

Release notes snippet

TBD.

🐛 Bug report
Status

Needs work

Version

10.1 ✨

Component
Migration  →

Last updated about 12 hours ago

Created by

🇫🇷France fgm Paris, France

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

Comments & Activities

  • Issue created by @fgm
  • Comment over 1 year ago →
    🇫🇷France fgm Paris, France
  • Comment over 1 year ago →
    🇫🇷France fgm Paris, France

    More info: when generating the migrations with migrate:upgrade, the migrate_plus.migration.upgrade_d7_taxonomy_vocabulary migration entity for process.vid.length has value 30, which explains why the vocabulary names are truncated to 30 characters instead of the 32 allowed by machine names.

    The generated terms migration e.g. upgrade_d7_taxonomy_term_vocabulaire_de_l_horreur_et_du_malheur correctly references the new vid using the migration_lookup plugin, for which the migrate_map entry shows the name has been correctly truncated.

    However, when checking the migrate_map entry for the field_instance migration, the destid2 is the unchanged source name of. the vocabulary instead of the updated vocabulary. This appears to be due to the process.bundle using source = ['entity_type', '@bundle_mapped'], where bundle_mapped is a constant map only remapping the comment_forum bundle to comment_node_forum and ignoring the other possible renamings.

  • Status changed to Needs work over 1 year ago
  • Comment over 1 year ago →
    🇫🇷France fgm Paris, France

    As a quick hack, modifying the generated migrate_plus.migration.upgrade_d7_field_instance.yml to add the mapping manually allows the upgrade_d7_field_instance not to fail.

    process:
  # ...
  bundle_mapped:
    - 
      plugin: static_map
      source: bundle
      bypass: true
      map:
        comment_node_forum: comment_forum
        # Add a line like the one below
        the_name_that_is_really_too_long: the_name_that_is_really_too 
  # ...

    Now, the question is how to automate this.

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024