Problem/Motivation
Follow-up to two Forum related issues
- Term migrations: #2903007: [D7] Forum containers are migrated as forums
- Vocabulary migrations: #2914249: Translated forum vocabulary migration creates duplicate forum vocabularies
Clean Forum specific logic from Term migrations
From comment #56:
Separately, it feels super grody to the max and decidedly un-tubular and non-radical to shove a bunch forum logic in the taxonomy term migrations. Maybe we could also get a non-critical follow-up to make Forum a sub-class of Term so we can better encapsulate the one-off logic here.
And comment #59:
I'm wondering if the forum migration could be a secondary migration (i.e. allow taxonomy to migrate the terms, then have forum get the forum/container metadata from the source site, load the terms already migrated and save the field values etc.).
Clean Forum specific logic from Vocabulary migrations
From comment #18
We should open a follow-up to move this logic into a Forum-specific variant of this plugin. Forum could even swap in its own implementation of the plugin (using the ol' plugin hijacking technique) which implements this logic.
And comment #13
Move the process plugin from Taxonomy to Forum.
Set the forum_vocabulary source property somewhere other than the d6_taxonomy_vocabulary and d7_taxonomy_vocabulary source plugins. I am not sure what the best way is, but we must have an event or an alter hook that lets us modify a row.
Implement hook_migration_plugins_alter() to insert the process plugin into 6 migrations, and remove the corresponding step from those migrations.I am not sure it is worth the effort, but it would have the effect of simplifying the code that is left behind when we remove the Forum module.
Similar: the code related to the is_container source property (set in the d7_taxonomy_term and d7_taxonomy_term_entity_translation source plugins) and the forum_container taxonomy field (boolean?) should be moved to the Forum module
Steps to reproduce
Proposed resolution
Make a migration test fixture in the forum module and use that for all the forum migration tests.
Remove the use of the process plugin, forum_vocabulary, from taxonomy migrations.
Create migration tests in the forum module for taxonomy
Remaining tasks
User interface changes
API changes
Data model changes
Release notes snippet
| Comment | File | Size | Author |
|---|---|---|---|
| #44 | 2914251-44.patch | 243.24 KB | quietone |
| #44 | diff-39-44.txt | 3.61 KB | quietone |
| #42 | 2914251-42.patch | 250.17 KB | quietone |
| #42 | interdiff-39.42.txt | 3.69 KB | quietone |
| #39 | 2914251-39.patch | 243.27 KB | quietone |
Comments
Comment #2
maxocub commentedComment #3
quietone commentedAdd a postponed item to the IS.
Comment #4
masipila commentedAdded the vocabulary issue the issue summary so that we won't forget it when fixing the term thing.
Cheers,
Markus
Comment #5
masipila commentedComment #6
catchThe two critical bugs are in, so this can be unpostponed now.
Comment #15
quietone commentedI think the source of the problem is that the taxonomy source plugins do not exclude forum. Moving code related to the process plugins, as suggested in #13, will fix part of the entanglement but not all.
Comment #16
quietone commentedTo see what this looks like here is a patch that removes the forum processes from the taxonomy migrations and adds them back in hooks. There are updates to the forum fixtures, so I have made a patch without that to make it easier to review. And I did not look at the Functional tests, so I expect failure.
Comment #17
quietone commentedMost failures due to errors in
forum_migration_plugins_alter.The error in \Drupal\Tests\forum\Kernel\Migrate\d6\MigrateForumTest is fixed in #3350511: Change MigrateForumTest to use forum test fixture.
Comment #18
quietone commentedThe test MigrateLanguageContentTaxonomyVocabularySettingsTest.php isn't right. There should be one in forum that tests for the changed name.
Comment #21
quietone commentedI thought I ran those failing tests locally but I ran the ones in migrate_drupal_ui out of habit and not the ones in forum. The updates the Upgrade tests for the changes to the source fixtures. I also sorted the entity count array which make is appear that more counts were changed. I did that because it is just a pain that the lists never got sorted.
This should results in 1 failing test, \Drupal\Tests\forum\Kernel\Migrate\d6\MigrateForumTest which is fixed elsewhere.
Comment #23
larowlan🔥 this is amazing! Looks like just that one fail (one is random)
paranoia but let's add the ['allowed_classes' => FALSE] as the second argument here
this is only used inside the alter hook, so let's make it a closure inside that function instead
this could use
array_column($entity->get('parent')->getValue(), 'target_id')and save the need for the protected method as well as a few extra queriesComment #24
quietone commentedIf I don't update this by Monday, feel free to set to 'unassigned'.
Comment #25
quietone commentedThis patch address all the items in #23. There were no issues, it was all straightforward.
Comment #28
quietone commentedRerolled. Also, the incremental migrations are not run in the functional test so the method returns an empty array instead of entity counts.
Comment #30
quietone commentedAdding a test file to the d6 and d7 Functional tests.
Comment #32
quietone commentedThis will fix one of the tests. It needed checks forum_migrate_prepare_row and forum_migrate_d7_taxonomy_vocabulary_prepare_row that the results from a query exist before trying to use them. And a change to \Drupal\Tests\forum\Functional\migrate_drupal\d6\Upgrade6Test::getEntityCountsIncremental to return an empty array because we are not testing incremental migrations here. Also re-installed Upload in the d6 database.
Comment #34
quietone commentedIt too a long time but I finally spotted the problem. In
forum_migration_plugins_alterI have the machine name as 'forum' instead of 'taxonomy_forum'. With that fixed all the remained was to correct the tests.Comment #36
quietone commentedIgnore #34.
While investigating the error in #32 I saw that forum is being installed in two Migration tests in the taxonomy module. This should fix both of those and move what needs to move to forum tests. I also made MigrateTestTrait in forum to make the tests a bit easier to follow.
Comment #37
quietone commentedJust entity count changes.
Comment #39
quietone commentedNow to fix the error in MigrateForumTest. It seems that I did not complete
forum_migration_plugins_alterand didn't have the correct process for the field name, that have been removed from the taxonomy migrations. With that fixed some tests needed to use the correct field name.Comment #40
quietone commentedReady for review again.
Comment #41
larowlanI went through each of the tests here that extend from core tests (other than base classes) and made sure we've named the test method the same and that the parent classes don't contain any other test methods (so we're not inadvertently running the same identical test twice).
All of them looked good.
The changes since #23 look good to me.
This was a huge effort @quietone and my comment 'just one fail' was famous last words.
Thanks for all your efforts here!
Comment #42
quietone commentedThis needed a reroll. I also sorted the list of entity types in the forum tests, Upgrad6Test and Upgrade7Test
Comment #44
quietone commentedIgnore #42. I wasn't working from a clean site.
Comment #45
smustgrave commentedSince this was previously RTBC and reroll #44 seems good going to remark.
Comment #47
catchLooks great and how it should have been done all along as evidenced by the age of the issue.
Committed/pushed to 11.x, thanks!
Comment #48
quietone commentedThis needs a change record and then a followup to correct the URL in the deprecation messages. I am working on this now.
Comment #49
quietone commentedChange record made and published. The followup is #3387831: Fix change record link added in #2914251
Comment #51
donquixote commentedThis code can lead to problems.
In core 'd7_taxonomy_vocabulary',
$migrations[$migration_id]['process']['vid']is a single process plugin, so all is good.But with a custom migration, as with migrate_plus,
$migrations[$migration_id]['process']['vid']is already an array of process plugins. The$process[] = ..assignment will result in a nesting level that is one level too deep.As a result, I get "Undefined array key "plugin" Migration.php:727" for the upgrade_d7_taxonomy_vocabulary migration.
In fact, the upgrade_d7_taxonomy_vocabulary generated with migrate_plus contains has the 'forum_vocabulary' processor in 'vid'.
So adding it again would result in duplication.
As a workaround, I can edit the custom migration, by copying the 'vid' process setup from 'd7_taxonomy_vocabulary'.
Still, this should be fixed.