At the State of the Word 2018, Matt Mullenweg made a lot of different announcements. Most of them focused on Gutenberg, but a few didn’t. One of those was a proposal by Gary Pendergast to increase WordPress’ minimum PHP version.

This announcement received a lot of applause. That’s because it made a lot of people (especially developers) excited. WordPress still had a minimum PHP version of 5.2 at the time. This PHP version hadn’t been supported in more than eight years.

Developers have always felt frustrated by this situation. PHP has changed a lot and added a lot of cool, useful features since PHP 5.2. But those weren’t available to them if they had to write code that supported PHP 5.2.

So, without a doubt, this was a great announcement for WordPress developers! They were finally going to be able to use modern PHP features while writing WordPress code. That said, that announcement didn’t change the nature of the WordPress project itself. It still won’t make it a modern PHP project that’ll attract and retain developers.

The WordPress Legacy

Part of the reason for that is WordPress is a legacy application. The WordPress project itself is more than 15 years old, but it’s also a fork of another project called b2/cafelog. This was an open source project that had already existed for a few years before Matt and Mike decided to fork it. So all things considered WordPress is a lot closer to 20 years old.

Working with software that old brings unique challenges. Case in point: Your development practices tilt towards not keeping up with what others may be doing in the industry. This is especially true with WordPress. That’s because the PHP ecosystem wasn’t at all like it is now when the WordPress project started.

For example, there weren’t community-wide PHP coding standards back then. But there are now with the PHP standards recommendations also known as PSRs. This leads to an awkward situation where there’s the “WordPress way” and the “rest of the PHP community way” of doing things.

Now, it’s not realistic to expect the WordPress project to conform to all these new standards. WordPress already has the WordPress way of doing things. And it’s more important to work with a consistent coding standard than not.

But it highlights the difficulties of working on a legacy application like WordPress. It also demonstrates the challenges of retaining developers in the WordPress ecosystem. Most developers would rather work like the rest of the PHP community and not just the WordPress way.

Bumping the Minimum PHP Version Isn’t Going to Fix This

As you can imagine, bumping the minimum PHP version isn’t going to fix this issue. The novelty of being able to use namespaces, anonymous functions or short array syntax doesn’t last very long. Of course, they’re all great language features and we’re all excited to finally be able to use them.

But if WordPress wants to retain developers in the long run, it needs to do more than just bump its minimum PHP version. It needs to find a way to bridge how it does things with the way PHP does things now. This will require that it modernizes its outdated PHP development practices.

It’s worth reiterating again that WordPress doesn’t need to overhaul all its development practices. That said, updating some of them would go a long way to help its image with developers. It’ll never make it the cool new thing, but that’s not something worth striving for anyhow.

Make WordPress Code Easier to Unit Test

As someone who teaches about testing with WordPress, this is an area that’s really lacking. While WordPress does have a test suite, there’s more to testing than just having one. And that’s where WordPress really shows its age.

The main issue is that WordPress code is notoriously hard to unit test. There are a few reasons for that. First, WordPress still uses global variables to store information about itself. This means that a lot of what you have to do while unit testing WordPress code is manage these global variables.

Why is that bad when unit testing? It’s because a fundamental element of unit testing is the use of mocks. But it’s very hard to mock WordPress’s behaviour if it stores all its information in global variables.

Besides having to deal with all the global variables, WordPress code also tends to be quite complex. The primary cause for that is WordPress functions and class methods are typically quite large. For example, the get_posts method in the WP_Query class is over a thousand lines long. It’s pretty much impossible to test that properly.

Stop Writing WordPress Code Like You Did 20 Years Ago

The issue with testable code also highlights another problem with WordPress development practices. It’s that the code isn’t testable because it’s still being written like PHP code was written 20 years ago.

So what are we talking about when we say that WordPress code is still being written like PHP code was 20 years ago? Well, there’s the reliance on global variables like we mentioned before. Using global variables to store the state of your application is widely seen as a bad development practice. (You can read more on that here and here.)

