Problem/Motivation

Follow-up to two Forum related issues

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

Comments

maxocub created an issue. See original summary.

maxocub’s picture

Issue summary: View changes
quietone’s picture

Issue summary: View changes

Add a postponed item to the IS.

masipila’s picture

Issue summary: View changes

Added the vocabulary issue the issue summary so that we won't forget it when fixing the term thing.

Cheers,
Markus

masipila’s picture

Status: Active » Postponed
catch’s picture

Status: Postponed » Active

The two critical bugs are in, so this can be unpostponed now.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)

Bug reports should be targeted against the 8.6.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.8.x-dev

Drupal 8.6.x will not receive any further development aside from security fixes. Bug reports should be targeted against the 8.8.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.9.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

Bug reports should be targeted against the 8.9.x-dev branch from now on, and new development or disruptive changes should be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.2.x-dev

Drupal 8 is end-of-life as of November 17, 2021. There will not be further changes made to Drupal 8. Bugfixes are now made to the 9.3.x and higher branches only. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.15 was released on June 1st, 2022 and is the final full bugfix release for the Drupal 9.3.x series. Drupal 9.3.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.4.x-dev branch from now on, and new development or disruptive changes should be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.9 was released on December 7, 2022 and is the final full bugfix release for the Drupal 9.4.x series. Drupal 9.4.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.5.x-dev branch from now on, and new development or disruptive changes should be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

quietone’s picture

I 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.

quietone’s picture

Version: 9.5.x-dev » 10.1.x-dev
StatusFileSize
new53.83 KB
new274.71 KB

To 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.

quietone’s picture

Status: Active » Needs review
StatusFileSize
new3.66 KB
new276.68 KB

Most 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.

quietone’s picture

StatusFileSize
new2.4 KB
new278.51 KB

The test MigrateLanguageContentTaxonomyVocabularySettingsTest.php isn't right. There should be one in forum that tests for the changed name.

The last submitted patch, 17: 2914251-17.patch, failed testing. View results

Status: Needs review » Needs work

The last submitted patch, 18: 2914251-18.patch, failed testing. View results

quietone’s picture

Status: Needs work » Needs review
StatusFileSize
new3.84 KB
new282.69 KB

I 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.

Status: Needs review » Needs work

The last submitted patch, 21: 2914251-21.patch, failed testing. View results

larowlan’s picture

Status: Needs work » Active

🔥 this is amazing! Looks like just that one fail (one is random)

  1. +++ b/core/modules/forum/forum.module
    @@ -643,3 +654,95 @@ function template_preprocess_forum_submitted(&$variables) {
    +        $forum_container_tids = unserialize($result[0]);
    ...
    +      $forum_nav_vocabulary = unserialize($result[0]);
    

    paranoia but let's add the ['allowed_classes' => FALSE] as the second argument here

  2. +++ b/core/modules/forum/forum.module
    @@ -643,3 +654,95 @@ function template_preprocess_forum_submitted(&$variables) {
    +function merge_forum_vocabulary($process) {
    

    this is only used inside the alter hook, so let's make it a closure inside that function instead

  3. +++ b/core/modules/forum/tests/src/Kernel/Migrate/d6/MigrateTaxonomyTermTest.php
    @@ -0,0 +1,134 @@
    +    $this->assertEquals($expected_parents, $this->getParentIDs($id));
    

    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 queries

quietone’s picture

Assigned: Unassigned » quietone

If I don't update this by Monday, feel free to set to 'unassigned'.

quietone’s picture

Status: Active » Needs review
StatusFileSize
new5.78 KB
new282.43 KB

This patch address all the items in #23. There were no issues, it was all straightforward.

Status: Needs review » Needs work

The last submitted patch, 25: 2914251-25.patch, failed testing. View results

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

quietone’s picture

Status: Needs work » Needs review
StatusFileSize
new109.82 KB
new238.62 KB

Rerolled. Also, the incremental migrations are not run in the functional test so the method returns an empty array instead of entity counts.

Status: Needs review » Needs work

The last submitted patch, 28: 2914251-28.patch, failed testing. View results

quietone’s picture

Status: Needs work » Needs review
StatusFileSize
new274 bytes
new239.25 KB

Adding a test file to the d6 and d7 Functional tests.

Status: Needs review » Needs work

The last submitted patch, 30: 2914251-30.patch, failed testing. View results

quietone’s picture

Status: Needs work » Needs review
StatusFileSize
new10.29 KB
new236.9 KB

This 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.

Status: Needs review » Needs work

The last submitted patch, 32: 2914251-32.patch, failed testing. View results

quietone’s picture

Status: Needs work » Needs review
StatusFileSize
new11.39 KB
new237.12 KB

It too a long time but I finally spotted the problem. In forum_migration_plugins_alter I have the machine name as 'forum' instead of 'taxonomy_forum'. With that fixed all the remained was to correct the tests.

Status: Needs review » Needs work

The last submitted patch, 34: 2914251-34.patch, failed testing. View results

quietone’s picture

Status: Needs work » Needs review
StatusFileSize
new15.45 KB
new243.05 KB

Ignore #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.

quietone’s picture

StatusFileSize
new3.23 KB
new243.05 KB

Just entity count changes.

Status: Needs review » Needs work

The last submitted patch, 37: 2914251-37.patch, failed testing. View results

quietone’s picture

Status: Needs work » Needs review
StatusFileSize
new5.22 KB
new243.27 KB

Now to fix the error in MigrateForumTest. It seems that I did not complete forum_migration_plugins_alter and 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.

quietone’s picture

Assigned: quietone » Unassigned

Ready for review again.

larowlan’s picture

Status: Needs review » Reviewed & tested by the community

I 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!

quietone’s picture

Issue summary: View changes
Status: Reviewed & tested by the community » Needs review
StatusFileSize
new3.69 KB
new250.17 KB

This needed a reroll. I also sorted the list of entity types in the forum tests, Upgrad6Test and Upgrade7Test

Status: Needs review » Needs work

The last submitted patch, 42: 2914251-42.patch, failed testing. View results

quietone’s picture

Status: Needs work » Needs review
StatusFileSize
new3.61 KB
new243.24 KB

Ignore #42. I wasn't working from a clean site.

smustgrave’s picture

Status: Needs review » Reviewed & tested by the community

Since this was previously RTBC and reroll #44 seems good going to remark.

  • catch committed 14167858 on 11.x
    Issue #2914251 by quietone, maxocub, masipila, larowlan: Move forum...
catch’s picture

Status: Reviewed & tested by the community » Fixed

Looks great and how it should have been done all along as evidenced by the age of the issue.

Committed/pushed to 11.x, thanks!

quietone’s picture

Status: Fixed » Needs work
Issue tags: +Needs change record, +Needs followup

This needs a change record and then a followup to correct the URL in the deprecation messages. I am working on this now.

quietone’s picture

Status: Needs work » Fixed
Issue tags: -Needs change record, -Needs followup

Change record made and published. The followup is #3387831: Fix change record link added in #2914251

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

donquixote’s picture

    if (is_a($source_plugin, D7Vocabulary::class)
      && !is_a($source_plugin, D7VocabularyTranslation::class)
      && !is_a($source_plugin, D7LanguageContentSettingsTaxonomyVocabulary::class)) {
      if (isset($migration['process']['vid'])) {
        $process[] = $migrations[$migration_id]['process']['vid'];
        $migrations[$migration_id]['process']['vid'] = $merge_forum_vocabulary($process);
      }
    }

This 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.