Problem/Motivation

Add validator class to catch incorrectly created configurations, field choices , etc between both the wizard UI and the drush. It can return messages to both drush and the wizard UI.

This should corral invalid taxonomy choice, invalid form field selections and so on.

Proposed resolution

Add validator class and tests. Loop into the existing workflow and then proceed with refactoring later.

Remaining tasks

  • MigrationConfigurationValidator.php
  • MigrationConfigurationValidator service yml
  • WordPressMigrationGenerator.php calls validator before createMigrations()
  • wordpress_migrate_ui/src/Form/
  • WordPressImportForm.php calls validator in validateForm() in wordpress_migrate_ui
  • calls validator before generator call in drush

User interface changes

Proper rejection messages.

API changes

Moves validators out of wordpress_migrate_ui and into the main module.

Data model changes

Will eventually work with a better formed configuration object in the main generator.

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Comments

hongpong created an issue. See original summary.

  • hongpong committed 47a8c9e0 on 8.x-3.x
    Issue #3579149 by HongPong. Add migration config validator and logger...
hongpong’s picture

Status: Active » Fixed

Going with this for now.

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.

ressa’s picture

Thanks @hongpong, this is a huge improvement and extremely helpful, giving actionable feedback, as can be seen below. Tags, formats, or content types that don't exist are used, and the migration is rejected, and not created. Nice!

$ drush wordpress-migrate-generate /var/www/html/my_wp_export_03_15.xml \
--group-id=my_wp \
--prefix=my_ \
--base-url=https://wp.ddev.site \
--category-vocabulary=tagsZ \
--tag-vocabulary=tagsZ \
--image-field=field_imageZ \
--page-type=articleZ \
--page-body-field=bodyZ \
--page-text-format=full_htmlZ \
--post-type=articleZ \
--post-body-field=bodyZ \
--post-text-format=full_htmlZ \
wp_migrate_drush_logging_level is 7
[DEBUG][file_uri] Checking WordPress export file: /var/www/html/my_wp_export_03_15.xml
[INFO][file_uri] WordPress export file verified: /var/www/html/my_wp_export_03_15.xml
[DEBUG][group_id] Checking migration group availability: my_wp
[DEBUG][group_id] Migration group "my_wp" is available.
[DEBUG][default_author] No default author specified; users will be imported from WordPress.
[DEBUG][tag_vocabulary] Checking tag vocabulary: tagsZ
[ERROR][tag_vocabulary] The tag vocabulary "tagsZ" does not exist.
[DEBUG][category_vocabulary] Checking category vocabulary: tagsZ
[ERROR][category_vocabulary] The category vocabulary "tagsZ" does not exist.
[DEBUG][post_type] Validating content type mapping for WordPress post → Drupal bundle "articleZ".
[ERROR][post_type] Content type "articleZ" does not exist.
[DEBUG][page_type] Validating content type mapping for WordPress page → Drupal bundle "articleZ".
[ERROR][page_type] Content type "articleZ" does not exist.
wordpress_migrate: 4 validation error(s) found. Migrations were NOT generated. Review the issues above and re-run.
-
  id: 'ABORTED: validation errors found'
hongpong’s picture

Thank you ressa! I would honestly for sake of consistency want this to run at the last part of the import wizard UI as well, but I realized that it needs more service dependency injections to be run there. (Or i could put that as a new function in the generator but don't want to. ( #2742283: Validate configuration in WordPressMigrationGenerator::createMigrations for this)

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.