Drupal 10.3.3 w/ Migrate plus & tools (6.0.4) and ctools (4.1.0)

I got following error after xml upload.

---
Error message
The specified file example_WordPress_2024-09-11.xml could not be uploaded.
The referenced entity (file_type: undefined) does not exist.
WXR file upload failed. Please try again. Your log messages may have additional information.

---

By 'drush migrate:status',

---
[error] Message: Failed to connect to your database server. The server reports the following
message: /No database connection configured for source plugin variable/.
* Is the database server running?
* Does the database exist, and have you entered the correct database name?
* Have you entered the correct username and password?
* Have you entered the correct database hostname?
-----

I think Migrate core module calls for database connection.

Comments

keithkhl created an issue. See original summary.

keithlee_giai’s picture

keithlee_giai commented

I have uninstalled following modules, which removed above database connection error, but I still cannot run this migration. Despite the error msg, xml files are indeed uploaded, but it is stuck there.

- Migrate Drupal
- Migrate Drupal UI

keithlee_giai’s picture

keithlee_giai commented

I further uninstalled most uninstallable modules, and now it is working. I will later add what module or customization caused the issue.

gord.fisch’s picture

gord.fisch commented

Hi Keithkhl;

Can you specify the state of things when it worked? What was installed? What did you have to Uninstall?

thanks

keithlee_giai’s picture

keithlee_giai commented

@gord.fisch, that was file path module.

It created 'public://' at the front of urls for image, which nullified url rules that wp migrator follows.

I was going to use this plugin, but not any more. It creates db tables that are not in native structure of Drupal. I might have misconfigured, but that's already a big no go. migrating custom post types of wp to drupal's new contents type didnt work neither. image urls were not properly changed, and some images missed drupal's uuid creation.

I could debug and fix one by one, but i would rather pay a few thousand bucks to human migration. this will be way less prone to errors.

hongpong’s picture

hongpong commented
Status: Active » Postponed (maintainer needs more info)

I believe this issue is now fixed on the dev branch re #3484883: Protocol "public" not supported. Please re-open if it is still giving the public URL issue.

Regarding db tables outside of native structure can you be more specific?

This module is maintained by volunteers, and has patches that need review from other volunteers as well. Thank you!

keithlee_giai’s picture

keithlee_giai commented

instead of node_xxxx datatables, the module gives me an option to create my own name of node's datatables.
And, for featured images and custom posts, each had it's own node type, so after migrating 3 custom post types from WordPress, I had 6 new node-like datatables, but slightly different structure from Drupal's native node.

Because of the difference, many Drupal modules were incompatible.

Besides, the module did not migrate other key values of WP posts, such as category, SEO summary, keywords, and etc.

In the end, I paid a few thousand bucks to copy and paste each post by human.

I appreciate the volunteer group's hard work on this module, but as for a long time WP user, I have almost given up migrating to Drupal largely because of this module's limited capability. I had no alternative due to my company's situation, but not that many people will go for human migrator and pay $$$.

If Drupal wants to grow user base, I think this is the very first module that has to be massively upgraded.

ressa’s picture

ressa
he/him
commented
Related issues: +#3173973: Pluggable extension, support contrib + custom WordPress, Yoast SEO

Thanks for the feedback @keithkhl. I agree that Drupal could grow its user base if this module got even more features, supporting import of keywords and SEO summary. About pages and categories, I do read this on the project page:

Import of WordPress posts, pages, comments, attachments, tags and categories is supported. Imports can be rolled back completely.

As you comment, the module is maintained by the community, but the maintainers are also developers. So those few thousand bucks spend copy-pasting content could in theory have paid for a developer to create this feature for you, and the entire community could have benefited form these new options.

It's too late now of course, but anyone else finding this post should definitely consider reaching out to @hongpong or another maintainer for features needed, budget, and timeline. If @hongpong or other maintainers don't have time, I am sure they can propose other competent Drupal developers to help out.

About importing custom fields, I got this reply the other day by @msielski in #3173973: Pluggable extension, support contrib + custom WordPress, Yoast SEO:

@ressa I am hoping to use the plugin architecture from this issue to start working on an ACF plugin. I'll open a issue for it sometime soon.

So if all goes well, import of custom fields will at some point be possible.

ressa’s picture

ressa
he/him
commented
Related issues: +#3247389: Plan for stable release

#3247389: Plan for stable release for Simplenews is an example of sponsored module development, which resulted in the module getting a stable release.

The sponsor of the upgrade (think modular) is now listed on the Simplenews project page under "Supporting organizations":

Supporting organizations:

keithlee_giai’s picture

keithlee_giai commented

@ressa, as much as I respect your suggestion and this whole Drupal dev community, after seeing what this module does to the test site, I was really afraid of losing money again on dev. I have lost $$$ to dev from a variety of platforms and projects, including in house services, and unfortunately given that WP migration module has been maintained over 10+ years in Drupal community, while WordPress's DB handling has almost not changed at all, if it still has these many bugs for basic functions, it was really hard for me to trust any dev on this module.

Sorry to be really harsh on commenting like this, but as for a 'wannabe' dev friendly person as in that I do frequently sponsor open source module customizations and sometimes fix minor bugs / version compatibility issues by myself, after finding out that 'public://' was the very cause of my lost hours, it was hard to convince myself to ask for further developements. It might not make sense from dev's point of view, but as a project manager with limited successful project experience, your current code and code upgrade history are the only two reliable indicators of the dev's capability.

Besides, from dev's point, every additional function may be seen as an incremental improvment, but for business people who pays for it, it is mostly 0 or 1. Partial solution still requires human back up, which means hiring relevant people, train them with relevant information, and monitor the outcome. Unless it is a complete solution, it really isn't much of a 'solution'.

I will probably never need this module again, but for other people suffering from WP's limited capability, I do hope that they get benefited by this migrator's massive upgrade.

ressa’s picture

ressa
he/him
commented

Thanks for the reply @keithkhl. I understand, many people have been burned over the years in IT projects ... As we agree, your task has been solved, so our comments here are mainly directed at people later finding this issue. And like you write, hopefully version 3.x beta fixes those basic problems you mention.

And I do think you are little bit too harsh. You reported the issue 11 September 2024 and it was fixed 14 November 2024 in #3484883: Protocol "public" not supported two months later. I think that's pretty fast. Also, about the problem:

[...] unfortunately given that WP migration module has been maintained over 10+ years in Drupal community, while WordPress's DB handling has almost not changed at all, if it still has these many bugs for basic functions, it was really hard for me to trust any dev on this module.

That's not a correct analysis of the problem. It happened because Drupal's file handling changed. This happens, and then we need to update the code.

Like @hongpong who graciously maintain and expand the module with features commented:

This module is maintained by volunteers, and has patches that need review from other volunteers as well. Thank you!

Also, here's a tip, for people finding this issue later: If a WordPress to Drupal migration is slightly more complex, using Drupal core Migrate module with Migrate Plus and Migrate Tools instead is probably a better idea. And speaking of hiring developers, I can wholeheartedly recommend Migrate modules' maintainer @heddn and his team at Mtech. They have previously assisted me with very complex migrations, and always delivered on time, and at a very reasonable price.

ressa’s picture

ressa
he/him
commented

PS. I looked at some of your issues @keithkhl, and thanks for creating them, and getting things moving, testing features, proposing new solutions, etc. It keeps Drupal moving in the right direction :)