6.06 breaks WP Migrate DB Pro migrations

I didn’t make any changes to the table name in 6.0.6. The only thing I changed was the uninstall.php file. So the code where you get the error is exactly the same in both versions. Not sure why 6.0.6 would cause an issue and 6.0.5 would not.

Hi Jeff,

Just in case I didn’t isolate the problem properly I just tried again – upgraded to 6.06, tried to migrate and got this same error:

Unable to connect to the remote server, please check the connection details – 500 Internal Server Error (#129 – scope: ajax_nopriv_flush)

Reverted back to 6.05 and migration goes through successfully. No other settings/options were changed with WP Migrate DB Pro or Plugin Organizer.

Let me know if there’s anything else I can do to help.

Ok I just realized what the problem is. You are probably running windows. Your mysql installation is ignoring case in the table name and trying to rename a table that doesn’t exist to a table name that already exists. When you go back to 6.0.5 you aren’t calling the activate function so it isn’t trying to rename the table. This would cause other problems for you and others in the future. I just released 6.0.7 which compensates for the OS ignoring case so it won’t try to rename the table if your OS doesn’t care about case.

Hey Jeff,

I’m not running windows. Migrating from local (Mac OS X El Capitan 10.11.5) to live (Ubuntu 12.04.5 LTS (GNU/Linux x86_64)).

In any event I will give 6.0.7 a go and report back.

Thanks!

OS X also ignores case.

Still getting the same error with 6.0.7:

Unable to connect to the remote server, please check the connection details – 500 Internal Server Error (#129 – scope: ajax_nopriv_flush)

This error occurs at the end of the migration.

Are you getting the same DB errors?

This is the error I am getting on the remote site in debug.log

[30-Jun-2016 16:10:02 UTC] PHP Notice: Undefined index: HTTP_USER_AGENT in xxxxx/wp-content/mu-plugins/PluginOrganizerMU.class.php on line 355

But that’s just a notice – I don’t think it would break the migration. Other than that and the error above, that’s it.

Without a specific error to track down I can’t really figure out what the problem is. The PHP notice won’t cause a 500 error. I’m not sure what the problem is now. Can you check the server logs to see what the 500 error is?

This is really strange.

Nothing in the Apache error logs on the remote site. I’m using MAMP Pro locally and this was in the PHP log:

[30-Jun-2016 15:37:10 UTC] WordPress database error Table ‘wp_po_plugins’ already exists for query RENAME TABLE wp_PO_plugins TO wp_po_plugins made by require_once(‘wp-load.php’), require_once(‘wp-config.php’), require_once(‘wp-settings.php’), do_action(‘init’), call_user_func_array, PluginOrganizer->init, PluginOrganizer->check_version, PluginOrganizer->activate
[30-Jun-2016 15:37:10 UTC] WordPress database error Multiple primary key defined for query ALTER TABLE wp_po_plugins ADD PRIMARY KEY PO_post_id (post_id) made by require_once(‘wp-load.php’), require_once(‘wp-config.php’), require_once(‘wp-settings.php’), do_action(‘init’), call_user_func_array, PluginOrganizer->init, PluginOrganizer->check_version, PluginOrganizer->activate, dbDelta
[30-Jun-2016 15:46:49 UTC] WordPress database error Table ‘wp_po_plugins’ already exists for query RENAME TABLE wp_PO_plugins TO wp_po_plugins made by require_once(‘wp-load.php’), require_once(‘wp-config.php’), require_once(‘wp-settings.php’), do_action(‘init’), call_user_func_array, PluginOrganizer->init, PluginOrganizer->check_version, PluginOrganizer->activate
[30-Jun-2016 15:46:49 UTC] WordPress database error Multiple primary key defined for query ALTER TABLE wp_po_plugins ADD PRIMARY KEY PO_post_id (post_id) made by require_once(‘wp-load.php’), require_once(‘wp-config.php’), require_once(‘wp-settings.php’), do_action(‘init’), call_user_func_array, PluginOrganizer->init, PluginOrganizer->check_version, PluginOrganizer->activate, dbDelta

I don’t know if that helps at all.

No that doesn’t really help. It looks like those errors are from before version 6.0.7. And they aren’t critical php errors, which is what is stopping the process.

Let me know if there is anywhere else to check. I’m happy to give you access to the remote (live) site but obviously I can’t do that for my local install.

I’m not sure what to look for. If you are receiving a 500 error then there should be an error logged somewhere telling you what it is. To track it down I would need root access to your server and an admin account on your wordpress install. I wouldn’t recommend giving that out.

So I just tried migrating on another site with PO 6.0.7 and it went through without issue although it is on another host.

Yet still on the site in question, migrations work with 6.0.5 and do not with 6.0.7. Thus there is something else on this site that PO does not like.

I don’t mind giving you credentials but I don’t know if that will help unless you would be able to look at my local install as well (which isn’t an option, obviously).

Have you tried migrating with PO turned off?