Categorize migrations according to their type

This is a example about Categorize migrations according to their type

+++ b/core/modules/action/migration_templates/d6_action_settings.yml
@@ -2,6 +2,7 @@ id: d6_action_settings
+  - Struct

I think "Configuration" would be better than "Struct" for our tag name here.

That being said - the necessary information is in the destination plugin, isn't it? If the destination plugin is config, or entity:foo where foo is a configuration entity, it's a configuration/structure migration. hook_migration_plugin_alter() could check the destination plugin and set a Configuration or Content tag appropriately.

Now, if we were to do that, should we do it in migrate_plus rather than core?

The patch contains the code for that hook_migration_plugins_alter add Configuration/Content tag to each migration depending the class of destination plugin.

But we have a problem, when it's export configurations doesn't show the tags that have been added, also there the bug that doesn't add "default" value to migrations_group in migration tools, it has as it should be in the case of not having it in configuration. Opened a new issue for this second issue. See #2809703: hook_migration_plugins_alter does not alter permanently

1. +++ b/core/modules/migrate/migrate.module
   @@ -20,3 +20,22 @@ function migrate_help($route_name, RouteMatchInterface $route_match) {
   +      if (is_subclass_of($destination['class'], 'Drupal\migrate\Plugin\migrate\destination\EntityContentBase')) {
   

   Not all content is necessarily an entity. What we should do is set it to Configuration when the destination class is either EntitConfigBase or Config, and default to Content otherwise.

2. +++ b/core/modules/migrate/migrate.module
   @@ -20,3 +20,22 @@ function migrate_help($route_name, RouteMatchInterface $route_match) {
   +      } else {
   

   Coding standards - else should be on a new line.

But we have a problem, when it's export configurations doesn't show the tags that have been added,

Did you do a cache rebuild after adding the hook? The plugins after the alter is applied are cached.

also there the bug that doesn't add "default" value to migrations_group in migration tools

The migration_group support is in the contrib migrate_plus module, I don't see how it's relevant to this core patch?

Here is a small change to the previous patch
These are tests migrations drupal 7 to 8 applying patch code

For tag Configuration

1. Processed 1 item (1 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_block_content_type' [status]
2. Processed 1 item (1 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d7_dblog_settings' [status]
3. Processed 1 item (1 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d7_image_settings' [status]
4. Processed 0 items (0 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d7_image_styles' [status]
5. Processed 1 item (1 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d7_node_settings' [status]
6. Processed 1 item (0 created, 0 updated, 0 failed, 1 ignored) - done with 'upgrade_d7_search_settings' [status]
7. Processed 1 item (1 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d7_system_authorize' [status]
8. Processed 1 item (1 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d7_system_cron' [status]
9. Processed 1 item (1 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d7_system_date' [status]
10. Processed 1 item (0 created, 0 updated, 0 failed, 1 ignored) - done with 'upgrade_d7_system_file' [status]
11. Processed 1 item (0 created, 0 updated, 0 failed, 1 ignored) - done with 'upgrade_d7_system_mail' [status]
12. Processed 1 item (1 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d7_system_performance' [status]
13. Processed 1 item (1 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d7_taxonomy_vocabulary' [status]
14. Processed 1 item (1 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d7_user_flood' [status]
15. Processed 1 item (1 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d7_user_mail' [status]
16. Processed 1 item (1 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_file_settings' [status]
17. Processed 1 item (1 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_menu_settings' [status]
18. Processed 1 item (1 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_search_page' [status]
19. Processed 1 item (1 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_system_image' [status]
20. Processed 1 item (1 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_system_image_gd' [status]
21. Processed 1 item (1 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_system_logging' [status]
22. Processed 1 item (1 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_system_maintenance' [status]
23. Processed 1 item (1 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_system_rss' [status]
24. Processed 1 item (1 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_system_site' [status]
25. Processed 1 item (1 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_taxonomy_settings' [status]
26. Processed 1 item (1 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_text_settings' [status]
27. Processed 1 item (1 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_update_settings' [status]
28. Processed 1 item (1 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_block_content_body_field' [status]
29. Processed 3 items (3 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d7_filter_format' [status]
30. Processed 3 items (3 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d7_user_role' [status]
31. Processed 30 items (10 created, 0 updated, 0 failed, 20 ignored) - done with 'upgrade_d7_block' [status]
32. Processed 1 item (1 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_user_picture_field' [status]
33. Processed 1 item (1 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_user_picture_field_instance' [status]
34. Processed 1 item (1 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_user_picture_entity_display' [status]
35. Processed 1 item (1 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_user_picture_entity_form_display' [status]
36. Processed 6 items (6 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d7_field' [status]
37. Processed 4 items (4 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d7_node_type' [status]
38. Processed 4 items (4 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d7_comment_type' [status]
39. Processed 11 items (11 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d7_field_instance' [status]
40. Processed 4 items (4 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d7_comment_field' [status]
41. Processed 4 items (4 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d7_comment_field_instance' [status]
42. Processed 4 items (4 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d7_comment_entity_display' [status]
43. Processed 4 items (4 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d7_comment_entity_form_display' [status]
44. Processed 4 items (1 created, 0 updated, 0 failed, 3 ignored) - done with 'upgrade_d7_comment_entity_form_display_subject' [status]
45. Processed 3 items (3 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d7_view_modes' [status]
46. Processed 18 items (16 created, 0 updated, 1 failed, 1 ignored) - done with 'upgrade_d7_field_formatter_settings' [status]
47. Processed 11 items (11 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d7_field_instance_widget_settings' [status]
48. Processed 4 items (4 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d7_node_title_label' [status]
49. Processed 1 item (1 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d7_shortcut_set' [status]
50. Processed 4 items (4 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_menu' [status]

For tag Content

1. Processed 0 items (0 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d7_url_alias' [status]
2. Processed 0 items (0 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d7_taxonomy_term' [status]
3. Processed 0 items (0 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d7_custom_block' [status]
4. Processed 6 items (0 created, 0 updated, 6 failed, 0 ignored) - done with 'upgrade_d7_file' [status]
5. Processed 1 item (1 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d7_user' [status]
6. Processed 0 items (0 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d7_node_article' [status]
7. Processed 0 items (0 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d7_node_page' [status]
8. Processed 0 items (0 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d7_node_panel' [status]
9. Processed 6 items (6 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d7_comment' [status]
10. Processed 0 items (0 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d7_node_revision_article' [status]
11. Processed 0 items (0 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d7_node_revision_page' [status]
12. Processed 0 items (0 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d7_node_revision_panel' [status]
13. Processed 4 items (4 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_menu_links' [status]
14. Processed 2 items (2 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d7_shortcut' [status]
15. Processed 0 items (0 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d7_shortcut_set_users' [status]

These are tests migrations drupal 6 to 8 applying patch code

For tag Configuration

1. Processed 1 item (1 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_block_content_type' [status]
2. Processed 0 items (0 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d6_date_formats' [status]
3. Processed 1 item (1 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d6_dblog_settings' [status]
4. Processed 1 item (1 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d6_search_settings' [status]
5. Processed 1 item (1 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d6_system_cron' [status]
6. Processed 1 item (1 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d6_system_date' [status]
7. Processed 1 item (0 created, 0 updated, 0 failed, 1 ignored) - done with 'upgrade_d6_system_file' [status]
8. Processed 1 item (1 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d6_system_performance' [status]
9. Processed 1 item (1 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d6_user_mail' [status]
10. Processed 1 item (1 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d6_user_settings' [status]
11. Processed 1 item (1 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_file_settings' [status]
12. Processed 1 item (1 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_menu_settings' [status]
13. Processed 1 item (1 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_search_page' [status]
14. Processed 1 item (1 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_system_image' [status]
15. Processed 1 item (1 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_system_image_gd' [status]
16. Processed 1 item (1 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_system_logging' [status]
17. Processed 1 item (1 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_system_maintenance' [status]
18. Processed 1 item (1 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_system_rss' [status]
19. Processed 1 item (1 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_system_site' [status]
20. Processed 1 item (1 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_taxonomy_settings' [status]
21. Processed 1 item (1 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_text_settings' [status]
22. Processed 1 item (1 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_update_settings' [status]
23. Processed 1 item (1 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_block_content_body_field' [status]
24. Processed 4 items (4 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_menu' [status]
25. Processed 3 items (3 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d6_filter_format' [status]
26. Processed 2 items (2 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d6_user_role' [status]
27. Processed 14 items (3 created, 0 updated, 0 failed, 11 ignored) - done with 'upgrade_d6_block' [status]
28. Processed 1 item (1 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_user_picture_field' [status]
29. Processed 1 item (1 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_user_picture_field_instance' [status]
30. Processed 1 item (1 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_user_picture_entity_display' [status]
31. Processed 1 item (1 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_user_picture_entity_form_display' [status]
32. Processed 3 items (3 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d6_node_type' [status]
33. Processed 1 item (1 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d6_node_settings' [status]
34. Processed 7 items (5 created, 0 updated, 0 failed, 2 ignored) - done with 'upgrade_d6_field' [status]
35. Processed 7 items (5 created, 0 updated, 0 failed, 2 ignored) - done with 'upgrade_d6_field_instance' [status]
36. Processed 7 items (4 created, 0 updated, 1 failed, 2 ignored) - done with 'upgrade_d6_field_instance_widget_settings' [status]
37. Processed 3 items (3 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d6_view_modes' [status]
38. Processed 21 items (3 created, 0 updated, 18 failed, 0 ignored) - done with 'upgrade_d6_field_formatter_settings' [status]
39. Processed 1 item (1 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d6_upload_field' [status]
40. Processed 0 items (0 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d6_upload_field_instance' [status]
41. Processed 1 item (1 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d6_comment_type' [status]
42. Processed 1 item (1 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d6_comment_field' [status]
43. Processed 1 item (0 created, 0 updated, 0 failed, 1 ignored) - done with 'upgrade_d6_comment_field_instance' [status]
44. Processed 1 item (1 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d6_comment_entity_display' [status]
45. Processed 1 item (1 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d6_comment_entity_form_display' [status]
46. Processed 1 item (1 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d6_comment_entity_form_display_subject' [status]
47. Processed 3 items (3 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d6_node_setting_promote' [status]
48. Processed 3 items (3 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d6_node_setting_status' [status]
49. Processed 3 items (3 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d6_node_setting_sticky' [status]
50. Processed 10 items (10 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d6_taxonomy_vocabulary' [status]
51. Processed 10 items (10 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d6_vocabulary_field' [status]
52. Processed 10 items (2 created, 0 updated, 8 failed, 0 ignored) - done with 'upgrade_d6_vocabulary_field_instance' [status]
53. Processed 10 items (2 created, 0 updated, 8 failed, 0 ignored) - done with 'upgrade_d6_vocabulary_entity_display' [status]
54. Processed 10 items (2 created, 0 updated, 8 failed, 0 ignored) - done with 'upgrade_d6_vocabulary_entity_form_display' [status]
55. Processed 0 items (0 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d6_upload_entity_display' [status]
56. Processed 0 items (0 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d6_upload_entity_form_display' [status]

For tag Content

1. Processed 0 items (0 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d6_url_alias' [status]
2. Processed 0 items (0 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d6_custom_block' [status]
3. Processed 1063 items (0 created, 0 updated, 1063 failed, 0 ignored) - done with 'upgrade_d6_file' [status]
4. Processed 0 items (0 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d6_user_picture_file' [status]
5. Processed 51 items (51 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d6_user' [status]
6. Processed 0 items (0 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d6_node_page' [status]
7. Processed 0 items (0 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d6_node_story' [status]
8. Processed 0 items (0 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d6_node_webform' [status]
9. Processed 0 items (0 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d6_comment' [status]
10. Processed 0 items (0 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d6_node_revision_page' [status]
11. Processed 0 items (0 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d6_node_revision_story' [status]
12. Processed 0 items (0 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d6_node_revision_webform' [status]
13. Processed 50 items (50 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d6_taxonomy_term' [status]
14. Processed 0 items (0 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d6_term_node_1' [status]
15. Processed 0 items (0 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d6_term_node_10' [status]
16. Processed 0 items (0 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d6_term_node_2' [status]
17. Processed 0 items (0 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d6_term_node_3' [status]
18. Processed 0 items (0 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d6_term_node_4' [status]
19. Processed 0 items (0 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d6_term_node_5' [status]
20. Processed 0 items (0 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d6_term_node_6' [status]
21. Processed 0 items (0 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d6_term_node_7' [status]
22. Processed 0 items (0 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d6_term_node_8' [status]
23. Processed 0 items (0 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d6_term_node_9' [status]
24. Processed 0 items (0 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d6_term_node_revision_1' [status]
25. Processed 0 items (0 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d6_term_node_revision_10' [status]
26. Processed 0 items (0 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d6_term_node_revision_2' [status]
27. Processed 0 items (0 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d6_term_node_revision_3' [status]
28. Processed 0 items (0 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d6_term_node_revision_4' [status]
29. Processed 0 items (0 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d6_term_node_revision_5' [status]
30. Processed 0 items (0 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d6_term_node_revision_6' [status]
31. Processed 0 items (0 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d6_term_node_revision_7' [status]
32. Processed 0 items (0 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d6_term_node_revision_8' [status]
33. Processed 0 items (0 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d6_term_node_revision_9' [status]
34. Processed 0 items (0 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d6_upload' [status]
35. Processed 51 items (0 created, 0 updated, 0 failed, 51 ignored) - done with 'upgrade_d6_user_contact_settings' [status]
36. Processed 0 items (0 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_menu_links' [status]

Looks good - but I've had a thought, people might want to specify explicitly the opposite value of the automation determines (e.g., if there's another odd case like ComponentEntityDisplayBase), this should first see whether Content or Configuration is already set and only apply the tag if neither is.

Needs tests - as I suggested to heddn in IRC, that retrieved migrations have the expected tag - I would try one each among the 3 config-based classes, one content entity migration, and one content non-entity migration. And, per above, that explicitly specifying an "opposite" tag does not get overridden.

Thanks.

Just a wee historical and interesting note. Take a look at bullet points 4 and 5 in the first comment at The UI. It mentions having a button for migrating configuration and one for migrating content.

Looks good to me!

I'm not sure this is the right way of doing this. Firstly we probably should be using \Drupal\Core\Plugin\CategorizingPluginManagerTrait to do this. And secondly we probably should not be altering the information in - that feels odd.

Fixed duplication of tags.

Fixed test.

@heddn, I think language related migrations are also missing. Can we add language related migrations to the test? There are some d6_i18n_* ones, d6_language_content_settings.yml for example.

And I think migrate/destination/DefulatLangcode needs to be tagged configuration.

1. Nice test coverage - great to everything in core tested
2. Whilst the trait might not be applicable it'd be great if we can implement \Drupal\Component\Plugin\CategorizingPluginManagerInterface
3. Are we sure that UserData is configuration?

4. +++ b/core/modules/migrate/src/Plugin/MigrationPluginManager.php
   @@ -258,4 +296,24 @@ protected function findDefinitions() {
   +  protected function classInArray($plugin_class, array $classes) {
   

   Rather than introducing a new method for this we could use an anonymous function in the calling code. Ie,

   $is_config_class = function ($class) {
     return $class instanceof EntityConfigBase::class || $class instanceof Config::class || $class instanceof ComponentEntityDisplayBase::class);
   };
   

5. +++ b/core/modules/migrate/src/Plugin/MigrationPluginManager.php
   @@ -258,4 +296,24 @@ protected function findDefinitions() {
   +      if (is_a($plugin_class, $class, TRUE)) {
   

   instanceof is quicker and should work just fine here. See above...

I think need to use is_a because we do not have an object from $destination['class'], only a class name.

@heddn on a feature request it doesn't make any sense to implement an interface on followup - we should be doing this right first time. Also it might affect the implementation.

@Charlotte17 yep you're right re instanceof v is_a. Unfortunately quite a few out-of-scope changes have occurred in #45 and also some additional spaces.

1. +++ b/core/modules/migrate/src/Plugin/MigrationPluginManager.php
   @@ -258,4 +296,51 @@ protected function findDefinitions() {
   +  protected function classInArray($plugin_class, array $classes) {
   

   No longer used.

2. +++ b/core/modules/migrate/src/Plugin/MigrationPluginManager.php
   @@ -258,4 +296,51 @@ protected function findDefinitions() {
   +    $tags = array_column($this->getDefinitions(), 'migration_tags');
   

   So, if we're going to use all migration_tags as categories, perhaps we should deprecate the migration_tags key and use 'category' going forward as is the default in CategorizingPluginManagerTrait? If I had known about that in the first place, I'd have used that instead of migration_tags...

For sorted and grouped, should I duplicate migrations into different categories if they are tagged with multiple tags?

Interesting question. I'd look at other uses of CategorizingPluginManager in core - what do they do?

All migrations have at least 2 tags.

All core Drupal migrations have at least 2 tags. The general plugin manager needs to deal with 0-N categories.

Glancing over the code I picked up one little thing:

+++ b/core/modules/migrate/src/Plugin/MigrationPluginManager.php
@@ -258,4 +296,51 @@ protected function findDefinitions() {
+   * @param array $classes
+   *

Parameter description missing.

On the broader question - it seems that CategorizingPluginManagerInterface, although it isn't explicitly documented that way, assumes a single category per plugin (certainly that assumption is built in to the trait), so using migration_tags with it is an awkward fit. So - what if instead of adding Content and Configuration to migration_tags, we implement them as 'category' and use the trait? migrate_tools would need a new --category option, but that's not a big deal. I think conceptually it makes more sense as well - migration_tags suggests a free-tagging vocabulary, so having the core API reserve special values feels funny (yes, there's 'Drupal 6' and 'Drupal 7' - but those are elements of the upgrade "application", and letting an application implement special meanings for specific tags makes more sense to me).

Thoughts?

Well, I don't consider provider metadata on source/destination plugins to really be a tagging/categorization feature - but still, 3 ways to slice/dice migrations is too many.

The one thing that bothers me a little about #41 is still that certain tags are magical. But, overall, I can live with that I think.

Next step is to reroll #41?

• Setting to 8.4.x
• It seems the patch from #41 does not need re-rolling, but here it is for running past the testbot.

• Removed unused use statement.
• Removed "d7_taxonomy_term" from the tests (I think) because it uses a deriver (like d7_node, which is also excluded).

+++ b/core/modules/migrate/src/Plugin/MigrationPluginManager.php
@@ -62,6 +66,40 @@ public function __construct(ModuleHandlerInterface $module_handler, CacheBackend
+    if (!empty($destination['class'])) {
+      $definition += [
+        'migration_tags' => [],
+      ];
+      $configuration_classes = [
+        EntityConfigBase::class,
+        Config::class,
+        UserData::class,
+        ComponentEntityDisplayBase::class,
+      ];
+      if ($this->classInArray($destination['class'], $configuration_classes)
+        && !in_array('Content', $definition['migration_tags'])
+        && !in_array('Configuration', $definition['migration_tags'])
+      ) {
+        $definition['migration_tags'][] = 'Configuration';
+      }
+      // Default to content.
+      elseif (!in_array('Content', $definition['migration_tags'])
+        && !in_array('Configuration', $definition['migration_tags'])) {
+        $definition['migration_tags'][] = 'Content';
+      }
+    }

Briefly discussed with @heddn on IRC and I'm not sure if this would be the optimal way to proceed. It really should not be up to some code tucked...somewhere in Migrate to decide which categories various destinations belong to. This stuff belongs squarely in the destination plugins' definitions.

Therefore, to that end, I suggest this:

1. Add two new constants to either the Destination annotation class, or the DestinationInterface. TYPE_CONFIGURATION and TYPE_CONTENT, or similar.
2. Add a new property to the Destination annotation, called "type" or something, which if set must refer to one of those constants. There are other examples of a similar approach in core, just not 100% sure where (I think the Filter plugin annotation does a similar thing).
3. Update all the destination plugins in Migrate and Migrate Drupal to include one of these constants.
4. Ensure that all the destination base classes set an appropriate constant in $plugin_definition during their __construct method, so that all destination plugins will always report a valid type.
5. Have the plugin manager leverage this information.

IMHO this would be a much cleaner design that would maintain BC.

1. +++ b/core/modules/migrate/src/Annotation/MigrateDestination.php
   @@ -25,6 +25,10 @@
   +  const CATEGORY_CONFIGURATION = 'Configuration';
   +
   +  const CATEGORY_CONTENT = 'Content';
   

   Should these really be in the annotation class? Why not the destination interface?

2. +++ b/core/modules/migrate/src/Annotation/MigrateDestination.php
   @@ -43,4 +47,14 @@ class MigrateDestination extends Plugin {
   +  public $category;
   

   For that matter, if we never actually use this in the annotations of any core plugins, why add it to the annotation class?

3. +++ b/core/modules/migrate/src/Plugin/MigrationInterface.php
   @@ -322,4 +322,11 @@ public function getDestinationIds();
   +  public function getCategory();
   

   So, this would be a BC break. With a default implementation in the Migration class, and it being unlikely people are implementing MigrationInterface without extending Migration, probably little-or-no real-world impact, but still... it is a BC break in migrate, which is experimental-beta.

4. +++ b/core/modules/migrate/src/Plugin/MigrationPluginManager.php
   @@ -258,4 +264,64 @@ protected function findDefinitions() {
   +      $categories[$key]  = $row['category'];
   +      $labels[$key]  = $row['label'];
   

   Extra spaces before '='.

Overall, this feels to me like a heavy change for functionality which is convenient rather than essential - are we overthinking this? Stepping back a moment, and recalling what we were saying in #56 and #57 - do we *really* need yet another way to group migrations? I feel like the CategorizingPluginManager thing is adding complexity without a clear practical benefit. What would be the simplest way (adding the least technical debt) to leverage migration_tags?

What if we:

1. Don't touch the annotation or migration plugin classes - the plugin manager can access the destination plugin definition 'category' directly.
2. Add the destination plugin's category to migration_tags rather a new 'category' key.

?

Oh, and another thought if we're leveraging migration_tags would be "namespacing" the tags - use something like "Category: Configuration" and "Category: Content" as the actual tag names rather than just Configuration and Content, making our magical tag names less likely to get in the way of whatever tagging people would find natural for their application.

@mikeryan, it seems this change would be great for me. Once the config changes are in place I likely only want to target content migrations for rollback/migrate because the config is done and there seems to be more config migration issues that I run into than content ones, if I had to do those configurations manually it wouldn't be the end of the world.

The namespacing proposed in #71 seems verbose, off hand, but maybe you are seeing something I'm not.

Also this is a API addition, not a BC break, so removing that tag, what is the BC break?

1. Shouldn't this

+++ b/core/modules/migrate/tests/src/Kernel/Plugin/DestinationCategoryTest.php
@@ -0,0 +1,243 @@
+  /** @var \Drupal\migrate\Plugin\MigrationPluginManager $migrationManager */
+  protected $migrationManager;

be written as

/**
 * The migration plugin manager.
 *
 * @var \Drupal\migrate\Plugin\MigrationPluginManager
 */
protected $migrationManager;

?

2.

+++ b/core/modules/migrate/tests/src/Kernel/Plugin/DestinationCategoryTest.php
@@ -0,0 +1,243 @@
+  /**
+   * We cannot call enableModules in setup, so this is broken out.
+   */
+  protected function enableAllModules() {
+    // Install all available modules.
+    $module_handler = $this->container->get('module_handler');
+    $modules = $this->coreModuleListDataProvider();
+    $modules_enabled = $module_handler->getModuleList();
+    $modules_to_enable = array_keys(array_diff_key($modules, $modules_enabled));
+    $this->enableModules($modules_to_enable);
+    $this->installConfig($modules_to_enable);
+  }

I found another way to enable all modules in the setup method, not sure if it's better, but it's shorter:

  protected function setUp() {
    // Enable all modules.
    self::$modules = array_keys($this->coreModuleListDataProvider());
    parent::setUp();
  }

Do we really want this hard-coded array of migrations in the test? This means that if we add a new migration into core, this test will fail, even if it has a Content or Configuration tag.

If we keep the array, can we not fail the test if a migration is not in the array but does have one of the two tags?

We could also add a check to make sure no migration have both tags.

What do you think?

Updated issue summary based on the IRC discussion with @heddn.

Re-roll.

Proposing to bump this to Major.

This is a significant improvement that supports DEV - STAGING - PROD workflow when building upgrades for complex sites where some parts of the config can be migrated but significant amount of D8 site building needs to be done manually.

With the differentiation between config and content, it is possible to migrate the config & content in DEV, build the rest of the config in DEV, then deploy the whole site config to STAGING with the configuration management capabilities and only migrate content on higher environments.

I'm planning to write handbook doc on this approach once we land this, see #2921971: Add a documentation page about configuration vs. content migrations

Cheers,
Markus

Edit: fixed related doc issue number

Fix test failures.
Correct coding standards errors.

address for: #80 and #81.

I have reviewed patch #90.

• We are adding the 'Content' or 'Configuration' tag to all migrations provided by core
• We are adding test coverage that checks that all migrations have either Content or Configuration tag
• The migrations that extend EntityConfigBase are interpreted as 'Configuration' in the tests. There are a couple of core migrations that do not extend EntityConfigBase and these are explicitly covered in the tests.
• The migrations that extend EntityContentBase are interpreted as 'Content' in the tests. There are a couple of core migrations that do not extend EntityContentBase and these are explicitly covered in the tests.

The patch is in line with the issue summary. The issue summary had a question on whether the UI impact should be handled as a follow-up.

• The Drush approach (Migrate Tools) can start using these new migration tags immediately once we land this. No change impact to Migrate Tools, it's just about start using the tags.
• For Migrate Drupal UI (the web browser user interface), there was already a follow-up which we can use for this purpose #2826742: Expose migration types in Migrate UI

I have also reviewed the Change Record and updated it so that it is more reader friendly.

With these comments, all looks good to me. Thank you everyone! RTBC.

Cheers,
Markus

Fixed the remaining tasks in the issue summary to help committers.

+++ b/core/modules/migrate/tests/src/Kernel/Plugin/DestinationCategoryTest.php
@@ -0,0 +1,104 @@
+          if ($migration->getDestinationPlugin() instanceof Config ) {
+              $this->assertTrue(TRUE);
+          }
+          elseif ($migration->getDestinationPlugin() instanceof EntityConfigBase) {
+              $this->assertTrue(TRUE);
+          }
+          elseif ($migration->getDestinationPlugin() instanceof ThemeSettings) {
+              $this->assertTrue(TRUE);
+          }
+          elseif ($migration->getDestinationPlugin() instanceof ComponentEntityDisplayBase) {
+              $this->assertTrue(TRUE);
+          }
+          elseif ($migration->getDestinationPlugin() instanceof ShortcutSetUsers) {
+              $this->assertTrue(TRUE);
+          }
+          else {
+              $this->fail("The migration $id was set as Configuration.");
+          }

I think this can be written a bit simpler. In terms of code paths and readability.

And if you need support, I too agree that this is RTBC

Adding review credit

Committed 7e0ddac and pushed to 8.6.x. Thanks!

Sorry to bring up a problem/question after the commit for the second time this week, but why is there no category tags in d6_node, d7_node, d6_node_revision, d7_node_revision, d6_node_translation, d7_node_translation? And why does the test did not catch those?

It looks like the test is not testing derived migrations...

I tried drush migrate-import --tag=Content and, sure enough, the node migrations did not run.

I'm fine with a follow-up, but since the testing part might take longer to sort out, would it be possible to have two follow-ups, one just for adding the missing tags (so Drush Migrate Tools can start using them, as stated in the IS) and one for testing the derived migrations?

I've cherry picked this back to 8.5.x because the only run-time change is the addition of tags to the migration templates. The code changes are all text. And we want to celebrate the success of the migration initiative getting Migrate API to stable and Migrate Drupal to beta so usability improvements that are as low risk as this seem a really good idea.

#3014629: Document that Configuration migrations can depend on Content migrations is a follow-up for this, an oversight that was not covered here.