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

The static map and the simple assigned are ok as it. The process plugin forum_vocabulary uses a flag set in the source plugin to identify the vocabulary as a forum one, in that case the vid if the row is for a forum. Again, there is nothing there that requires the forum module.

There is no need to change or move any of these migrations that refer to forum. None of these require forum data to exist, or the forum module to be enabled.

@quietone
what is the proposed solution. Is it impacting on 10

@Manoj Raj.R, this is one of the steps to deprecate the Forum module. There is more detail about that process in the parent issue, That issue also has a link to the issue where the deprecation and removal of the Forum module was approved.

I made this issue so that there was a place to discuss what happens to migrations that do anything regarding the Forum module. As for the proposed resolution, it is as stated in the Issue Summary. That is, I don't think anything needs to be done regarding the migrations listed in the Issue Summary. Therefore, nothing changes for Drupal 10 because of this issue.

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?

Re #8. There was some discussion about this, specifically about block migrations. #3265483: Handle block migration for modules moved to contrib → and #3267309: Decide whether to completely skip the migration of blocks from missing modules → . In that case it was preferred to leave the migrations as is because it would allow the migrator to get an error that something was not migrated. This still needs more disucssion.

#9. Yes, that is true. However, Forum is moving to contrib so we should complete this first. That will likely happen anyway because deprecating migrate_drupal is a much bigger task.

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 📌 Move forum related logic from taxonomy migrations to new forum migrations Fixed . 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 agree with #14, I am updating the meta data.

I misread #14 but am leaving the changes for now. Updated the IS with the current proposal

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

@benjifisher, I was trying to refer to your suggestion of making this issue a sibling of 📌 Move forum related logic from taxonomy migrations to new forum migrations Fixed . Instead I made this the parent of that one. I was thinking that here we could discuss the approach and record the decision in this one issue. Any implementations of those decisions are then children of this issue. For me, I prefer one issue on 🌱 [Meta] Tasks to deprecate Forum Active to represent this body of work.

I updated the IS to show that 2 and 3 of the proposed resolution are being explored in 📌 Move forum related logic from taxonomy migrations to new forum migrations Fixed .

I reviewed the child issue and it does resolve the points in the issue summary. I think this is now fixed.

I will set to RTBC for others to check.

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.

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