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.

It is good that is it long gone.   Yet for some reason, mostly likely the clout of lazy-ass hosting companies that do not want to put any effort into upgrading their hosting platforms, WordPress still insists on supporting that release.

What does that mean for plugins, themes, or even WordPress core itself?  Is it really that bad?

Yes.   Yes it is.

Why supporting 7-year-old languages is bad

At first glance people may think “well, it is not that hard to keep the programs updated to support older versions of the language”.   Yes and no.

First of all any modern IDE will start throwing out all kinds of warnings as will compilers and any other modern PHP development tool.   However the bigger issue is that if you wish to support the entire spectrum of PHP versions WordPress supports you need to start littering your code with “if old-shitty PHP do X otherwise if new PHP do Y” and in a few rare cases even “if really-old PHP to X, kinda-old PHP do Y, new PHP to Z”.    A maintenance nightmare .

Not too mention the notable security and performance issues.

create_function example…

For example, all of the IDE tools in use will soon complain about the nearly-ubiquitous create_function() being deprecated; as of PHP 7.2 it will no longer work.     So what are your options?

You can write for PHP 5.3, at least that language has only been dead for FOUR YEARS as of August 2014, and replace the old super-shitty, memory-hog and security-issue-laden create_function() function in PHP 5.2 with the PHP 5.3 inline anonymous functions.   But wait…. NOT IF YOU SUPPORT PHP 5.2.    Nope.  WordPress will force you to use a function with performance and security issues.    So if you wish to support OLD AND NEW versions of PHP — you know, so your plugin or theme can run on any system WordPress supports you now have to start doing things in your code that are a nightmare for maintenance.

To fully support the entire range of PHP that WordPress runs on you now have code that basically says this:

if ( PHP_VERSION < 5.3 ) {
  add_filter( 'my_filter' , create_function( 'echo "do something"; return true;' ); );
} else {
  add_filter( 'my_filter' , function() { echo "do something"; return true; } );
}

OK – so that doesn’t seem so bad.  Except you now have to do that in EVERY piece of code where an anonymous function is desired.    If you want to change what the anonymous function does you now have to edit two pieces of code every single time a tweak is needed.

Do you need to use anonymous functions?  No, you can use a proper inline function (why are you still coding inline procedures?) or a class/method call.   It really is the better way to do it but from what I’ve seen of the 30,000+ plugins in the WordPress repository is that there are a lot of bad and lazy programmers publishing plugins.   They’ll all break either on PHP 7.2 or PHP 5.2.

Other PHP version issues

This is just one of many examples of a the nightmare the “full PHP spectrum for WordPress” brings about.    Supporting PHP 5.2 drops a myriad of new, and by new I mean 6-year-old tech, features and functions that can significantly reduce the overhead needed to design modern plugins and themes.    Autoloading of classes or other support PHP modules becomes far more difficult.   The self-instantiating singleton model now being used in most of the Store Locator Plus plugin stack is notably more difficult.

Here are some of the reasons Store Locator Plus™  requires newer PHP versions:

* PHP min: 5.2 pathinfo() with path_parts['filename']  
required for proper file path self-discovery
@see  http://php.net/manual/en/function.pathinfo.php

* PHP min: 5.3 get_called_class() 
required for self-instantiating singletons
@see http://php.net/manual/en/function.get-called-class.php

* PHP min: 5.3 anonymous functions to replace create_function() 
required for PHP7.2 compatibility
@see http://php.net/manual/en/function.create-function.php

Instead of trying to support PHP 5.2 we opted to drop that support in Store Locator Plus™ a year ago.   It should have happened sooner.   It only makes one wonder what compromises have been made in WordPress core for similar reasons.