Problem/Motivation

the migrate group default tends to get created. there is an 'unguarded' call in the migration generator outside of the drush file, the ai gizmo flagged it as probably the trigger.

In addition there are other drush options that fail kinda silently e.g. if you do not have the taxonomies existing, you can pick nonexistent ones as a text entry etc. The kind of stuff the wizard does not let you do, the drush does let you do. we could make validations somewhere and run them against drush and the wizard UI routes.

Steps to reproduce

i think this happens generally.

Proposed resolution

clean up this default issue. possibly make a test

Remaining tasks

  • Clean up default issue
  • make validators for taxonomy, especially
  • Make a test.

User interface changes

drush could reject invalid taxonomy choices with a message.

API changes

something changing in the migration generator's behavior. additional validators that the drush file can call, or perhaps the generator should call internally instead and report back to drush as a whole.

Data model changes

maybe a different submission from drush to the generator.

Comments

hongpong created an issue. See original summary.

hongpong’s picture

hongpong commented
Title: drush creates default empty migration group » drush creates default empty migration group, allows invalid choices on CLI
Issue summary: View changes
hongpong’s picture

hongpong commented
Status: Active » Closed (duplicate)
Related issues: +#3522658: Is it possible to avoid creating the Default migration after installation?

this is a duplicate of #3522658: Is it possible to avoid creating the Default migration after installation?

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

ressa
he/him
commented
Component: Drush » Code

Yes it looks like a duplicate. Also, this "Default default A container for any migrations not explicitly assigned to a group."-extra migration is also created when you use the GUI to create a migration, so it's not Drush-specific.

This ^^ is what I wrote first, after these steps:

  1. Ran drush site:install
  2. Installed the WordPress Migrate modules, first via Drush then GUI, to cover both scenarios
  3. Checked the Migration status page, which was empty -- No "Default" migration
  4. Checked that "Default" was present after creating a migration, both via Drush and GUI

... but then I saw something weird: I again ran drush site:install and installed the modules, did some other stuff, and for some reason ran drush migrate:status, and I got the "Default"!

$ drush migrate:status
 ------------------- ----------------------- ------- [...]
  Group               Migration ID            Status [...]
 ------------------- ----------------------- ------- [...]
  Default (default)   wordpress_content       Idle   [...]
  Default (default)   wordpress_tags          Idle   [...]
  Default (default)   wordpress_categories    Idle   [...]
  Default (default)   wordpress_attachments   Idle   [...]
  Default (default)   wordpress_comment       Idle   [...]
  Default (default)   wordpress_authors       Idle   [...]
 ------------------- ----------------------- ------- [...]

And it was also now present under drush site:install as well.

So it seems that creation of the "Default" group can be triggered via these actions:

  • Create a migration via Drush or GUI
  • Run drush migrate:status

So it's slightly Drush-specific after all :) Still, the reason is probably best handled in #3522658: Is it possible to avoid creating the Default migration after installation?, preventing the underlying code which creates "Default" from getting triggered.