JRGould

Yes, PHP 5.2 reached end of life nearly 7 years ago. We’ll try to fix the backwards compatibility for our next release, but in the meantime I’d recommend updating to a currently supported version of PHP.

If that’s not an option, you can update that line to read:

$main_domain_replace = $this->get_domain_replace() ? $this->get_domain_replace() : $this->get_domain_current_site();

Hi, what PHP version are you running on this site?

Invalid nonce errors are usually due to an expired session. Have you tried refreshing the page and/or logging out and back in again?

Hi Vincent – This is not possible with WP Migrate DB, but it is a feature of WP Migrate DB Pro.

This sounds like a javascript error. I’d recommend checking your browser’s javascript console for errors and disabling any other plugins that might be referenced in those errors.

Hi,

The premium version of this plugin, WP Migrate DB Pro, allows you to exclude tables from a migration, but this is not possible with WP Migrate DB.

I’d recommend checking out the SQL output – it’s possible that the export that cPanel is creating has more verbose commenting enabled or extended insert syntax which definitely could account for different export sizes.

You could also import both export files into different databases and then check the actual size of the database using a query like the one described here: https://stackoverflow.com/questions/1733507/how-to-get-size-of-mysql-database

WP Migrate DB should be able to migrate a multisite install in pretty much the same way as it does a standard install – the primary difference is that you’ll want to have your destination site already set up as a multisite with the same type of links for subsites (subdomains or subdirectories) and make sure that’s all working with .htaccess set up to correctly route requests. After that you should just be able to export from WP Migrate DB and import using phpmyadmin or your preferred database administration tool.

WP Migrate DB Pro allows you to exclude the users and usermeta tables from a migration, but WP Migrate DB doesn’t have this feature so the only way to accomplish this would be to delete those tables from the export file manually before you import onto your destination site.

?You might try disabling the gzip option and enabling Compatibility mode on the settings tab.

Also, are there any errors logged in your php or mysql error logs?

Hi,

WP Migrate DB can’t do this as it would require merging the two versions of the posts and postmeta tables. We’re working on a premium product that will help with this situation – you can read more about that here if you’re interested: https://deliciousbrains.com/database-merging-made-easy/

We’ve found this issue to be due to the fact that the Requests class doesn’t explicitly set the “Expect” header which allows cURL to automatically set it to Expect: 100-continue. More information on that here: https://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html#sec8.2.3

This seems to cause issues on a small set of servers on the sending side of things that causes large POST requests to pretty much any other server that’s otherwise set up to respond to them to fail. I’m not sure why this happens, but the fix is pretty easy: we just need to explicitly set the “Expect” header before cURL can do so automatically. We can do that with the following filter:

function preempt_expect_header($r) {
	$r['headers']['Expect'] = '';
	return $r;
}
add_filter( 'http_request_args', 'preempt_expect_header' );

• This reply was modified 8 years, 6 months ago by JRGould.

Check your table prefixes – if the site that you exported has a different $table_prefix set in wp-config.php than does the site you imported to, the import will just add some more tables to your database rather than overwriting the ones that are there. At that point, all you need to do is change the $table_prefix variable in the wp-config.php on the site you just imported the database into to match the $table_prefix from the site you exported from and it will start using the new tables..

I’m also having this problem in IE 8 only. So far, it looks like the ajax call is going through but receiving a null response for some reason.

EDIT: FOUND FIX ——

Looks like this was a bug in jquery.form.js which was fixed a few days ago. Grab the latest version of jquery.form.js and jquery.form.min.js from here: https://jquery.malsup.com/form/#download and use these to replace the corresponding files at plugins/contact-form-7/includes/js/

I’ve had a client blog hacked by this same exploit – took me quite a while to find it because I was searching the entire file structure for the tell-tale eval or base64_decode functions that these sorts of hacks utilize. Turns out this one was using strrev to hide itself from just those sorts of broad-stroke searches.

In my site it was actually inserted first thing into functions.php – but if you want to search for it just try searching for strrev or )lave and you should suss out the injected code.

Obviously this only solves the code injection, not how it got there – so make sure to update wordpress and change all of your passwords.

—edit—

This hack also appears to add an option to your database – for me the option_name was {options_names} – I found this by de-obfuscating the injected code and tracing through it really quick to check for any other traces it may have left in my install.