When I used Duplicator – as I always do because it is the most fabulous and free plugin for cloning and migrating my WordPress sites – to create a copy of a client’s site built with DIVI, I faced two problems:

• The special characters were shown as questions marks in a rhombus ���
• When I wanted to edit a page that was built with the DIVI builder, it was showing the DIVI builder active but with the empty standard row. Amazingly, on the frontend the pages were showing, yet with the ? problem. Once I pressed Update, the empty DIVI builder was taken over and the page also disappeared on the frontend

It was clear that it must have to do with a collation issue in the database, and as my tests showed, both errors are related. These are the results of my tests:

Failed tests

I found a few workarounds from both the DIVI team and the Duplicator developer, but these ones failed in my situation:

• The plugin WP Migrate DB
• Script workaround from https://wordpress.org/support/topic/can-duplicator-handle-different-collation-methods-between-mysql-versions

Working tests

• On my XAMPP localhost it worked, so I was guessing that it is connected to the MySQL Version (5.6.1, while on my webhost’s server 5.5.45)
• But on another webhost who uses MySQL Version 5.5.44 it worked as well, so I exclude the MySQL Version as the cause.
• It worked with the good old manual way, exporting and importing from phpMyAdmin, using the script Search Replace DB for manually changing the URLs in the serialized database entries. So this is basically my only workaround for the moment.

My workaround

1. Use Duplicator as usual
2. Upon install, copy the absolute paths from the replacement step (this saves us to figure them out otherwise, but you can also search the net for “absolute path php” to figure them out with an easy server script)
3. Export the site’s database manually in phpmyadmin
4. Import the new database manually in phpmyadmin
5. Run the script Search Replace DB on it, replace the old URL with the new one, and the old absolute path with the new one.
6. Ready. It is still faster to use Duplicator even with this additional manual database replacement.
7. Actually I now wonder, why does it work in this way, what is Duplicator doing different?

This is what I figured out. On one side I am glad that it works on another webhost and might only become a problem on rare occasions.

On the other hand I really hope to be able using my favorite Duplicator together with my favorite DIVI theme in all situations, so I opened this post to collect the experiences of others in the hope that we can isolate the issue and not only finding workarounds but a proper solution. If you have the same issue and tried around figuring out more clues, please share them in the comments and I will periodically let the developers know. You can find the actual status of the developer’s process here, it is meanwhile already fixed in many occasions.

Update 6.12.2015: fixed

I came across the mysqldump option in the settings just now that the compatibility mode told me about. So I activated it and thought to give it a try even without the compatibility mode, since the MySQL Version on that host is 5.5 so I couldn’t imagine that this would help in my case. And what can I say, it worked.

So I can recommend everyone who as me didn’t know about this setting yet, to change in the Duplicator settings from “Use PHP” to “Use mysqldump”. It might already fix your problem. If it doesn’t, then you can download and install the developer version as described in the link above and then you find in “Step 1: Package Setup” in the tab “Archive” / “Database” the compatibility mode options. Good luck.

Update 6.12.2015 later that day: unfixed

Oh no. On one webhoster it worked, the one where it happened first to me (strato), but now I duplicated my standard DIVI installation to the hoster of another client (1&1), and again the question marks. The same archive already worked on another hoster. Really strange, all hosters are big ones, with actual MySQL versions (5.5). And the behaviour is so very odd, nearly like random.

Even my workaround, the good old searchreplace script, doesn’t work here. Such a mess. But I found out a few more interesting things.

• In my standard installation that I duplicate whenever I start a new site, I have typed some special characters into the front page to identify at first sight if the issue appears. Now these german characters äöüÜÖÄ appear as question marks. BUT I checked the database content directly, and in the table wp_posts in phpmyadmin these characters appear normal!!!
• Now I got curious and typed some more öüä behind them. When reloading the page, they also appeared as ���.
• Next test: I created a new page in WP and typed again äöüäöü, and now completley crazy: they appear normal in the website, but in the database they are saved as something like öäöäüöä. Which is the UTF8 coding of them. Now it is really strange: The üöä I see correctly in the database appear as ��� on the website, and the öäü I enter there are transformed into öäü.
• On hosters were the issue is not appearing (I checked the same things on such) I see my german umlauts on the website and in the database everywhere correctly.
• On both hosters the table collation is utf8mb4_unicode_ci, but on the hoster that makes the mistakes, the database itself is latin1_german2_ci, while on the correct one it is utf8_general_ci. Ha, and the original db on the localhost is latin1_swedish_ci. No wonder that we get into translation problems.

I drilled it down to the point of a fresh install into a utf8mb4_unicode_ci database, so everything in this install was utf8mb4_unicode_ci. I transferred to the new host, into a utf8mb4_unicode_ci database, everything is utf8mb4_unicode_ci. And still I only see question marks – and not only on the screen.

No matter if I use duplicator or phymyadmin export and import. No matter if the divi theme or a regular page. I can exclude everything meanwhile but the webhoster. I will call them tomorrow hoping they have an idea of why in their system it doesn’t work what works on other hosters.

It continues and I really hope soon this issue is out of the world completely.