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
Make sure the functional tests in migrate_drupal_ui work without tracker installed and that the migration tests in tracker still work when tracker is removed from core.
Steps to reproduce
Proposed resolution
Add @todo where needed to remove tracker references in the removal issue
Copy the d7 fixture to tracker for the tracker tests and update cspell.json to ignore it
Create a version of NoMultilingualReviewPageTest to confirm that Tracker will be upgrade when enabled on the destination
Do not create an Upgrade7Test in tracker because there are no entities to count.
Remaining tasks
Patch
Review
Commit
User interface changes
API changes
Data model changes
Release notes snippet
Comment | File | Size | Author |
---|---|---|---|
#18 | 3267314-18.patch | 934.89 KB | quietone |
#18 | diff-16-18.txt | 2.12 KB | quietone |
#16 | 3267314-16.patch | 934.9 KB | quietone |
| |||
#16 | interdiff-14-16.txt | 5.45 KB | quietone |
#14 | 3267314-14.patch | 930.01 KB | quietone |
Comments
Comment #2
quietone CreditAttribution: quietone at PreviousNext commentedLet's try this.
Comment #4
quietone CreditAttribution: quietone at PreviousNext commentedCopied the wrong file. Start again for NoMultilingualReviewPageTest in tracker.
Comment #5
quietone CreditAttribution: quietone at PreviousNext commentedI think the test is failing because a directory, which is empty, is not created. This should fix that and I've trimmed down the ReviewPage test to the bare minimum.
Comment #6
quietone CreditAttribution: quietone at PreviousNext commentedComment #8
quietone CreditAttribution: quietone at PreviousNext commentedAdding a review only patch that removes the test fixture from the patch in #5.
The failing tests are random javascript test fails, so setting this to NR.
Comment #9
quietone CreditAttribution: quietone at PreviousNext commentedRereoll
Comment #11
quietone CreditAttribution: quietone at PreviousNext commentedFailure was 1) Drupal\Tests\layout_builder\FunctionalJavascript\ContextualLinksTest::testContextualLinks
This just reduces the size of the tracker fixture by removing things like translations and lots of fields. The fixture still works on a d7 site.
Comment #13
quietone CreditAttribution: quietone at PreviousNext commentedThe failure on 10 was Drupal\Tests\quickedit\FunctionalJavascript\QuickEditFileTest::testRemove
Comment #14
quietone CreditAttribution: quietone at PreviousNext commentedAdding an @todo. No need to run tests again for a comment.
Comment #15
danflanagan8@quietone, I think I found a couple things that need an update.
1. After applying the patch in #14 I still see tracker referenced in
MigrateDrupal6AuditIdsTest
andMigrateDrupal7AuditIdsTest
. I think we probably need to add the standard @todo for those.2. I think that we can remove the cspell line from
Drupal\Tests\tracker\Functional\Migrate\ReviewPageTest
. That appears to be a copy/paste relic.3. Is
MigrateTrackerSettingsTest
completely new test coverage? That's not a problem exactly, but it's driving me nuts that I can't figure out where that came from.Looking good! I'm going to set back to NW.
Comment #16
quietone CreditAttribution: quietone at PreviousNext commented@danflanagan8, thanks.
#1. I was more careful in my checking for 'tracker' this time and have added more @todo, including the files mentioned.
#2. Done
#3. It is not a new test. It is testing d7_tracker_settings, #2353777: Migrate Tracker module variables in D7.
The tests of the ReviewPage in migrate_drupal_ui are still testing with Tracker enabled and just have @todos to remove tracker later. Ideally, Tracker would not be installed in these tests but I am not convinced the extra work to do that is needed. The ReviewPage relies on the state files, and the combination of state files and the possible combinations is well tested.
Comment #17
danflanagan8Thanks for the updates, @quietone, especially the note on d7_tracker_settings. My question must have sounded crazy now that I see that file is not new, just very slightly modified. D'oh!
At this point I am noticing an inconsistency between this issue and the issue to remove
aggregator
. In that issue, aggregator got uninstalled in theReviewPage
tests and it got moved from thegetAvailablePaths
togetMissingPaths
. And there is no @todo to remove "Aggregator" fromgetMissingPaths
. I recently defended this in #3264120-17: Remove aggregator module and our dependency on Laminas Feed:Your latest patch though adds @todos to remove
tracker
fromgetAvailablePaths
but there's nothing about adding them togetMissingPaths
. And the RDF patch actually adds @todos to remove RDF fromgetMissingPaths
.(RDF issue: #3267513: Handle migration tests for removing RDF)
So now I'm not sure which of the approaches is correct. I had assumed
aggregator
would be the model, but maybe not. Can you clarify for me?Comment #18
quietone CreditAttribution: quietone at PreviousNext commentedUnfortunately that is not true. How each module behaves depends on its status in the standard profile, the source database, and if there are related migrations. We discovered with aggregator that the block migration will migrate all blocks, including aggregator ones. So we left those blocks in the source database since the migration needs to handle that case properly, we should test it. That make aggregator a special case.
Patch needed a reroll.
Comment #20
quietone CreditAttribution: quietone at PreviousNext commentedUnrelated fail, Drupal\Tests\media_library\FunctionalJavascript\WidgetOEmbedTest::testWidgetOEmbedAdvancedUi.
Comment #21
SpokjeLGTM
Comment #22
SpokjeSince this is blocking #3261452: [11.x] Remove tracker module from core, which has priority major, also bumping this one to major.
Comment #24
catchCommitted/pushed to 10.0.x and cherry-picked to 9.5.x, thanks!
Comment #25
SpokjeI have _no_ clue how this happened, but by the look of https://www.drupal.org/pift-ci-job/2408230 the commit to
10.0.x
broke HEAD.Reopening and marking as Critical.
Comment #27
catchI've reverted this from 10.0.x, left it in 9.5.x until we know whether we need to redo the patch here or it's an unlucky interaction with another patch.
Comment #28
catchSent the patch for a fresh run against 10.0.x
Comment #29
Spokje"Fun" stuff, the patch now fails similar in the way HEAD failed when the patch was applied, weirdly on it's previous runs, the last one being literary one hour before the commit on both
9.5.x
and10.0.x
(https://www.drupal.org/pift-ci-job/2408203) it returned all green.10.0.x
HEAD comes back with the same 70 failures after the patch was reverted.Something with the letters W, T and F springs to mind...
I can only conclude that this patch isn't the root cause of the HEAD failure.
Comment #31
catchSince this doesn't look like the culprit, I've reverted the revert. However I also can't see an obvious candidate for the culprit either.
Comment #32
SpokjeI think this needs to go back to fixed since the revert was reverted and both
9.5.x
and10.0.x
contain this code.