MaTachi

Thank you Frank, that did indeed solve the problem.

I’m having the same problem with Autoptimize enabled.

I changed the collation with:

alter table wp_options convert to character set utf8 collate utf8_unicode_ci;

To show the collation for all database table columns:

SELECT TABLE_CATALOG, TABLE_SCHEMA, TABLE_NAME, COLUMN_NAME, COLLATION_NAME FROM INFORMATION_SCHEMA.COLUMNS;

However, that didn’t help. Still isn’t possible to store a string containing the emoticon…

I guess base64 encoding the string is a sufficient workaround. :/

OK, when the value contains the ?? character it never gets saved, as seen in:

mysql> select * from wp_options where option_name like '%kalle%';
+-----------+------------------+--------------+----------+
| option_id | option_name      | option_value | autoload |
+-----------+------------------+--------------+----------+
|       270 | _transient_kalle |              | yes      |
+-----------+------------------+--------------+----------+
1 row in set (0.00 sec)

But if I remove ?? and only keeps the string hej:

mysql> select * from wp_options where option_name like '%kalle%';
+-----------+------------------+--------------+----------+
| option_id | option_name      | option_value | autoload |
+-----------+------------------+--------------+----------+
|       270 | _transient_kalle | hej          | yes      |
+-----------+------------------+--------------+----------+

Umm, played a little more with it. Seems like the string with the Unicode character only shows up after the first page load. When you do additional page reloads it doesn’t appear again. However, if I remove ?? and only keep hej it works fine on every page load. Dunno what’s up with that behaviour. Maybe the first time it never gets it from the actual database.

Haven’t tried the collation change, I’m affraid I will mess something up, especially on a live website. ??

But I have a locally installed instance of WordPress, which also has collation set to utf8_general_ci. I added the following three lines of code to the default plugin hellp.php:

set_transient('kalle', '??hej');
$hej = get_transient('kalle');
echo $hej;

And it prints the string ??hej correctly on the screen. So apparently there shouldn’t be any problems with storing and getting those exotic Unicode characters.

However, my local web server runs another version of PHP, etc. Dunno if that matters.

I tried the code change that you suggested, with base64 encoding the transient data, and it worked fine. However, it feels a bit like a hack. The downsides are the extra encoding/decoding and 33 % storage overhead. Although, I guess neither is noticable.

I haven’t coded any WordPress plugins so I don’t know the API. But I’m wondering, why do you currently do set_transient($cache_key, json_decode($json), $instance['cache_time']);? Isn’t it possible to store a JSON string as is in the database?

I looked at my MySQL database and the collation for the varchar columns in wp_options are all set to utf8_general_ci. I wonder if it might work if I were to change the collation to utf8_unicode_ci instead. Apparently does the latter handle Unicode characters better, although a little slower; according to https://stackoverflow.com/questions/1036454/what-are-the-diffrences-between-utf8-general-ci-and-utf8-unicode-ci.

I looked at your patch:

$json = preg_replace('/??/','',$json);

However, that does obviously only handle the Unicode character ??, i.e. U+1F40E. In the Unicode standard there are a lot more emoticons: https://en.wikipedia.org/wiki/Emoji#In_the_Unicode_standard And I guess there would be problems with other Unicode characters as well: https://en.wikipedia.org/wiki/List_of_Unicode_characters

Is the problem in set_transient or in json_decode? I mean, I would think it’s desirable if they can handle all unicode characters properly.

I set the timeout variable to 10 on both places in youtube-channel.php, but I’m still getting the same error.

It’s a little hard to follow the flow in the code because you have mixed both tabs and spaces for indentation, and WordPress’s editor shows tabs as 8 spaces wide.

I’m experiencing the same problem. I don’t have any cache plugins activated on my WordPress blog.

This is my debug information from the plugin:

server: Apache
php: 5.4.8
wp: 3.9.1
ytc: 2.2.0
url: https://misslisibell.se
title: Mina senaste YouTube-filmer
channel: MissLisibell
vidqty: 5
playlist: null
use_res: null
cache_time: 3600
only_pl: null
getrnd: null
maxrnd: 5
goto_txt: null
showgoto: null
popup_goto: null
showtitle: on
showvidesc: null
descappend: …
videsclen: null
width: 220
height: null
to_show: thumbnail
autoplay: null
controls: null
fixnoitem: null
ratio: 3
fixyt: null
hideinfo: null
hideanno: null
themelight: null
debugon: on
userchan: null
enhprivacy: null
autoplay_mute: null

However, the thumbnails show up as expected if I change the “Cache feed” setting to “Do not cache”. On the other hand, I suspect disabling the caching will affect the page load time and server performance negatively.