Thanks for the fresh release, and Drush 13 support!
I wanted to update https://www.drupal.org/docs/extending-drupal/contributed-modules/contrib... and went through the steps. All worked well, until I ran into an error when I ran this command:
$ drush migrate:import --all
[error] Migration my_wordpress_comment_post did not meet the requirements. Missing migrations my_wordpress_content_post. In MigrateToolsCommands.php line 1184: my_wordpress_comment_post migration failed.
It seems to block other migrations from completing, and I needed to click "Execute" via the GUI for those migrations to run.
Also, it seems that if I run drush migrate:import my_wordpress_comment_page first, it seems to take care of the problem.
But ideally, it would be nice if drush migrate:import --all could complete without errors.
GUI created migration
drush migrate:import --all and get an errorDrush created migration
Place the export file in the root of the installation, and run this Drush command, to direct all content to the "Article" content type:
drush wordpress-migrate-generate /var/www/html/my_wp_export_03_15.xml \
--group-id=my_wp \
--prefix=my_ \
--base-url=http://ddev-wp-web \
--category-vocabulary=tags \
--tag-vocabulary=tags \
--image-field=field_image \
--page-type=article \
--page-body-field=body \
--page-text-format=full_html \
--post-type=article \
--post-body-field=body \
--post-text-format=full_html"categories from WordPress XML blog_wordpress_categories" are imported via GUI or Drush into "Tags", so the file can be seen, and content imported:
Status message
Processed 31 items (31 created, 0 updated, 0 failed, 0 ignored) - done with 'blog_wordpress_categories'Nodes (like "Import content from WordPress XML blog_wordpress_content_post") are not getting created:
Status message
Processed 0 items (0 created, 0 updated, 0 failed, 0 ignored) - done with 'blog_wordpress_attachments'
Processed 0 items (0 created, 0 updated, 0 failed, 0 ignored) - done with 'blog_wordpress_categories'
Processed 0 items (0 created, 0 updated, 0 failed, 0 ignored) - done with 'blog_wordpress_tags'
Processed 0 items (0 created, 0 updated, 0 failed, 0 ignored) - done with 'blog_wordpress_content_post'
From the error log:
Missing bundle for entity type node (/var/www/html/web/core/lib/Drupal/Core/Entity/ContentEntityStorageBase.php:132)
Show commandsStart 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:
changes
Comments
Comment #2
hongpong commentedThanks for testing this new kaboodle!!
Enable configuration manager core module and try checking the configuration entities: /admin/config/development/configuration . Go into Migration then Configuration name down to the problem one.
I think if you can examine the entities at /admin/config/development/configuration/single/export/migration/my_wordpress_comment_post or similar that would be helpful.
when i do it by gui the only migration_dependencies for post are
my hunch is that yours is not like this perhaps. Generally the fault would be around in there.
( I updated our issue template to point attention to checking in this)
... Upon more checking when I try running that command I am also getting odd migration jobs that are not even ones that are named in my system . So something is hinky for sure.
drush migrate:import --all -vvvfor verbose output.Comment #3
ressaThanks for a fast reply!
I checked under that path, and this is what I see:
I did not include it, but this a plain vanilla Drupal 11.3.5, built with the steps from the DDEV Quickstart, in case it makes a difference.
I originally generated content with FakerPress of Users, Terms as well as Posts, Attachments and Comments. Second time, I did not generate Comments, but still saw the issue. Maybe you could try with all possible types of content, comments, etc. as well?
Under the Migrate Wizard settings I chose "Tags" for all tags, used the "Article" content type for both "Posts" and "Pages", and "Full HTML" for format. If it's useful I can easily supply a more detailed list of the options I used, just let me know, or if you need anything else.
Comment #4
hongpong commentedI also used ddev and approximately get the same thing I think. We will probably need to hook into more logging to understand WTF is going on here. ( with luck maybe I can get some more on this saturday at the drupal meet in NJ)
update - also unless i missed it we do not enforce comments module being turned on which might be affecting the comment import gizmo. especially drush would not have any check on this.
Comment #5
ressaYes, the comment module was also on my radar. So I checked, and it's installed by default in a fresh Drupal 11 installation ("plain vanilla Drupal 11.3.5, built with the steps from the DDEV Quickstart") and a Comment field is included for the Article content type.
So Drupal seems ready to accept comments.
Eventually, it would be nice if importing comments could be optional, but getting it to work would be a great first step, and optional comment import can always be dealt with in a follow up issue, if it's relevant.
It sounds fantastic that you may be able to take a closer at this with other Drupalers, have a nice weekend.
Comment #6
ressaI wanted to try to automate the configuration process with Drush, and it works partially, but is slightly more fragile than via GUI configuration.
I placed the export file in the root of the installation, and used this Drush command to direct all content to the "Article" content type:
I can import "categories from WordPress XML
blog_wordpress_categories" just fine via GUI or Drush, the categories get imported into "Tags", so the file can be seen, and content imported:But nodes (like "Import content from WordPress XML blog_wordpress_content_post") are not getting created. I see this:
... and in the in the error log:
Missing bundle for entity type node (/var/www/html/web/core/lib/Drupal/Core/Entity/ContentEntityStorageBase.php:132)I added this additional Drush configuration observation in the Issue Summary as well, under "Steps to reproduce".
Comment #7
ressaFix Issue Summary markup.
Comment #8
ressaComment #9
ressaJust another observation. I tried creating the same migrations as identical as possible (first GUI) and this is what I see when I export the configuration made with Drush. It looks like the only difference is this (twice), not included when using Drush:
... and the way the path to the import file is stored:
The full feedback:
Comment #10
hongpong commentedReally good digging. I have added the missing body fields at least into the drush commands - will push on mr here. it still gives me issues. ( this shows the enforcement of migrate order should be working.
Migration mymy1wordpress_comment_post did not meet the requirements. Missing migrations mymy1wordpress_content_post. In MigrateToolsCommands.php line 1184: mymy1wordpress_comment_post migration failed.I think this could really be a failure in the field mapping inside post migrate. right now I have set post_body_field_type and page_body_field_type to save as null in the config from drush command unless otherwise specified. this value should be updated / passed in by command line. (the new validator function will check these field values and report if its invalid, is my goal)
For starting this MR: I think you will get better results in config though, I now added:
#[CLI\Option(name: 'post-body-field', description: 'Machine name of Drupal field name to hold imported post content.')]
#[CLI\Option(name: 'post-body-field-type', description: 'Machine name of Drupal field type to hold imported post content.')]\
and same for page.
and tweaked for drush:
tree:
going to push on the MR and add validator class, and a logging class, and wire into drush first, since it assembles the configuration object, before passing it to the migration generator, we should validate it there. i added some todo comments to show where this would be going. also changing us to require ^6.0.9 migrate_tools to deal with the plugin generator.
Comment #12
hongpong commentedI put the validator / logger stuff here - https://git.drupalcode.org/project/wordpress_migrate/-/merge_requests/45 part of issue: #3579149: Create validator classes MigrationConfigurationValidator + ValidationResult
Can be setup to give better logging all around, will go with the validator to catch all the things going on.
Comment #13
ressaThank you so much, it works much better now. Improving (or adding) a better validator/logger feature in the other issue, and adding config options for Body are really great improvements!
drush migrate:import --allstill fails, so I do need to perform some extra steps (or at least in the right order) but the process can now be completed, so the rest is details :) ... I'll be ready to test further tweaks to the code:I need to import attachments first (
my_wordpress_content_postrequires it):drush migrate:import my_wordpress_attachmentsNow I can import posts:
drush migrate:import my_wordpress_content_post... and I can finally run the full import, without any errors:
The migration is complete, hurray! 🎉
A detail: Is it possible to list the Drush confirmation message like this? (not super important, I just prefer it as compact as possible)
... the current format of the list:
During testing, I was reminded about this ... I may even have created an issue about this before? I just could not find it:
#3579327: HTML in Body field of a migration is not used, until the node is saved
**
I'll share my set up, in case I (or someone else) needs it in the future:
UPDATE 18 march 2026 there has been two great improvements, so updating tips below accordingly:
http://ddev-wp-web)1. SET UP
2. TEST
Comment #14
hongpong commentedThanks this is very helpful . I am going to post the larger validator and logging updates, onto. https://git.drupalcode.org/project/wordpress_migrate/-/merge_requests/45 .. hopefully this give us the good logging to crack these other things.
I also found that the drush migrate group import command would not work - that is unclear to me what the issue is.
Comment #15
ressaThat sounds fantastic, please let me know if I can help test the new validator and logger feature, and what I should look out for.
About using
--groupwith Drush I believe I have tried to use it previously for standard migrations, but never had much luck with getting it work ... But after experimenting with the--tagparameter, I managed to be able to run clusters of migrations withdrush migrate:import --tag=content_all.I looked around, and just now found this:
From https://www.drupal.org/docs/drupal-apis/migrate-api/executing-migrations...
So perhaps
--grouponly works if https://www.drupal.org/project/migrate_manifest is installed?Comment #16
hongpong commentedmigrate_manifest doesn't seem to be supported anymore, it looks like. Super pesky. Anyways I have gotten the logging working on drush (along with the critical fixes for command line arguments) so I will add that to 8.x-3.x . Still doesn't resolve this issue however.
Comment #18
ressaThanks for the hard work here!
Some good related news: It seems like DDEV is now able to connect to another DDEV instance directly, and not as previously where using the internal Docker hostname was required. This is a great improvement, since the internal Docker hostname is a bit cryptic, and can be hard to find:
I updated the documentation page, and the instructions are now a little easier to complete: https://www.drupal.org/docs/extending-drupal/contributed-modules/contrib...
Comment #19
starlight-sparkleHi all, I was looking for similar error messages in custom migrations and happened to stumble upon this issue thread.
I am not using wordpress_migrate, but rather my own hand-written migration ymls, and observed that it seems
drush mim --tag=[tag](or any other command that imports multiple migrations) simply never tries to sort by dependency graph at all and always just runs migrations in alphabetical order.What I discovered was that when migrate_run was merged into Drush Core, the implementation of
migrate:importcommand that was merged simply did that by design.Code excerpt:
It does not provide the same dependency checking provided by the
migrate:importcommand from migrate_tools, which is what most Drupal 8 era devs will be used to.Code excerpt:
The effect is that depending on the combination of module versions and drush versions you have installed, you could be running the command from Drush Core, or the command from Migrate Tools, and they behave differently.
Comment #20
hongpong commentedthank you starlight-sparkle. it reminds me i saw just recently in the #migration slack something similar, maybe the same issue. https://drupal.slack.com/archives/C226VLXBP/p1773935360368689 . also this may be related: #3572002: migration_dependencies.optional ignored since 6.1.3 and #2969227: 'migrate status MIGRATION' loads every migration. could see if migrate_tools 6.1.2 does not have the issue? It does seem like an upstream regression because I am fairly sure I remember this module executing things with actual reference to the dependencies. benjifisher noted "Migrate Tools is relevant, since it overrides some of the default Drush commands."
if someone has the time to check if the dev branch of migrate_tools repairs this issue that would answer the question. there is a purported fix already committed but not on tag release. ( when a tagged release comes out I could tick the requirements to match it because of this, if it is indeed the case)
Comment #21
ressaThank you @starlight-sparkle and @hongpong, great digging and sharing of information and links to related issues.
I tried the dev-version of Migrate Tools and have good news: The requirements are used, so
drush migrate:import --allcompletes in the first try, and I am happy to set this issue to "Closed (cannot reproduce)" :)PS. A few Page comments are unprocessed, but that can be handled in #3580225: Add support for setting comment destination.
Comment #23
ressaComment #24
starlight-sparkleOne question: is there a reason this module's info yml doesn't enforce the enablement of migrate tools, even though it's required in composer.json?
Comment #25
ressaJust adding related issue.
Comment #26
ressaComment #27
ressa... and updating title :)
Comment #28
ressaThat's an interesting question @starlight-sparkle. Only WordPress Migrate UI seems to require Migrate Tools, and running a Drush migration without installing neither WordPress Migrate UI, nor Migrate Tools works well:
Comment #29
ressaAdding correct solution issue in issue summary here.
Comment #30
ressaComment #31
ressaComment #32
ressaAdding tip that Migrate Tools 6.1.4 has been released.