No one has liked any of my posts or comments in months. Actually, that isn’t really true- the actual truth is that a small number of people who visit my site without using a browser have liked some of my posts. Nope, that still isn’t completely true: people may like my posts, but they can’t push a button recording the idea that they like them.

That’s a long-winded way of saying that the ‘like’ button that is supposed to appear on posts and comments has been broken. So badly broken, in fact, that I turned the feature off. Well, you can now rejoice! The Like button is back (although as always you need to log in…), and boy is that a story…

The problem

Something about my WordPress configuration and/or my Cloudflare CDN has been causing the ‘Like’ buttons and links to be non-functional. These poor UI elements have suffered from endless ‘loading…’ for a very long time. Exactly how long is indeterminate: I noticed it perhaps six months ago.

I suspected that the problem related to one of the performance-enhancing mechanisms I use for this site. Both Cloudflare (the CDN) and a WordPress plugin I use, WP Rocket, implement various techniques to compress or asynchronously load certain page elements to make the site faster. These elements include CSS and JavaScript, and the ‘Like’ button uses both of these kinds of technologies.

Failed debugging

I’ve taken a number of stabs over the past six months or so at getting ‘Like’ to work again. I had found several posts relating to other people experiencing such problems and resolving it by disabling or changing the way CSS and JavaScript is handled. I tried a large number of possible approaches based on these references, but no progress was made.

I tried again to fix the broken ‘Like’ elements during Blaugust, but mainly just got frustrated. One thing I really wanted to do was temporarily deactivate the WP Rocket plugin, but when I tried doing so my site broke in a number of ways. I was pretty sure I knew why: I was using a rather convoluted way to get HTTPS (SSL/TLS) working that involved using Cloudflare’s ‘Flexible SSL’ feature and redirecting requests to my http origin server (the one in my basement) unencrypted. WP Rocket was helping in this regard by doing some protocol URL remapping: so I’d unintentionally tied the two together.

This all rendered it impractical for me to ‘quickly’ deactivate WP Rocket, and thus I couldn’t progress my debugging. I got frustrated and disabled the Like UI elements entirely, promising myself I’d return to the matter after the Blaugust event was over.

Picking up the problem again

Shadowz posted on their blog about a week ago about resolving a similar sounding problem with the Like button on their WordPress site. Unfortunately the solution they used didn’t apply to me: although I am using Cloudflare, the specific ‘Rocket Loader’ feature their solution referred to was already disabled in my configuration.

Just as a bit of clarification: Cloudflare’s ‘Rocket Loader‘ feature is in no way related to WP Rocket, the plugin I use. However, WP Rocket’s default settings when configured to work with Cloudflare automatically turn off Cloudflare’s ‘Rocket Loader’, apparently due to possible compatibility issues. That is consistent with what Shadowz documented.

Getting support, and making ‘Like’ work again

Although Shadowz experiences didn’t solve my problems, they did inspire me to try fixing the issue again. This time I decided to invoke the dark magic of the Technical Support ticket. I can open tickets with WP Rocket because I have the ‘licensed’ version- I haven’t availed myself of this privilege before, but decided it was worth a try.

I created a ticket that recapped my tale of woe, including mentioning that I was unable to easily turn of WP Rocket to test its involvement in the failure. The response I got back was helpful without giving me an answer. In essence the support person clearly showed that they had checked my site out, had confirmed the behaviour, but had no explanation for the failure. The next diagnostic step: disable WP Rocket.

Well, darn. That’s a problem.

Rejiggering the SSL configuration

I had mentioned above that my site had a rather twisty way of enabling HTTPS, and that convoluted approach was making deactivating WP Rocket problematic. My solution: unravel the SSL settings.

First I reviewed Cloudflare’s alternatives for SSL. One approach on offer was to enable Full (Strict) SSL using dedicated certificates provided for Cloudflare to connect to the origin (my web server). These aren’t the same certs used by visitors to my site. I liked this approach, so I set about enabling it.

Implementation of this approach involves having Cloudflare generate a dedicated certificate, installing that cert and its key on your server, and then changing the Cloudflare SSL settings. It sounded easy. Of course it wasn’t.

I won’t go through every challenge I encountered, but the main ‘hiccups’ were:

• Adding the Cloudflare CA HTTP server: My server didn’t recognize the Cloudflare generated certificate as ‘valid’. This was fixed via the HTTP configuration and the SSLCertificateChainFile property
• Enabling compatible ciphers: my server hadn’t been configured to support a cipher compatible with Cloudflare’s SSL handshake. I resolved this by adding a compatible cipher to the http server configuration using the SSLCipherSuite property
• ‘Fixing’ my firewall’s https protocol redirect: my PFSense firewall was configured to redirect incoming requests on the HTTPS port (port 443) to the HTTP port (port 80) as my http server had originally been configured without HTTPS enabled

Not WP Rocket after all

I was able to successfully disable WP Rocket without breaking my site after making the SSL changes I refer to above. Surprise! Disabling WP Rocket didn’t fix the ‘Like’ button perpetual loading issue.

So I then began deactivating one plugin at a time. As luck would have it, the second plugin in the list was the one the fixed the problem: EWWW image optimizer. This really doesn’t make a ton of sense to me. EWWW is supposed to compress and reformat images to improve performance. It isn’t supposed to be interacting with JavaScript or CSS, so what the heck was it doing wrong?

I spent about fifteen minutes pondering this question, then realized that I really didn’t need EWWW any more. Images on my site were already being compressed, reformatted, and then delivered via the CDN where possible. This more or less rendered the EWWW plugin redundant. I left it disabled and called the whole exercise a success.

Conclusion

I’m pretty happy with how things have ended up, although I did have a few hours while trying to get SSL working again when I wondered whether I’d just made a terrible mistake. The ‘Like’ buttons for posts and comments are working without apparent issue. WP Rocket was never the cause of the problem to begin with, so I have re-enabled it. The site seems to be performing just fine again. EWWW was the real culprit all along- so I’ve deactivated the EWWW plugin which wasn’t really doing anything for me anyway.

And the Cloudflare => origin server SSL changes I made are a significant security improvement. All HTTP interactions with Ubergeek Kelly’s World are now ‘properly’ encrypted, which is a nice thing.