Rewrite local link/image references in content, switch image content domains

Hello All, I am trying to migrate big blog site to D9 and my images are not getting migrated to the D9.

How do I migrate image first and then run the blog migrations. I appreciate the help.
using D9 with following migration modules and wordpress_migrate latest alpha5 release.
drupal/migrate_manifest 3.0.2 Supports the running of migrations using a...
drupal/migrate_plus 5.3.0 Enhancements to core migration support.
drupal/migrate_source_csv 3.4.0 CSV source migration.
drupal/migrate_tools 6.0.2 Tools to assist in developing and running ...
drupal/migrate_upgrade 3.2.0 Drush support for direct upgrades from old...

It would be nice to be able to import images as well, they are after all present in most web sites :)

It looks like image import is supported, reading this in the README:

Importing Image Assets

For the new importation of attached images including post thumbnails (also known as featured images) you should:

• Assign an image field for these assets in the migrate process.
• Before importing the content posts, import the media assets.
• Import the media assets.

https://git.drupalcode.org/project/wordpress_migrate#importing-image-assets

But do I need to install the Media module, and create image fields of type Media first? I tried adding a Media field to the standard Article content type, but I still only get the standard field_image offered under /admin/structure/migrate/wordpress_migrate/image_select ...
(EDIT: No, see next comment)

I also tried to import the wordpress_attachments migration as the first import and then content, but it looks like no images are getting imported. (I assume "import the media assets" means wordpress_attachments in the migration, but I am not sure ...)

It would be great to get some more details added to the minimal steps required for this to work. Thanks!

PS. It is not clear to me, if this is the existing source WP site, or the target Drupal site URL you need to enter here:
"Enter 'Base url of the WordPress site' into the first stage of the wizard to automatically generate permalinks to the new content nodes."

I found an issue about adding Media support, which will be awesome to get! So that answers my question about that.

I was using two local DDEV instances, and finally figured it out, and will add the steps in https://www.drupal.org/docs/extending-drupal/contributed-modules/contrib....

Sorry for the noise.

But back to this issue, and just confirming that it still needs to be looked at: Like I wrote, I am testing in DDEV, with two local instances (from https://my-wp-site.ddev.site to https://drupal.ddev.site), and the domain in inline image links remains to be the original ... like this (it should be https://drupal.ddev.site):

http://ddev-my-wp-site-web/wp-content/uploads/2025/05/29d82e28-5fe8-3a88...

Where I left off the WIP on #3173916: Import as media I was trying to clean up how it loops thru the content types (posts, pages) and bumbled something in the for loop key line at https://git.drupalcode.org/project/wordpress_migrate/-/merge_requests/39... - and consequently this function was not getting the right params . public function CreateSingleMediaTypeMigration($migration_id, string $media_type_id, $process, string $config_key): void {

regarding : "Enter 'Base url of the WordPress site' into the first stage of the wizard to automatically generate permalinks to the new content nodes."" . this could be clarified as it is going to be used to form the pathauto entries locally and is used to search the XML file for old GUID type entries of the current, permalinkified url. those values would be the domains it is exported encoded as is. (sorry getting tired here)

regarding fixing attachments i have also been wondering how it should behave when there are none to be fetched, via unavailable domain or etc. it could be guided to manually seek a different domain provided by import user with an additional text field ("attempt to fetch and then save images from the following URL domain, instead of the base URL domain") would serve such a purpose. you could then be slurping the assets from that kind of temp subdomain into your prod site.

regarding this issue and rewriting links this could be implemented by a migration extension plugin for inline text, iframe codes and so on.

adding #3518677: attachments / featured images not fault tolerant if missing regarding behavior for missing media. which could include missing domain or 404 specific images, timeouts etc.

I believe this can help
https://git.drupalcode.org/project/wordpress_migrate/-/merge_requests/47...

Thanks @hongpong, #3518677: attachments / featured images not fault tolerant if missing is a clear and really helpful improvement, and the work is already paying off, since I now see warnings from Drush during migration import (from wp.ddev.site to drupal.ddev.site):

[warning] Attachment post_id 121 ("Picsum ID: 170"): replacement_domain "constants/replacement_domain" could not be parsed. Using original URL "https://wp.ddev.site/wp-content/uploads/2026/03/f3eba549-9754-3f41-8c94-370a7aba5aca.jpg".

In the created node I see this, which points to the original WordPress installation:
<img class="alignright" src="https://wp.ddev.site/wp-content/uploads/2026/03/3d31df2b-bfa9-35b1-b6c4-e7db0dc7a14a.jpg">

It would seem to me, that two things need to happen, where the import part seems to work well, so the content domain re-mapping is what's missing:

1. Inline images in the Body field should get imported into Drupal -- these are "Attachments" files in WordPress
   Imported into this folder: https://drupal.ddev.site/sites/default/files/featured_images/3d31df2b-bf...
   Under https://drupal.ddev.site/admin/content/files, listed as:
   3d31df2b-bfa9-35b1-b6c4-e7db0dc7a14a.jpg image/jpeg 31.22 KB Permanent Mon, 16 Mar 2026 - 14:41 Mon, 16 Mar 2026 - 14:41 0 places
2. The domain needs to be updated, for example from wp.ddev.site to drupal.ddev.site

I have updated the Issue summary, as far as I understand what needs to be done (I am trying to understand how it all ties together, as we go along) so feel of course free to correct any errors.