Create an audit plugin class/manager for migrations

So, I've given this some further thought, and I think the basic premise of the audit plugin idea could work. I have some specific thoughts outlined below:

These core plugins should only target D7 migrations, I don't think there is enough value in extending the system to work for D6 in core. The system could be built in such a way that d6 audit plugins might be built in contrib.

The audit plugin should have access to the legacy database, legacy files location, and the D8 container (through normal DI). Using these, the plugin should be able to determine if a particular problem will exist in the migration, and be able to generate a form structure that collects enough information to solve it.

For example, by scanning the d7 filter table and collecting a list of filter names and then checking the filter plugin manager for the existence of those filters, it should be able to determine which ones are missing, and generate some specific options for the user,( ie. install the missing module, skip the filter on this format, replace this format with that format.. specifics TBD, and we may want to handle the php_code format and filter specially. In fact, for this particular issue, we may want to go even simpler and just manage the php_code issue (since that used to be a core filter) and just tell the user they can install the contrib module (not recommended) or have the boolean choice of leaving the filter_null replacement like we currently do, or removing the filter. Security team might have opinions on this one too.)

The plugin should be able to validate and store the result of the form. I think state key/value storage should work fine for this, but we could consider other options.

I do not believe the data should be accessed from process or destination plugins. I think use of the data should be limited to modifying the migrations themselves before they run. I think this is the easiest way to guarantee that the base migration system continues to work outside of migrate_drupal. If a core module provides one of these audit plugins along with a source plugin specific to a drupal 7 migration, I might consider allowing the data to be used there, for example to modify a query, but only if we have to. My preference would be to leave use of this data to implementations of hook_migration_plugins_alter, and the prepare_row hooks. If we find a situation that needs something else, I would like to add a hook or event to use rather that adding code specific to these audits into source plugins. We may need to revisit #2904765: Alter derived migration definition early in life for example.

Finally, for the best UX across the board, we may find we need to duplicate this information gathering on the CLI in contrib migrate_upgrade. If we can somehow find a way to keep the detection logic separated out such that contrib can use it to collect the same data on the CLI without duplicating things too much (even if it does need to have some custom code per core plugin to work, it would still be doable, if we end up with half a dozen or so of these in core), I think that would be ideal.

In general, I like the idea.

#2++++++

Could you add concrete examples of audit plugins that could be added? Which ones are you thinking of that would have the highest impact?

Linking in the UX issue. I think the biggest bang for our buck would would be for " filter formats".

@Wim see https://www.drupal.org/docs/8/upgrade/known-issues-when-upgrading-from-drupal-6-or-7-to-drupal-8#s-drupal-7-to-8 . Looking now, that page might need some updating, but off the top of my head:

• filter formats, especially php_code: detect and handles as mentioned above
• having the ability to detect and offer to remove the article comment field, and otherwise manage some of the defaults in the standard install profile that can cause problems.
• Detecting and managing text fields that have conflicting field instance settings and offering a solution rather than skipping and logging. This will be tricky, but I think doable. We should be able to create new fields and manage keeping the content, but it necesssarily means some fields will have new names. Being able to give the user options of separating and renaming, or moving everything over to one field storage and alerting them of the possible concequences would be a very helpful plugin. Currently migrate just skips these field completely, and you need to go to that known issues page to find out that you have to change your D7 settings in order to get that content migrated.

Meantime there's existing implementation for views using following naming https://api.drupal.org/api/drupal/core%21modules%21views%21src%21Analyze...

Thanks, @mikelutz, that helps a lot :)

FYI: @slv_ from Lullabot maintains the migrate_expansion module, which provides Drush commands with audit-like abilities:

• text format usage: https://git.drupalcode.org/project/migrate_expansion/commit/7f3347f615fa...
• field usage across bundles: https://git.drupalcode.org/project/migrate_expansion/commit/4675e2554303...

Discussed briefly on a migrate call today. This isn't 'migrate critical', the intent of that tag is to get deprecation done in a timely fashion.