This reliance on global variables is the symptom of another issue with how PHP code was written 20 years ago. PHP applications only used functions back then. That’s because PHP didn’t really support object-oriented programming yet. So everything was 100% procedural.

Now, there’s nothing wrong with using procedural code or PHP functions. For example, Laravel has plenty of PHP helper functions that you can use. But that’s all they are, helper functions.

PHP functions and global variables aren’t central to the workings of Laravel like they are for WordPress. Laravel is an object-oriented framework. You build things by extending classes and combining them together. (I spend a lot of time discussing this in my book on how to use object-oriented programming with WordPress.)

The problem is that most developers expect to work that way. They’ve used Laravel, Rails, Django or React which are all modern object-oriented frameworks. They don’t want to write PHP code that was modern two decades ago. So it feels like a step back for them to work with WordPress.

Add Ways to Handle Errors

As developers, we make mistakes all the time. (Don’t let anyone else tell you otherwise!) These mistakes can be harmless or they can bring down a WordPress site. With WordPress, the classic way to know if you broke something is the “White Screen of Death“.

There’s nothing more frustrating to a developer than seeing a white screen on a production server. You might not have access to it to see what went wrong. There might not be any good errors for you to diagnose what the issue was.

The White Screen of Death is also a relic from PHP’s past. Modern PHP frameworks all come with code to catch errors that would cause the White Screen of Death. (For example, Laravel comes with error handling built-in as well as a beautiful error page.) WordPress finally got rid of the White Screen of Death in WordPress 5.2.

That said, this only fixes one aspect of error handling in PHP. WordPress still lacks a standardized way to log errors and stack traces. These are especially important when trying to diagnose problems in production environments.

Some plugins solve this problem by implementing their own logging system. (For example, WooCommerce has the WC_Logger class.) If you have your own server that you control (like you do with SpinupWP), you can use auto_prepend_file to add your own logging class. However, this is really something that should be handled by WordPress which is what the trac ticket linked earlier proposes.

Put in a System to Manage Dependencies

Most programming languages and operating systems have a package manager. They’re useful for managing and installing software packages for use by your application. They also allow developers to reuse code more easily between software projects.

PHP’s package manager is Composer. Composer is widely seen as one of the main reasons why PHP has evolved so much as a language over the last decade. It has allowed the PHP community to share high-quality code on a scale that was never seen before.

If you want to use Composer in a WordPress site project, you would need to use a project template like Bedrock or another Composer-ready template like the one we have primed for SpinupWP. And if you want to use Composer in a plugin or theme, things are even more complicated. That’s because there’s nothing preventing plugins or themes from using the same library as you. (That would be Composer’s job to prevent that!)

That’s why it’s often not recommended to use Composer with plugins or themes outside testing. This means that the benefits of Composer have largely escaped the WordPress community.

This is a frustrating reality for a lot of WordPress developers. You can’t work with some of the popular PHP libraries like Guzzle. And there’s no way to create and distribute high-quality libraries that would help strengthen the WordPress project.

That being said, there are ways to safely use Composer packages in a WordPress plugin but they are very much hacks and require extra tooling and testing.

Add an Autoloading API

One side benefit of Composer is that it generates an autoloader for you. If you’re not familiar with autoloading, it’s a system that lets PHP automatically load PHP files for you. It removes the need to have all your files either included or required.

Autoloaders have been a staple of PHP development for over a decade. Even so, WordPress still doesn’t have any native support for it. There have been a few Trac tickets to add some sort of autoloader support to WordPress. This is the currently active one.

Now, it’s not very complicated to implement an autoloader for your plugin or theme. This is the common objection to adding support for it to WordPress. But this is still one more thing that makes the WordPress project feel dated.

These Are All Things That Could Change Right Now

None of what we discussed in this article depends on using a higher version of PHP. They don’t require implementing any of the PHP standards either. They’re just development practices that the WordPress project could choose to put in place right now.

There are a lot of good developers that work on WordPress that could ensure this happens. It’s more of a question of the WordPress project making this a priority. If it did, it would go a long way toward improving WordPress’ reputation in other developer communities.

What other steps do you think could be taken to make WordPress a modern PHP project? Let us know in the comments.