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!
| Comment | File | Size | Author |
|---|---|---|---|
| #11 | 3484883-MR13.patch | 2.81 KB | msielski |
Issue fork wordpress_migrate-3484883
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
Comment #2
hongpong commentedWhich 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.
Comment #3
hongpong commentedadditional info
- https://www.drupal.org/forum/general/general-discussion/2024-05-20/publi...
- https://www.drupal.org/docs/8/modules/webform/webform-frequently-asked-q...
- https://www.drupal.org/docs/getting-started/installing-drupal/some-direc...
we may need something like:
$url = file_create_url($uri);Comment #4
vaidas_a commentedI'm experiencing the same.
Drupal 10.3.7
wordpress_migrate 8.x-3.0-alpha6
Comment #5
vaidas_a commentedThe 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.
Comment #6
mithun-a-sridharan commented@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?
Comment #7
mithun-a-sridharan commentedDear 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?
Comment #8
msielskiAgree 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.
Comment #9
msielskiComment #11
msielskiCreated 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.
Comment #12
msielskiComment #13
ryumaou commentedI'm also getting this error on a fresh install of 10.3.7
Comment #14
hongpong commentedThanks 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...
Comment #15
hongpong commentedThat is rolled in thank you msielski and ryumaou mithun-a-sridharan vaidas_a !!
Comment #16
mithun-a-sridharan commentedDear 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:
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.
Comment #17
hongpong commentedHello 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.