Hi,
when i import a backup from duplicator to local i get 2 problems.
1 - Some characters are not encoded correctly as you see in the attachment
2 - the forms created with contact form 7, are reset in the configuration and message fields
when i import a backup from duplicator to local i get 2 problems.
1 - Some characters are not encoded correctly as you see in the attachment
2 - the forms created with contact form 7, are reset in the configuration and message fields
is there any way to avoid these problems?
thank you
best regard
Emanuele
This probably has less to do with Duplicator and Local and more to do with some differences in the configuration of the database between these two environments.
Specifically, when I see that kind of mangling of characters, I usually think of issues with character sets between the two DBs.
This blog post will give you a better backstory of the issue, as well as a general idea for how to fix it:
But basically, you’ll probably want to export the DB, make some changes to the sql dump to update the character sets and then try manually importing the DB into Local using either Adminer (from the database tab) or WPCLI from within the “Open Site Shell” link.
I compared two databases, the first created automatically by the duplicator import and the second created by the Local … as you can see the charsets are different … if I modify them, do I risk losing something from the database?
I ran 2 tests.
the first one installed the site with the standard duplicator procedures, then uploading the installer.php file + the .daf file in Local folder, the installation did not create encoding problems for the texts.
with the second method, then by dragging and dropping the duplicator .zip file to Local, in this case the text encoding problem occurs!
Therefore, considering that the files and the database are the same,
I don’t understand the way by which Local incorrectly encodes the cherset.
Yeah, latin1_swedish_ci is the older collation whereas utf8_general_ci is the newer, and in most cases better (especially for internationalized strings) character set.
WordPress used to create tables using latin1_swedish_ci and there’s even a Codex entry on converting to the newer character set:
Most of the time, having latin1_swedish_ci isn’t an issue if the site stays in one place. It only becomes an issue like in this case when the environments change.
If you can, for the long-term flexibility of the site, I’d recommend putting in the effort to update the DB to use utf8.
To your question of why Local doesn’t correctly encode the charset – I’m not sure why that’s the case, but if I were to guess, it’s because Local is maybe creating the database before importing the SQL file, whereas the duplicator process is somehow altering or dropping the existing local database.
Either way, I think if you get to a point where you have it working, I’d say getting the production site updated to utf8 would be a good thing so that migrating the site to Local (or any other host) is a little safer in terms of accidentally introducing these kinds of content errors.
I know you didn’t specifically ask for this, but I found this older blog post to be very helpful in my understanding of Character sets in general, as well as the overall history for why things are the way they are. Hopefully it’s a useful resource to you too!
