One of the biggest challenges that comes with working with PHP and WordPress is determining which version of PHP to use.

From the WordPress.org Requirements page:

PHP version 5.2.4 or greater (recommended: PHP 5.4 or greater)

With respect to PHP, a lot has changed between 5.2.4 and 5.4. And the problem, for developers, usually comes down to something like this:

If we opt to stick with the oldest supported version then we have the largest audience appeal, but if we stick with newer versions then we get some nice, new features in the language but at the expense of certain hosts.

So when it comes to WordPress and PHP, what do we do?

Use The Base Version

Personally, I used to be of the mindset that we should always be using whatever the minimum required version for our projects to make sure that we’re as compliant with as many hosts, as many installations, and as many copies of WordPress as possible.

But if you work on enough projects and you begin to hit pain points in your code, you begin to see the benefit of some of the newer PHP features. These include:

  • Namespaces
  • Closures
  • Constants
  • The ternary operator
  • Autoloading
  • Generators
  • Iterators
  • …and many, many more.

Though all of the above may not be applicable to the code that you’re writing for WordPress, I’d venture to say that some of them are applicable to what you are working on or what you may be working on in the near future.

WordPress and PHP

“I dunno which version to use.”

As I mentioned a moment ago, I used to think that using the minimum required version and forgoing these new features was the right move. Now, though, I think that kind of perspective is a little narrow-minded.

Use The Most Recent Version

There are times where that’s exactly what we need to be doing. For example, if you’re working on a theme and you’re truly focused on just creating something at the presentation level, then I think you’re okay to stick with the minimum required version of PHP.

But if you’re working on a more advanced plugin or application, then there’s a lot of benefit to be gained from some of the newer features. Yes, it might come at the expense of alienating some of the potential audience, but that’s a business decision that you have to make based on who you’re targeting.

Far too often, I think we try to oversimplify things by saying “Either it’s going to work for everyone or just some people,” and then we make our architecture decisions based on that. But is that really the best decision? I mean, it’s kind of a blanket generalization, isn’t it?

Identify The Best Version

What if we were to take each project as it comes down our pipeline, determine who the intended audience is, and then go from there? There are other parallels to this in the WordPress development community, as well.

If you take a look at ways in which plugins and themes are now being built with more sophisticated tools as opposed to just dropping libraries and dependencies into directories and managing them on our own, I think it’s time that we begin shifting away from the all-or-nothing mentality of the version of PHP and start looking at our projects on a case-by-case basis.

No, dated versions of PHP are not going to be going anywhere anytime soon, and I love that the WordPress core team is working with various hosts to try to move the version forward, but there’s also an active role that we – as developers, consultants, etc. – can play in this: We can advise the people for whom we’re building solutions on what hosts are best for their project.

We don’t have to drop in all of the jargon that talks about language features and so on (because who cares but us?), but talking about how it can improve the integrity of the application can go a long way.

Who wants to say they have their work running on an out-dated environment? I digress. The point is that we aren’t going to be able to sell what we want to use to our customers if we speak our language. We need to speak to the business needs for those whom we’re working.

So identify which version works best for the problem that’s to be solved, work on communicating the benefits to the customer in their terms, and then proceed from there.

This is at least one practical way to get started using newer features with PHP in WordPress all while moving your own projects forward.

Category:
Articles
Tags:

Join the conversation! 5 Comments

  1. Well, this is timely given that I just fixed a bug in my plugin related to the PHP version.

    As far as plugins are concerned, if there are usage stats somewhere on the various PHP versions running on WordPress sites (and perhaps there are, I really haven’t looked), that could influence my decision on the minimum PHP version to support. Similar to the front-end world when deciding which browser versions to support based on market share.

      • That’s scary, John! One in six WP websites are still on 5.2.

        So many of those features Tom mentions I am not up-to-speed with because it’s easier to write 5.2 compatible code than having to write dual-code. But you don’t learn what you don’t use. I did accidentally for a while have my MAMP set to 5.3 and used some 5.3+ techniques, and consequently had to write some legacy routines when I got the shock of someone saying – “this gives errors!”

        Thus I became even more cautious and reticent.

        WP is the only PHP I write for – so I’m blaming them for holding back my development! :P

        Automattic should have made WP4.0 at least PHP 5.3 dependent – and then I could have started using and learning all that cool stuff.

  2. The only thing I would add is I think we really need to get to the point where we’re not supporting PHP5.2. PHP5.3 is almost EOL as it is, and it seems crazy to me that we’re not able to integrate namespaces in particular without losing some of WordPress’s install base. I really want to know who these hosts are that still run 5.2.

    There is also this package:

    https://github.com/WPupdatePHP/wp-update-php

    which you can bundle with your themes/plugins to check for the current version and display a notice for the user to update their PHP version. I really hope these sorts of things get enough traction to actually move the needle to the point where core will support 5.3+. 5.3 is just leaps and bounds ahead of 5.2, so even just taking that step would be great. I’m personally less concerned with 5.4+. But yeah, abandoning 5.2 I think is kind of a big deal at this point.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.