D7->D8 Language module migration runs when not appropriate

See #3151980-6: System mail settings migration (d7_system_mail) assumes that the mail_system variable is always available.

This also can be solved by the help of improving the Variable source plugin #3152789: Add required variables config to Variable migrate source plugin, and if one of those are missing, return zero rows. @DamienMcKenna, if you can help it moving forward, that would be awesome.

Back to NW for a failing test that passes with the fix.

Actually this is postponed on #3152789: Add required variables config to Variable migrate source plugin, and if one of those are missing, return zero rows

No longer postponed

Tagging novice for the task of changing the property name. Remember to remove the novice tag when that work is done. Thx

+++ b/core/modules/language/migrations/d7_language_types.yml
@@ -5,7 +5,7 @@ migration_tags:
+  variables_required:
...
 

s/variables_required/variables_no_row_if_missing/

created patch implementing #15. Please review

anushrikumari, thanks for working on this.

1. +++ b/core/modules/language/migrations/d7_language_negotiation_settings.yml
   @@ -5,7 +5,7 @@ migration_tags:
   +  variables_required:
   

   I don't see anything in the issue that says that this file needs to be change. I think this should be removed.

Still needs work for #15, which is to change to the string 'variables_required' to 'variables_no_row_if_missing'.

Resolved points mentioned in #19.

There is 1 fail in test cases, getting this issue.

Drupal\Tests\language\Kernel\Migrate\d7\MigrateLanguageNegotiationSettingsTest::testLanguageTypes
Failed asserting that null is identical to Array &0 (
0 => 'language_content'
1 => 'language_url'
2 => 'language_interface'
).

To answer the question about why the migration is running. The migration d7_language_types runs because language is enabled on the destination and the migration is discovered.

Ah, the suggested approach won't work since we will not get any of the variables if only one is missing. Instead, it should get all the available variables but only if locale is enabled on the source.

The migration does declare locale as the source_module and that is supposed to be used by checkRequirements which will throw an error if the module is not enabled on the source. However, it is not. DrupalSqlBase::checkRequirements uses the source_module from the source plugin annotation. For the variable source plugin it makes sense that the migration can override the source_module declaration.

This patch does that and adds a test that checks the requirements. There is no interdiff because this is a new approach.

Edit: grammar fixes

#22 reminds me of #3176393: Use SourcePluginBase::getSourceModule() in DrupalSqlBase::checkRequirements().

Yes, your are right. Maybe this should be postponed on that.

Then the patch will be this.

Just updating tags,

The Migrate Drupal Module was approved for removal in #3371229: [Policy] Migrate Drupal and Migrate Drupal UI after Drupal 7 EOL.

This is Postponed. The status is set according to two policies. The Remove a core extension and move it to a contributed project and the Extensions approved for removal policies.

The deprecation work is in #3522602: [meta] Tasks to remove Migrate Drupal module and the removal work in #3522602: [meta] Tasks to remove Migrate Drupal module.

Migrate Drupal will not be moved to a contributed project. It will be removed from core after the Drupal 12.x branch is open.