Use utf8mb4 to support emojis

Hello together,

I encountered a problem loading a dataset from remote. The remote uses emojis in its titles and Xibo fails to insert them into the database (Error message: “Incorrect string value: '\xF0\x9F\x98\xAD …”). I think this is because Xibo doesn’t use utf8mb4 character set.
I would like to see this is getting changed in future versions. utf8mb4 should be preferred generally.

I’m also open to ideas to fix this problem for me.

Kind regards,

Thanks for this suggestion - after a bit of reading it seems MySQL will eventually move all utf8 columns over to utf8mb4. The utf8 column is actually utf8mb3 under the hood.

I don’t think there are any downsides to utf8mb4 and we should certainly do it for all new tables/columns. (note to future Xibo devs - ['collation'=>'utf8mb4_unicode_ci'] in phinx).

In the interim, you could try changing the collation on the dataset_ tables directly in your database yourself. (Please take a backup first if you do).

Best wishes,

Hi, I’ve tried to change the collection for all tables. I’m not working in a production environment yet, so that’s not a problem. But it seems that this is not enough to support emojis. Maybe it is needed to adjust parameters while the software is etablishing the database connection?

That is interesting, there are two places in PdoStorageService.php where we run SET NAMES 'utf8', and I wonder if that is the reason it doesn’t work.

It seems to be. I’ve changed it temporarily in my docker installation and it seems that now I can save text with emojis without problems. So far, I have not noticed any problems after the change. It is possible to change this in the core in the next version?
Because I use a docker version my change is not permanent.

Good to hear that works, thanks for posting back.

I’m reluctant to change it in a patch, mostly because of the words “so far” :slightly_smiling_face: and making such a change to a stable release isn’t usually a good idea.

I’m happy to make the change for the next minor release, which also happens to be a major release - 4.0.0 and I have retagged the issue to make sure that gets done for you.

If you want to persist your change you can add a volume for the file you’ve edited to your docker compose file. The volume would map the file on your host OS over the one inside the container.

1 Like

I’ll go with that. If only because a change in the collation of the database is also necessary for it to work.

I’m happy to test the new version as soon it is ready.

I already thought of this and I think I will try that.

1 Like