Move migration code from content_translation to migrate_drupal

Removing content_translation from the list of installed modules will fix StateFileExistsTest.

I think all the remaining failures are due to that fact that translation migrations are discovered when previously they were not. And thus effects tests of the migrate UI.

Add deprecation of I18NQueryTrait. Also add filtering of the migration definitions so that only those for installed extensions are used.

Locally, I am getting failures in /d6/NoMultilingualReviewPageTest.php and I am starting think that this work is exposing an existing bug.

Ah, it is failing on different tests now.

Changed MigrationPluginList to not install 'content_translation' at setup, but at the end for testing the entity translation migrations. Also improved the filtering, which is still rough.

I think we should change d6_ and d7_entity_reference_translation to have a destination_module defined. I just haven't done that yet.

This adds destination_module to the entity_reference_translation followup migrations. Also added is filtering of the declared migration state results (those in the state files) to remove those for modules that are not installed on the destination.

Fix coding standards.

Remove changes that were removing information from the state files. I was trying to make this behave the same as when the data was in content_translation. And manipulating the state data like that isn't the right thing to do. If the state file is correct, the results are different for d6\NoMultilingualReviewPageTest::testMigrateUpgradeReviewPage because it now has all the data available, which it did not before when content_translation was disabled.

Let's get a fresh test run.

This is to fix the 2 Drupal 6 related tests. Remember the source Drupal 6 sites has translations and translation modules enabled. In both of these tests the module content_translation is not enabled. Therefore, the destination will be missing data and this should be reflected on the review page. That fact that it does not on HEAD is a bug.

Because the Review page is a best effort, I am not inclined to make a separate issue to fix that on HEAD. It also requires some thought about how that applies in all cases. How can a user be informed that they need a destination module installed if that module is not already installed to make the state file available.

That leaves the failures for Drupal 7 sources, which is simply 2 less path aliases. I presume that content_translation is creating those. I have not fixed that in this patch.

I was mistaken, /core/modules/forum/tests/src/Functional/migrate_drupal/d7/Upgrade7Test.php is in the same situation as the Drupal 6 tests fixed in the previous patch.

Still don't know why the core/modules/migrate_drupal_ui/tests/src/Functional/d7/Upgrade7Test.php has less path_aliases.

The reason there are 2 less path_alieses is because the entity_translation migrations, specifically d7_taxonomy_term_entity_translation, is not running. And that is correct because the destination_module is content_translation.

Time to get some feedback on this approach.

One thing that needs to be done is to search for Kernel migration tests that should move as well. One such would be \Drupal\Tests\taxonomy\Kernel\Migrate\d7\MigrateTaxonomyTermTranslationTest. I think that can wait until there are some reviews on this.

FWIW I think it would be more manageable to breakout separate tickets for moving

Option 1

Per module - this includes migration folder and any tests.

Option 2

Ticket for per module to migration folder and a separate one for tests.

I'm also more of a fan of the smaller tickets (easier to review) but not sure how much that comes into play here.

Just my 2 cents.

The Needs Review Queue Bot → tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

Updating tags

Just a reroll.

This is introducing filtering of migrations, I wonder if that should part should be a separate issue?

@quietone are you referring to

+  /**
+   * Gets migrations for installed modules.
+   *
+   * @return array
+   *   Filtered definitions.
+   */
+  public function getDefinitions() {
+    $definitions = parent::getDefinitions();
+
+    // Filter out definitions where the destination module is not installed.
+    $installed = array_keys(\Drupal::service('module_handler')->getModuleList());
+    $filtered_definitions = array_filter($definitions, function ($definition) use ($installed) {
+      $destination_module = $definition['destination']['destination_module'] ?? NULL;
+      if (empty($destination_module)) {
+        $destination_module = $definition['destination_module'] ?? NULL;
+      }
+      if (empty($destination_module)) {
+        if (is_array($definition['provider'])) {
+          $destination_module = reset($definition['provider']);
+        }
+        else {
+          $destination_module = $definition['provider'];
+        }
+      }
+      return in_array($destination_module, $installed);
+    });
+    return $filtered_definitions;
+  }

I think it would be nice to have separate just for searching of tickets later.

I am postponing this on the parent. I was assuming we would follow the current policy of removing a module from core. But, as usual, migrate drupal is a 'special snowflake' (I am pretty sure that is a phrase used by chx).

The plan has changed, see 📌 [Policy] Migrate Drupal and Migrate Drupal UI after Drupal 7 EOL Fixed