This site has always been a tool for me to stay sharp on new web technologies and lately it’s been a great way to test my cognitive skills since the little incident in October. I’ve had three things on my web development to-do list for a long time: 1) use Let’s Encrypt to add TLS/SSL security, 2) make my WordPress theme mobile-friendly and 3) create some dedicated data entry screens for golf scores, runs and bike rides. During my recovery at home, I decided to tackle item #1…

Since I still had Homebrew installed on this server, I was able to get Certbot installed early on in the process and had a valid certificate ready and waiting. I haven’t tried automating the renewal process yet, but can manually renew the certificate with no problem (had to do this once already, in fact). For whatever reason, I had trouble finding examples online of people with similar setups and had several false starts in getting Apache configured correctly to use the certificate for this domain. This post got me most of the way there, but had more of a focus on Mac OS X Server and not plain old Mac OS X client. A few other helpful links here, here and here. And this thread on the Let’s Encrypt site helped me figure out what can/should go in the httpd-vhosts.conf file versus what should go in the httpd-ssl.conf file.

Combined with the Really Simple SSL WordPress plugin, I was able to get a green “B” rating on the Qualys SSL test site. After adding a SSLCertificateChainFile line to my VirtualHost config, I got the top A+ rating and just needed to figure out why my main page was still showing a “not fully secure” message in Chrome. After upgrading the Really Simple SSL plugin to the pro version, I was able to run a full scan, correct a few issues it found, enable HSTS and make cookies more secure. Now all pages in Chrome have the coveted padlock (with no warnings) and I still had the A+ rating. All was right and good in the world.

Then I looked at some old posts…

Almost everything looked fine, but posts and pages that had emoji in them were now messed up (hearts seem to display OK, but everything else was either a question mark or some other image). Emoji support in WordPress started back in version 4.2 and I remember having issues back then too. For this site, it was due to the MySQL tables on the backend not being configured correctly. I verified that the database was using utf8mb4_unicode_ci collation on the posts field and also discovered that phpMyAdmin wasn’t having any issue displaying the emojis (it runs under the same domain and those pages were getting a padlock from the Let’s Encrypt certificate, so this has to be a WordPress issue). I thought maybe this had something to do with the newest emoji release, which WordPress contributor Brandon Kraft writes about here. After I tried matching his page source code for things like charset=”UTF-8″, I still couldn’t get these emojis to display (which they did when the site was not secure).

After Google failed to turn up much for WordPress, SSL and broken emoji, I contacted Really Simple SSL pro support. Their first question was if this happened to new posts in addition to the old ones (yes), then asked if I had looked at all the character encoding angles (like this post). My wp-config.php file didn’t have DB_CHARSET or DB_COLLATE lines, so I tried various combinations of adding that back in and commenting it out, with no success. Made sure to check caches and different browsers too. They hadn’t seen this before, so I’m guessing it’s something with my custom theme and combination of various plugins that is causing the issue. If I paste the same emojis into a test post on a different domain on the same server that hasn’t had SSL added (and with the same version of MySQL and WordPress), the emojis display fine. Huh.

Standard WordPress troubleshooting would have you disable all your plugins and I have tried to go back and disable Really Simple SSL (I don’t want to turn them all off). I also started researching how WordPress implemented emoji display and found some core javascript code that gets inserted automatically (it’s a section that starts with window._wpemojiSettings and references a baseUrl of “https:\/\/s.w.org\/images\/core\/emoji\/11\/72×72\/”). I thought maybe this was the issue, as I can’t seem to access that s.w.org domain using https, but when I compared the page source from my site to the javascript on Brandon Kraft’s page, it was exactly the same (and emojis appear fine on his site).

So in the grand scheme of things, I’d much rather have the A+ security rating and not worry about displaying emoji in posts. It does bug me, though, that I can’t find anyone else online with a similar problem and that I haven’t been able to successfully troubleshoot this issue. If you have any ideas, please contact me via email here.