[Meta] Handle forum migrations not in the forum module for deprecating forum

@quietone
What is the importance of this issue.
what is the proposed solution. Is it impacting on 10

Ok!

@quietone for the static map ones, do we have the option of filtering out those rows in the source, and then duplicating those migrations to the forum module and doing the converse (filtering to only the forum rows)

Aren't these files being moved to migrate_drupal to also be deprecated/removed?

Should this be Needs Review, no patch/MR that I can see?

@larowlan:

Would it make more sense if we changed the title to "Evaluate migrations ..." or "[Policy, no patch] Handle migrations ..."?

There is nothing wrong with migration code that supports contrib modules, so +1 for keeping the migrations as is unless they actually cause problems.

My favorite example of support in core for contrib modules is the filter_id process plugin in the filter module.

Most of the migrations that refer to "forum" set some property using the static_map process plugin, and one or more of the keys that get mapped are related to the Forum module. This is harmless, so leave it as is.

Maybe I am going outside the scope of this issue, but I support moving everything related to the forum_vocabulary process plugin into the Forum module. Maybe leave the parts that are in the migrate_drupal module where they are; everything else is in the taxonomy module. Here is what that would involve:

1. Move the process plugin from Taxonomy to Forum.
2. 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.
3. 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, if someone is willing to make the effort. Curiously, there is some test code related to this field, but I do not see any tests that mention forum_vocabulary.

I just noticed the related issue #2914251: Move forum related logic from taxonomy migrations to new forum migrations. Perhaps we can make that issue a sibling of this one (child of the same meta issue) and use that issue to make the changes I suggested in #13.

Is this more a plan then a task?

I think something got lost in #17. Is this what you meant? (See 2 and3 in the proposed resolution.)

This is still in d7/TermTest:

  $tests[0]['source_data']['variable'] = [
      [
        'name' => 'forum_containers',
        'value' => 'a:3:{i:0;s:1:"5";i:1;s:1:"6";i:2;s:1:"7";}',
      ],

I guess that is fine because it's just test data?

Otherwise looks like no traces left.

Yeah, I agree this can be marked done.

There's a reference to forum_containers in the variables table but on it's own that does nothing.

There's also some terms from a 'forum' vocabulary that are migrated but they're migrated as terms - because that's what they are.

There's no special handling for the fact the vocab is called forum in the taxonomy module.