Move migratefield plugins to migrate drupal

Yes, I did get that wrong.

Let's see how this goes.

The last submitted patch, 7: 3332224-7.patch, failed testing. View results →

Restore the name of the md_empty plugin

The last submitted patch, 9: 3332224-9.patch, failed testing. View results →

Forgot to delete the original Number and EntityReference annotation.

Ran a search for @MigrateField

Should the files in link and telephone be moved also?

Yes, I missed a few.

The last submitted patch, 13: 3332224-13.patch, failed testing. View results →

Fix the field plugin tests. Added \Drupal\migrate_drupal\Plugin\MigrateFieldPluginManager::getDefinitions() so that the field plugins can be filtered by the destination module. That is filter out those for modules not installed.

The last submitted patch, 15: 3332224-15.patch, failed testing. View results →

Fix namespace error for d6/LinkFieldTest.
Use the injected module handler in MigrateFieldPluginManager. And then make changes for the failing MigrateFieldPluginManager tests. It was good to see that the field plugins in the test modules had to have their destination_module change so that the field plugin would be discovered.

Re-searched @MigrateField and everything appears under migrate_drupal

Hi I have created an MR . Please merge thanks.

@kunal_sahu thanks for the interest but the patch #17 was already reviewed. So the MR is just reuploading the work that was already done. So removing credit for that unless there was something you were fixing.

Thanks

@smustgrave, thank you for the review and confidence in the work.

This does need more eyes on it so I am setting back to NR and tagging for subsystem maintainer review.

My previous comment failed to explain that this work is a part of the bigger task of moving migrate drupal code into the migrate_drupal module. It is a big task and we are exploring sensible ways to scope the work. This issue is for investigating moving the migratefield plugins as a set. We don't know if this is the best approach or if the committers will approve it. This isn't ready for other tags, so staying with 'subsystem maintainer'

Draft CR added.

FWIW change record makes sense and not sure if any of the subsystem maintainers of the module losing their migration files would object. Seems moving the plugins as 1 chunk doesn't seem terrible.

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

Apart from a re-roll or rebase, this issue may need more work to address feedback in the issue or MR comments. To progress an issue, incorporate this feedback as part of the process of updating the issue. This helps other contributors to know what is outstanding.

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

Updating tags

Just a reroll.

This is moving all the field plugins and introducing filter on their discovery. I am wondering if the new filtering should be done in a separate issue with one or two field plugins as an example?

I don't think I can remove the architectural tag

But if something can be broken off into a follow up I would vote yes as it's easier to search for 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).

Migrate Drupal and Migrate Drupal Ui are to be removed from core without replacement, this should not be needed.