Website Stability Woes

This site has been offline for almost a day, and I hadn’t noticed!

Luckily, I came here to draft a post about my recent experience with a PHP bug, and I noticed that the page was loading to a white screen. Experience teaches me that the web server Caddy likes to return empty responses when the configuration looks good but there is no handler providing a response. On closer examination, I found that I was missing restart: unless-stopped from my container definition in my docker compose file. My WordPress container wasn’t running.

I rebooted the server and failed to specify in my compose.yaml that the PHP-FPM WordPress container should be booted with the server!

Child crying.
Public Domain image by Victoria Borodinova. A visual representation of my pain.

So yeah, corrected that very important detail, and started up the container. At least I can be assured that the bots missed my web presence for not even a millisecond.

The other evening, my PHP bug was enabling the JIT. It turns out that the JIT author knows this feature has problems. For example, it causes the Dashboard->Updates page in the admin panel to fail to render. The PHP worker runs forever, and simply disabling the JIT fixes the problem. Disabling JIT by default seems to be the right call, but perhaps more could be done to communicate clearly with users that the feature is very much experimental. I feel that I was mislead into thinking that PHP ships with stable features. Surely WordPress ought to be supported. Other developers feel the same, writing that the JIT is not production ready. I’d argue perhaps it shouldn’t be shipped with PHP at all if the code doesn’t work for the most popular PHP application in the world.

The more I learn, the more kinda junky PHP seems to me, for all its incredible success.





Leave a Reply

Your email address will not be published. Required fields are marked *