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
We need an upgrade path from D7 for the core Tracker module.
Remaining Tasks
Write migrations, with tests, to cover the following:
- Any variables maintained by Tracker need to be moved into configuration
- The tracker_node and tracker_user tables may need to be migrated
Comment | File | Size | Author |
---|---|---|---|
#12 | interdiff-2500535-11-12.txt | 2.91 KB | quietone |
#12 | 2500535-12.patch | 10.9 KB | quietone |
#11 | interdiff-2500535-6-11.txt | 4.21 KB | quietone |
#11 | 2500535-11.patch | 9.69 KB | quietone |
#6 | 2500535-6.patch | 9.72 KB | quietone |
Comments
Comment #1
quietone CreditAttribution: quietone commentedComment #2
quietone CreditAttribution: quietone commentedJust need to figure out how to test this properly. How do I retrieve the data from the tracker tables?
Comment #3
quietone CreditAttribution: quietone commentedHere's a working patch that still needs tests.
Comment #4
quietone CreditAttribution: quietone commentedComment #5
phenaproximaExcept for the lack of asserts, looks pretty good to me. Some minor things, though:
The dump file hash doesn't appear to have been updated; this needs to be regenerated with migrate-db.sh.
Unnecessary extra line after the annotation.
Can be all one line:
return $this->select('tracker_node' ,'tn')->fields('tn')
. We don't generally need to cherry-pick the fields we're returning.There are extra lines after the annotation and after the doc block.
Nit: Needs an extra line before the query() doc comment.
This can be streamlined as well.
We're not generally supposed to mix array() and [] syntaxes in the same file.
This doesn't migrate configuration.
Should be public static.
It might be prudent to add optional dependencies on d7_node:* and d7_user to the d7_tracker_node and d7_tracker_user migrations, respectively.
No it doesn't :)
public static
We don't actually need this, since it's not truly a unit test that tests actual methods of TrackerNode.
$this->databaseContents['tracker_node'] = $this->expectedResults is preferable to repeating the rows.
Let's ditch this, since it doesn't really apply to these source plugin tests.
$this->databaseContents['tracker_user'] = $this->expectedResults
Comment #6
quietone CreditAttribution: quietone commentedI think I've addressed everything in #5.
How does one get the tracker data to test it?
Comment #7
rajeevkComment #10
phenaproximaThis is a good start, but @quietone is right -- how can we get some tracker data for testing? I'm thinking we should simply enable Tracker in the D7 database and use the site a bit like normal -- publishing nodes, browsing as different users, etc. -- that should collect at least a little data.
"publisehd"? Oops :)
Is this necessary? I don't think users are considered published...?
Needs @inheritdoc.
Better to use executeMigrations() here, since that'll put things in dependency order.
$this->executeMigrations(['d7_user_role', 'd7_user', ...])
Also needs @inheritdoc.
Should also use executeMigrations().
Comment #11
quietone CreditAttribution: quietone commentedFixed all the issues in #10.
Comment #12
quietone CreditAttribution: quietone commentedAdded tests.
Comment #13
phenaproximaThere should be an extra line between <?php and the file comment, but that can be fixed on commit.
Ditto here.
Other than these nits, I see no problems here. Big props to @quietone for sticking with it! RTBC.
Comment #14
webchickCommitted and pushed to 8.0.x. Thanks!
Comment #18
webchickComment #20
Wim Leers🙈 #3204511: Deprecate tracker migration