I’m pretty sure that wasn’t done by Duplicator. A global search and replace only shows DB_CHARSET once in the source here, and the value is set as readonly. It could be possible that the Core WP may be doing that.
In version 4.2 a change was made that automatically updates your tables. It maybe possible that there is some auto-detection that is running as well, I’m not sure where that would come from but there isn’t any code in the plugin that does that…
Are you using plain php on restore or Wp-Core is envolved somehow?
If you login to your site after step 3 of the installer then WP-Core code is called that might be were the change is made, but I’m just guessing. As far as Duplicator changing the value, there isn’t any code anywhere that I see making such an update…
I am logging in when the process ends, but not redirect by duplicator.
However this is a great tool
Thanks… I’m not quite sure where the change is happening at, wish I could provide more insight…
I may help.
I am using Siteground, they have multiple services tightly integrated with WP.
Who knows, maybe once WP is started they adjust wp-config.php somehow…
Possibly… Hope your able to get it pin-pointed…
Cheers~
I have discovered a couple things:
1. the default collation sequence of my development environment is utf8mb4
2. some tables in the database have utf8mb4 while others utf8
3. WP seems moving to utf8mb4? See here
That is correct. The link I have above titled version 4.2 also links to the same post, just in-case you missed it…
Whoops! What shall I do? Keep the collation fruit-salad in my db as is?
I’m not sure if I understand the question…
You might try checking the version of the MySQL servers between the servers your moving. If the server where the package DB is made is too much lower than the server where its being installed then you can run into conversions issues.
These issues are difficult to pin-point the root cause in some situations… I have put a check in the latest version (1.1.12) to warn on this when clicking the ‘Test Connection’ button on the installer…
There are a few FAQs on this that might help; checkout the question on the FAQs page under the section below:
-> Browse to: http://lifeinthegrid.com/duplicator-faq
-> Find section: “Database Issues”
Hope that helps!
Thanks and sorry if I didn’t explain myself properly.
The question was if in your opinion is it safe to keep my WP db with mixed collations, as I have tables with utf8 and others with utf8mb4.
Thanks a lot
Most of my databases and sites have mixed collations, its pretty normal and OK, however if you can get them all on the same collation it creates much more stability with any migration, and is a much better way to manage your database.
Cheers~
I’ve just done a deployment using Duplicator, from one utf8mb4_unicode_ci mysql server to another.
After ‘install’ I was sent straight to the language selection screen as if I’d never installed WordPress before. I’ve just checked the (new) database and all it contains is ‘wp_duplicator_packages’, which, looking at the database.sql file the plugin generates is the only ‘utf8’ charset table in my db.
So two questions:
1. Why was only the UT8 charset table installed?
2. Why is the ‘wp_duplicator_packages’ table utf8 and not utf8mb4_unicode… ?
I haven’t managed to resolve the issue, just playing with trial and error now. I haven’t had the issue before so I suspect it’s something to do with the destination server, which is one I haven’t used this plugin with. (Webfaction, for the record)
-
This reply was modified 9 years, 2 months ago by
nathanhornby.
Actually it seems this problem is specific to my MYSQL versions, built in 5.6 and deploying on 5.5 (collation errors). Annoying, not much I can do about that now! Will try the workarounds and hopefully one works 🙂
Still interested to hear why this plugin produces the only table that doesn’t use utf8mb4 though?
-
This reply was modified 9 years, 2 months ago by nathanhornby.
