As PHP continues its march into the future with improved support for objects, better memory management, and notable performance boosts WordPress seems to be dead-set in sticking to the “must support old technology no matter how bad it is”. As of this writing, on the verge of the much-anticipated WordPress 5.0 release with the almost-modern reactive components interface — the past continues to hamper the technology by insisting on clinging to PHP 5.2 as the baseline version that plugins and themes should support.
PHP 5.2 Is Dead
Not recently dead. Long deceased. PHP 5.2 support officially ended OVER SEVEN YEARS AGO in January of 2011. That is about 3,000 years ago in human-time.
Businesses have been hiring programmers for decades now. Back in the 70s it was something only Fortune 100 companies did. Today everyone from your local cafe to full-fledged software companies do it. Unfortunately few now how to hire a programmer.
Nearly every-single business outside of the tech sector gets screwed when paying an outside agency to write their apps. If you’ve hired a programmer recently it is very likely you are on that list. If you don’t think you’ve been screwed, you are likely just wallowing in a pool of naivety as your coder-for-hire laughs all the way to the bank.
First things first -let’s get setup.
One of the common processes that runs in Store Locator Plus is deleting locations. For sites with a few dozen locations the process runs smoothly. For sites with thousands of locations but deleting one or two at a time, not a big deal. But for sites that are deleting tens-of-thousands of locations at a time the process becomes painfully slow. A mere 2,500 locations can take up to a full minute to be removed on a fairly decent performance server. That’s not the type of performance I like to see from our product.
After digging into the performance of the PHP stack initial indicators point to the custom post types as the primary culprit. It turns out that deleting a single custom post type in the WP_Posts table runs through a dozen gyrations to delete the post. Multiple filters are called, associated taxonomies are delete, taxonomy meta is deleted. It is a TON of extra overhead. But even with removing records from a half-dozen tables the data queries seem out-of-control.
Removing just 9 locations generates over 190 data queries. If there is one thing that has not changed in decades of writing software it is that data queries are costly. They may run on solid-state drives with advanced memory caching but doing 190 data queries is still far slower than nearly any other part of the application.
WordPress LOVES backwards compatibility as can be witnessed by the minimum-allowed WordPress PHP version remaining at 5.2.4 a decade after its end-of-life date. It may be one of the reasons they have continued to garner market share. Don’t require people to do anything to improve their site and they’ll wallow in complacency. It makes sense. Inertia is a big thing to overcome. If you are a business focused on writing content, selling widgets, or doing just about anything else other than managing websites, upgrading software is way at the bottom of the priority list.
This backwards compatibility is one of the reasons why WordPress continues to RECOMMEND PHP 7 for performance and security reasons but allows the minimum WordPress PHP version to remain 5.2.4 without breaking the core application. It is the reason why so many plugins, including Store Locator Plus, continue to do some convoluted things to reach that PHP 5.2 audience and keep their potential market as big as possible.