When I try to import a WordPress export, I am running into the following error:

[Thu Oct 31 12:53:25.896923 2024] [php:notice] [pid 28105] [client 127.0.0.1:57012] Uncaught PHP Exception Drupal\\migrate\\MigrateException: "Error message: cURL error 1: Protocol "public" not supported (see https://curl.haxx.se/libcurl/c/libcurl-errors.html) for public://export-file-2024-10-31.xml at public://export-file-2024-10-31.xml." at /Users/testuser/htdocs/demosite.test/web/modules/contrib/migrate_plus/src/Plugin/migrate_plus/data_fetcher/Http.php line 114, referer: https://demosite.test/en/batch?id=236&op=start

Any pointers to work around this issue?

Thanks in advance!

CommentFileSizeAuthor
#11 3484883-MR13.patch2.81 KBmsielski
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

mithun-a-sridharan created an issue. See original summary.

hongpong’s picture

Which version of Drupal is this? Maybe the file handler changed in D11 I am not sure. See #3435726: Drupal 11 compatibility fixes for wordpress_migrate this has come up elsewhere.

vaidas_a’s picture

I'm experiencing the same.

Drupal 10.3.7
wordpress_migrate 8.x-3.0-alpha6

vaidas_a’s picture

The problem seems is wrongly set data_fetcher_plugin: http . It should be data_fetcher_plugin: file

Steps for a workaround:
1. Generate Wordpress migrations (/admin/structure/migrate, click on "+Add import from WordPress" and follow the steps)
2. Export configuration
3. Locate Wordpress migration configuration files (should look like migrate_plus.migration.my_wordpress_attachments.yml where 'my_wordpress' is my mashine name of a Wordpress migration group)
4. Replace "data_fetcher_plugin: html" to "data_fetcher_plugin: file" in all the migration files.
5. Import configuration

Now you should be able to run migrations.

mithun-a-sridharan’s picture

@hongpong: This issue occurs with Drupal 10.3.6 and Drupal 10.3.7.

The file_create_url approach would also be my preferred option, I reckon.

Any insights re. support for Drupal 11?

mithun-a-sridharan’s picture

Dear all,

I tried the approach suggested by @vaidas_a

Though the http error is fixed with this approach, the content isn't importing.

Would this plugin create the destination fields or should they be created prior to import?

msielski’s picture

Agree with comment #5 that the issue is around the data_fetcher_plugin. I think a good fix for this would be to correct it in each of the migrations/*.yml files which are used to make the user-generated migrations. I'm going to create a MR for this.

msielski’s picture

Version: 8.x-3.0-alpha6 » 8.x-3.x-dev
Assigned: Unassigned » msielski

msielski’s picture

StatusFileSize
new2.81 KB

Created an MR for this - hopefully it's the right approach. I'm sharing a patch of the change which may be helpful for people patching.

msielski’s picture

Status: Active » Needs review
ryumaou’s picture

I'm also getting this error on a fresh install of 10.3.7

hongpong’s picture

Status: Needs review » Reviewed & tested by the community

Thanks msielski that appears to be the correct solution, I tested it on Drupal 10.3.8 + Migrate Plus 6.0.4 + Migrate Tools 6.0.5 .. Will put it in.

reference:
- https://www.phase2technology.com/blog/migrating-drupal-alternate-sources
- https://www.drupal.org/docs/8/api/migrate-api/migrate-source-plugins/ove...

hongpong’s picture

Status: Reviewed & tested by the community » Fixed

That is rolled in thank you msielski and ryumaou mithun-a-sridharan vaidas_a !!

mithun-a-sridharan’s picture

Dear all,

Glad to see momentum on this issue.

I tried this approach and don't see errors, which is a good step closer to the solution.
However, the posts, categories and tags are not imported from the WXR file.

My approach was as follows:

# Export the entire configuration
vendor/drush/drush/drush cex

# In the config/sync folder:
# Copy the patch file to the sync folder
mkdir migrations
git apply --index 3484883-MR13.patch

# Move the yaml files back to sync folder

# Import changed configuration 
vendor/drush/drush/drush cim

Is this the right approach to apply this patch?

I wonder why such a convoluted approach - exporting, applying the patch and re-importing the configuration is a better approach than fixing the issue at source using the file_create_url approach.

Furthermore, the user experience in this approach isn't optimal, considering that these migrations mostly happen once when importing content from a different CMS.

PS: I also manually changed the data_fetcher plugin from http to file in the yaml configuration files, yet the posts are not imported.

hongpong’s picture

Hello mithun-a-sridharan,

the patch is already applied to the 8.x-3.x branch but it is not on a tagged release. If you are using 8.x-3.x dev release then the patch should not be needed (will not apply anymore).

You may need to create new migrations again, this patch does not fix ones that are already created.

Status: Fixed » Closed (fixed)

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