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
It looks like menu links that are localized are not migrated properly. I discovered this while working on #2975461: Convert query string to array for d6 menu_link migration and I was only looking at the because it came up as the triage issue for the day in #bugsmash earlier this week. So, well done bugsmash!
Steps to reproduce
Run a menu link migration from d6 and localized ones, not in the default language, get migrated with the default language instead of the menu language.
Proposed resolution
Add a migration for localized menu links, d6_menu_links_localized.
Remaining tasks
Patch
Tests
Review
Commit
User interface changes
N/A
API changes
N/A
Data model changes
N/A
Release notes snippet
N/A
Comment | File | Size | Author |
---|---|---|---|
#26 | 3245553-16.patch | 7.75 KB | quietone |
#16 | 3245553-16.patch | 7.75 KB | quietone |
| |||
#16 | diff.txt | 1.38 KB | quietone |
#10 | 3245553-10-fail.patch | 933 bytes | quietone |
#8 | 3245553-8.patch | 7.75 KB | quietone |
Comments
Comment #2
quietone CreditAttribution: quietone as a volunteer commentedAnd a fail patch and a working patch.
Comment #3
quietone CreditAttribution: quietone as a volunteer commentedComment #6
quietone CreditAttribution: quietone at PreviousNext commentedIt could be argued that this is a task, migrate localized menu link for D6. However, it is also a bug because the localized links are migrated incorrectly. Switching to a bug.
For those with configured legacy d6_menu_links migrations localized menu links will no longer be migrated, they were wrong anyway. Before this they were migrated with an incorrect language so not very useful. To fix that they need to update d6_menu_links and add the new d6_menu_links_localized migration.
The changes to the process plugin will not alter the results for legacy configured migrations.
Comment #7
danflanagan8@quietone, I've spent some time reviewing this one, though I'm starting to feel a little overmatched. Here's where I am...
First, I confirmed the bug doing a migration from the d6 fixture through the UI. After applying the patch and doing it all over, the menu link item was migrated correctly.
Here's the menu item in D6
Migrated into D9.4 without the patch
Migrated into D9.4 with the patch
So manual testing was good. Now for the code.
1. I'm a little confused by the naming of the new source properties
skip_localized
andnot_localized
. From an English standpoint, they look equivalent to me. We would skip localized migration if it is not localized.2. Is there a reason that we are using two properties for this? Since they are always opposite, would we be able to use a single property? Or could we even just rely on the
langcode
property?3. I'm struggling to parse the tests, probably in part because I'm just not that strong in translation and localization. (I don't even know if those are different things!) But I think something that would help me would be if the test-only patch would simply demonstrate the existing bug. Right now it fails with this message:
No migrations created for id 'd6_menu_links_localized'.
Not a surprise that migration doesn't exist since it's being added in the next patch! Do you think you could come up with something that just shows
d6_menu_links
failing? It looks like the existing tests were trying to assert translated menu links. Why were those assertions not catching this problem?Comment #8
quietone CreditAttribution: quietone at PreviousNext commented#7.1 and 2. It looks like I just did something quick and dirty. This should be cleaner.
Comment #9
quietone CreditAttribution: quietone at PreviousNext commentedComment #10
quietone CreditAttribution: quietone at PreviousNext commentedI know what you mean about localization and translation. Despite working on all the translation migrations I still don't feel like I know the system well.
7.3. Here is a failing test. Hope it helps.
Comment #12
quietone CreditAttribution: quietone at PreviousNext commentedReturning to Need Review because I made a sample failing test after posting the success patch.
Comment #13
danflanagan8@quietone, thank you for the updated fail test. That totally cleared this up for me. The existing assertions are testing the langcode attribute on the link, which is not the same as the langcode of the entity. That is the biggest thing I wasn't putting together.
And I think I get the localization/translation difference here. The menu link we are looking at only exists in French. It's not an English entity that also has a French translation. Is that right?
I like the `is_localized` flag a lot. But I wonder if rather than setting it to `FALSE` we could just keep it `NULL`.
And instead of `is_bool` we could just use `empty` as the callable, which is a more common function and reads more easily to me.
I think we could do that even if you prefer setting `is_localized` to `FALSE`.
Comment #14
quietone CreditAttribution: quietone at PreviousNext commented@danflanagan8, your welcome. I'm glad it helped. Yes, the link is not a translation, it only exists in the French language.
Glad you like 'is_localized', it does read better. As for the suggested change it won't work because
empty
is not callable.Comment #15
danflanagan8@quietone, right you are! It looks like
is_null
is callable. What do you think about relying onNULL
andis_null
instead ofFALSE
andis_bool
?Comment #16
quietone CreditAttribution: quietone at PreviousNext commentedIn core, both a boolean and NULL are used for setting source properties that appear to be used for 'skips'. So, there is no precedence or preferred way. Personally, I do not think the change is necessary, this works and is readable, and is for Drupal 6 source which ideally no one should be using anymore.
The attached patch changes
is_localized
to be NULL when the menu link is not localized in the source plugin and changes the callable used in d6_menu_links fromis_bool
tois_null.
Comment #17
danflanagan8Thanks, @quietone! Sorry for putting you through the wringer. I know the tests are still running but there's no reason they should fail. I'm going to RTBC this, and hopefully I won't get embarrassed by a failed test.
Comment #18
quietone CreditAttribution: quietone at PreviousNext commentedYay, neither of use are embarrassed by a failing test!
Comment #20
danflanagan8Random fails in FunctionalJavascript tests. Back to RTBC.
Comment #22
danflanagan8More random fails in FunctionalJavascript tests. Back to RTBC.
Comment #24
danflanagan8Holy moly! This can't have been related to this patch. Back to RTBC.
Comment #25
quietone CreditAttribution: quietone at PreviousNext commentedComment #26
quietone CreditAttribution: quietone at PreviousNext commentedRe-uploading patch so it will test with 10
Comment #28
quietone CreditAttribution: quietone at PreviousNext commentedUnrelated fail
1) Drupal\Tests\media\FunctionalJavascript\CKEditorIntegrationTest::testLinkability
Comment #30
quietone CreditAttribution: quietone at PreviousNext commentedFailure in 1) Drupal\Tests\quickedit\FunctionalJavascript\QuickEditFileTest::testRemove, restoring RTBC.
Comment #31
alexpottCommitted and pushed 53783642d7 to 10.0.x and ef28407352 to 9.5.x and a92ee9af4e to 9.4.x. Thanks!