Can you tell me what result you get when you try the same thing in a blog post on your website?

It took me a while to get back to this. 

Indeed, the whole website converts emoticons into squares. 
That sucks!
Any idea why? I searched on Google but could not find the solution. 

OK – so this is site wide and actually a WordPress issue as opposed to Simple:Press. SP passes those kind of keystrokes straight through to WordPress to resolve.

So I can only think of two possible reasons. The obvious one is that WP can not find images to resolve with. Check the url that is getting created in the display source code – that will give you a clue.

The other is that your tables have not been upgraded to MB4 encoding – needed for WP to display emoji’s. WP will attempt to use the MB4 encoding when it creates tables at install or – if an older, established database, attempt to upgrade tables during an update.

My problem with that scenario, is that I was pretty sure WP had a fallback to emoticon/image files if the tables were not updated. And some people do have a problem updating their encodings if the mySQL version being used is older and does not give the support.

I believe I am right in thinking that you have a test site? If so – and of you have the same problem on that – you could try using our MB4 upgrade tool plugin (https://simple-press.com/downloads/simple-press-database-mb4-encoder/) but this will only convert the SP tables. But you can inspect the DB tables to find out of course – which is probably quicker! 

I checked the source code and all I found is a square in it, so no path to any image file. 

This probably means there is an issue with the encoding of the database. 

I am hesitant to make such profound change in the database because I have never done it and I am worried that it may cause issue with other data in the database. I more like a “button pusher” when it comes to MySQL. I can make dumps and stuff but I have no experience with changing the encoding on a running site. 

Is it risky? Of course I would need to make a backup first, but is it risky that it could cause issues in the long run, when i change the encoding of the entire database?

We have a test site to experiment with, for sure. 

i have not heard of anyone having a problem making this conversion. The big issue is whether the version of MySQL you are using is capable – I can not recall now which V5 version was the one that allowed for it. 

But – am I not right in thinking you are hosted by WP Engine? If so they should be up to date and also up to date with the WP updates that ran this code on the whole DB.

To be perfectly honest with you – I think they would be the best people to speak to about this as it seems to me that this is essentially a WordPress issue as it happens in blog posts too. All the forum does is pass this straight through to WP filtering.

Thanks!
Your input it very valuable. I will talk to the WP Engine peops and let you know how it goes.  
(non converted big smile)

Please do let us know what happens…

I just try to use the plugin but this is what I got

it seems all tables already have the “right” encoding?

What else can I do?

Did you ask the hosting support guys? 

To be honest I don’t have a detailed understanding of how WordPress does this. The emoji support was built in quite a while back. If I want to enter a standard ‘smiley’ then I can just use the colon+right-bracket and it gets converted to 🙂

I can also add an emoji from my browser (edit menu) like this – ? – but whether that is just on a Mac I do not know.

As this is not working across the board for you – and the first place to test would be a blog post – then I would assume something is interfering with that built in support. I still think you need to work this with your host or on the WP support forums I am afraid

It’s so weird. I don’t know what is going on with me. 
It’s pretty much the same like yesterday when you pointed out about the CSS that was causing the issue. 

I commented this out in the functions.php 

// remove_action( ‘wp_head’, ‘print_emoji_detection_script’, 7 );
// remove_action( ‘wp_print_styles’, ‘print_emoji_styles’ );

And as you can imagine, now it works!

… and actually the WP Engine support just helped me because they said I should check if it works with another theme.

Thanks for your support, Andy! I learned some new things, so it wasn’t wasted time, I think. 

I was just about to send you a couple of links to the WP Codex but looks like you do not need them.

I am most curious as to why those two calls should be removed by a theme. Seems a most odd thing to do but hey – you’re working again which is all that matters.

Besides my focused work on creating these websites for my clients, I have this “kinda hobby” to explore WordPress functionalities and tune my functions.php. Sometimes it results in adding code that is just useless and in this particular case it was just that, adding respectively removing a functionality that messed with the proper functioning of what we consider as core functionality. 

People will want to use smilies in the forum, so it is good that they are back and we can just add those characters that will be turned into images. 🙂

Yay! It really bothered me that it didn’t work. 

Thanks!