Widgets lost after restore if containing emojis

Hello,
I’m trying to open again a ticket for the kind of problem raised here a few months ago:
https://www.ads-software.com/support/topic/text-widgets-lost-after-restore/

Basically, every time I restore the DB of a wordpress website backed up with backwpup I lose all the text widget (and custom html widgets at the same way).

In the meanwhile I took some more tests to find out where the problem is and I think I found out the solution:

The loss of widget happens every time a widget contains some “emojis” (inserted as unicode characters like these: ????) and it happens both with “text widgets” and “custom html widgets”. If I look at the strings “widget_text” and “widget_custom_html” on the live DB, right after restore, I can see that there is only a short string of a few characters with no data, that makes me think that the strings were corrupt and ignored by the restore process.

If I try to type only plain text instead of html code inside the widgets, I don’t lose them after restore.

Then I tried to backup the DB (with still emojis inside) directly from the phpMyAdmin page, deleting it, importing it back again, and this way the widgets are correctly restored including the emojis.

So I had a look at both the .sql export (one from backwpup and one from phpmyadmin), at the strings that contains the widgets: I can see that the phpmyadmin’s one contains the strings with the emojis (that are two characters long each) and the backwpup’s one instead replaced each emoji with a “?” (that is just one character long),so the whole string is a bit shorter than the real one, so I guess this is where the loss of data happens at restore phase, as the metadata in the wordpress strings are also counting characters.

After that, I tried to create a wordpress post containing an emoji in the title and in the text, tried backing up with backwpup and restoring again, the emojis are lost at the same way (replaced by a “?”) but at least the post is still there and not lost like the widget (and that’s because the DB strings containing the post are not counting the lenght in characters).

Summing up, it looks like Backwpup is not managing well that unicode characters (hope I wrote the correct encoding set?), that instead phpmyadmin is capable of.

If you need some example of the correct and wrong strings I’m talking about you can let me know.

Hope you’ll find a fix for that ??

Thanks,
best regards.

The page I need help with: [log in to see the link]