Problem/Motivation

It's not the name column in the Drupal 7 filter_format database table that determines the ID of the FilterFormat config entity, but the format column, which is an auto-incrementing integer.

Consequence: this makes any future debugging on your Drupal 8 site a pain, because rather than sensible formats such as basic_html or markdown_all_html_allowed, you get 3 or 7 as text format IDs.

Proposed resolution

Use the name column in the D7 table and apply the "machine name" algorithm to it to generate a sensible name.

Remaining tasks

TBD

User interface changes

N/A

API changes

N/A

Data model changes

More sensible D8 destination data model.

Release notes snippet

TBD

CommentFileSizeAuthor
#2 3095337-2.patch3.03 KBwim leers
#2 filter_format machine name.png901.57 KBwim leers

Comments

Wim Leers created an issue. See original summary.

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented
Issue summary: View changes
Status: Active » Needs review
StatusFileSize
new filter_format machine name.png901.57 KB
new 3095337-2.patch3.03 KB

Turns out the test coverage in \Drupal\Tests\filter\Kernel\Plugin\migrate\source\d7\FilterFormatTest is wrong — it does not reflect the Drupal 7 reality. 🙈

This fixes the tests, without fixing the reported bug yet.

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented
Title: Text formats that are migrated from D7 to D8 get a numerical ID instead of a sensible name » Text formats that are migrated from D6 to D7 to D8 get a numerical ID instead of a sensible name
Priority: Normal » Minor
Issue tags: +migrate-d6-d8

Based on #2555089: d7_filter_format migration mishandles format IDs, this must be happening because my Drupal 5 site updated to Drupal 7 via Drupal 6, and the Drupal 6-to-7 update path retained numerical identifiers.

That makes this a far lower priority. And it means that the patch in #2 is inaccurate.

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented
Related issues: +#2555089: d7_filter_format migration mishandles format IDs
wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented
Component: filter.module » migration system

Been told that I should put this in migration system :)

heddn’s picture

heddn
Primary language English
Location Illinois
commented
Status: Needs review » Needs work

NW per #2/#3.

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented

I'm not sure there is something to do here to be honest.

Ideally, the user would be prompted or at least warned that they'll be getting FilterFormat config entities with numerical IDs. Which is bad, weird, atypical, might trip up other code. But it should work okay. And I don't think the Migrate system was designed to prompt the user. So I think that the way to solve this is to generically make the migration system detect numerical IDs for any config entity it saves and log a warning. That warning should say it's recommended to modify the migration YML file, to specify a manual mapping (from e.g. 1 to full_html).

Thoughts?

heddn’s picture

heddn
Primary language English
Location Illinois
commented

Now I'm re-reading this again, this brings back to mind #2620932: D7 legacy numeric text formats fail, how to map them? and #2720271: Document how to perform format mappings in D6/D7 upgrade where we decided not to map any of these numeric values to anything else.

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented
Related issues: +#2620932: D7 legacy numeric text formats fail, how to map them?, +#2720271: Document how to perform format mappings in D6/D7 upgrade

Thanks, that's really useful context!

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

smustgrave’s picture

smustgrave commented
Status: Needs work » Postponed (maintainer needs more info)

Question is this still needed for D10? Feel after 5 years if still needed/

quietone’s picture

quietone commented
Status: Postponed (maintainer needs more info) » Needs work

Yes, sites are still migrating. This is still needed.

quietone’s picture

quietone commented
Status: Needs work » Postponed

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

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.