::by Michael Penner
Most WordPress website owners are business people and won’t know what “PHP 8.x” even means. That’s perfectly understandable, but when you choose self-hosted WordPress as your website platform, you are also choosing to deal with keeping PHP up to date along with all plugins and themes that run your website. PHP is a code library that WordPress relies on to run properly. Security support of PHP 7.4, which is still used by many WordPress websites as of this writing, ceased in November of 2022. The shiny new version of PHP is 8.1, and yes, it can break your WordPress website if your plugins and themes are not up to date.
Attempting to update a WordPress website to PHP 8.x when using outdated themes and plugins will almost certainly crash it. You’ll likely get the message, “This website has encountered a serious error.” In my WordPress security work, I’ve discovered the most common reason these components are outdated is that the web developer never reviewed the cost of annual licenses with the client at the beginning of the project. The web designer, or web developer, used their own licenses to build the website and then left them in there while offering no ongoing support and maintenance services. It’s a terrible burden to place on the client. Let’s review why.
A developer’s license is tied to their company e-mail and phone. Only the person on the other end of that e-mail may seek technical support. Confirmation e-mails from the supporting organization will only go to the developer, and accessing the licensed software (plugins or themes, for example) is only available if you know the developer’s login to the business account under which the license is held. Clients have access to none of this. Sure, the license might be entered under the plugin’s settings, allowing it to receive updates. But the second something goes wrong, and it often does in tech, that developer is the only one that can communicate with the licensing organization about the problem. The situation gets worse if that developer has moved on and is no longer in business. I see it all the time.
Now we get to PHP 8.1, or whatever version is current by the time this article hits the web. If you’ve been reading my posts, you know I am big into staging servers. All the updates and upgrades should happen first on a clone of the live website known as the staging server. That way, if the upgrade to PHP 8.x crashes the staging website, you have a safe place to figure out which component is incompatible.
The good news is that updating all the components usually fixes the problem. But every component is different in WordPress, and sometimes things just don’t work. If the component has been abandoned by its author, it will never be made compatible with PHP 8.x, and an alternative must be sourced. Otherwise, it’s usually just a matter of time before the author makes their component compatible.
Some web hosts, such as getflywheel.com, will force your website to upgrade to PHP8.x by a specific date (there’s a button that you can push in the hosting control panel that updates or reverts PHP) unless you log an exception that they find reasonable. The problem is one of server security and performance that goes beyond the website. PHP 7.4 is less secure than PHP8.x, and web hosting companies must ensure they aren’t inviting problems.
If this all sounds too technical, take some solace in that professional web hosting organizations can usually troubleshoot and deal with this for you to a degree. At some point, they might charge you to get into your website and figure out what’s going on. PHP will continue to evolve, so this issue will always be something to watch. It’s just another day in the life of self-hosted WordPress.