Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Problem/Motivation
Note that, as of 8.8.x, modules can declare their Drupal 8 (or 9) upgrade status (changelog, issue #2936365: Migrate UI - allow modules to declare the state of their migrations). Since there is no data to migrate from diff-7.x-2.x, diff-6.x-2.x, and diff-6.x-1.x, we should mark those migrations as "finished".
As a site owner migrating my site from Drupal 7 running diff-7.x-3.x to Drupal 8 or 9 running diff-8.x-1.x, I want to migrate configuration from diff, so that my Drupal 8/9 site has the same behavior as my Drupal 7 site.
It appears that 7.x-3.x stores the following data:
- Global variables:
diff_context_lines_leading(integer >= 0)diff_context_lines_trailing(integer >= 0)diff_show_diff_inline_node_bundles(associative array)diff_radio_behavior(string)diff_theme(string)
- For node and user entities, the following variables:
diff_additional_options_{$entityId}(associative array)diff_admin_path_{$entityId}(boolean)diff_default_state_{$entityId}(string/word)diff_show_header_{$entityId}(boolean)
- For
filefields, adiff_file_field_file_default_optionsvariable that contains the following data:show_header(boolean)show_id(boolean)compare_alt_field(boolean)compare_title_field(boolean)property_separator(string)markdown(string)line_counter(string)
- For
imagefields, adiff_file_field_file_default_optionsvariable that contains the following data:show_header(boolean)show_id(boolean)compare_description_field(boolean)compare_display_field(boolean)property_separator(string)markdown(string)line_counter(string)
- For each
listfield type, adiff_list_field_{$fieldType}_default_optionsvariable that contains the following data:show_header(boolean)compare(string)markdown(string)line_counter(string)
- For each
textfield type, adiff_text_field_{$fieldType}_default_optionsvariable that contains the following data:show_header(boolean)compare_format(boolean)markdown(string)line_counter(string)
- For
taxonomy[term reference] fields, adiff_taxonomy_field_taxonomy_term_reference_default_optionsvariable that contains the following data:show_header(boolean)show_id(boolean)sort(string)markdown(string)line_counter(string)
- For each remaining field type, a
diff_{$d7Module}_field_{$fieldType}_default_optionsvariable that contains the following data:show_headermarkdownline_counter
Proposed resolution
Add migrations.
Declare the finished upgrade path from D6 by creating a migrations/state/diff.migrate_drupal.yml and populating it appropriately.
Remaining tasks
Write a patch for global settings- Decide whether we want to migrate field configurations
- If "yes", then update the patch to migrate field configurations
- Review and feedback
- RTBC and feedback
- Commit
- Release
User interface changes
None.
API changes
None.
Data model changes
None.
| Comment | File | Size | Author |
|---|
Issue fork diff-3199333
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #2
miro_dietikerI didn't maintain the 7.x version, so i don't remember exactly the status there.
8.x is so much different that we felt like the default configuration is a healthy start and everything else that needs adjustments would be due to the different behavior and options 8.x provides. Where guessing from 7.x settings would provide little value.
I can be wrong, but that's why we didn't even consider providing a migration.
Is there any setting of value that should be migrated?
BTW i don't know if a migration is a task or a feature, but likely not a bug?
Comment #3
mparker17Updated issue summary with a list of what we need to migrate
Comment #4
mparker17As a bit of context, I'm trying to move a D7 site that I maintain in my spare time to D8/9 before D7 reaches end-of-life. The site uses 55 contrib modules that I want to keep around in D8/9; and 39 of those (i.e.: 71%) are missing migrations (although I've patched 9 of those already, leaving me with 30 to go)
I have been putting off upgrading from D7 because of the missing migrations (and I suspect other folks in the Drupal community have too).
To some extent, I'd like to know that the diff module's migration is "finished", i.e.: either because there is a migration, or because the maintainers consciously chose not to write a migrate. Right now, Drupal core's Migrate Drupal UI tells me the diff module "will not be upgraded", and until I filed this ticket, I wasn't sure whether the diff module not being migrated would be a bad thing.
In the case of the diff module, I hadn't really configured it much in D7; and the D9 site didn't appear to be broken, so I was considering it as a feature request.
That's fair enough... and again, we could just mark the migration as "finished" in
migrations/state/diff.migrate_drupal.ymlto indicate "the maintainers familiar with both versions don't think there's anything that needs to be migrated"... for my particular use case, that would be fine; although I dunno if I'm a typical use case.If we do decide to write migrations, comparing the 7.x-3.x variables with the 8.x-1.x configuration...
... perhaps the best approach here is a hybrid one, i.e.: migrate the easy global configuration, and mark the migration as finished; and if someone files an issue because they really need the per-field-type migrations, we can deal with that one when it comes up.
@miro_dietiker, what do you think?
Comment #5
mparker17Here's a patch to migrate the global configuration, but NOT the field configurations. Note it assumes the missing field config is intentional and marks the migration as complete; but includes a comment to reference this issue.
Marking as "Needs review" so testbot runs; and to get an answer for #4; but feel free to set it back to "Needs work" if we decide we do want to migrate the field configurations.
Comment #6
mparker17Apparently drupal.org's testbot wants
public static $modulesin tests; while my localrun-tests.shwantsprotected static $modulesComment #7
mparker17I am happy to report that I was able to use this patch to successfully migrate my Diff module configuration from my
drupal-7.99site runningdiff-7.x-3.4to adrupal-10.2.1site runningdiff-8.x-1.1.I cannot RTBC this issue because I wrote the patch. But, hopefully, my success will help other people migrating D7 to D10.
However, now that my D7 to D10 site migration is complete, my ability to contribute further to this issue is severely limited, because the D7 site that I had been using to test has been retired. However, I'll keep an eye on this issue and try to answer questions to the best of my ability.
Comment #8
heddnCan we convert this to an MR at this point?
Comment #10
mparker17I've tried, but as mentioned in #7, my D7 to D10 site migration is complete and my D7 site retired, so I have no way to manually test that it still worked the way it did 10 months ago (but note the MR contains automated tests).
Comment #11
heddnThe items being migrated are reasonable and checks just another box on the upgrade from D7. I made some very minor phpcs and test fixes. So let's just RTBC this thing.
Comment #13
heddnComment #14
mparker17Awesome, thanks @heddn!