At this point, I don’t know how many articles I’ve written about the importance of the WordPress Coding Standards (enough to link to them here, here, and here, I guess, which counts for something).

But after doing enough projects for clients and working with developers who are far smarter and familiar with advanced tooling than I am, I’m at a place where I’m opting to start using PSRs in WordPress WordPress development.

Using PSRs in WordPress Development

Oh the drama, right?

Seriously, though. There are reasons for this, and there are times in which I think the WordPress Coding Standards should still be used, but I’m quickly becoming more convinced that building any modern project on top of WordPress should use more modern PHP tools (which I’ll briefly mention later).

Using PSRs in WordPress Development

Posts like this often insight some debate or dramatic response within WordPress which isn’t my intent nor is it something that I think is even necessary. To be honest, I know a fair number of other developers all of whom have done this long time ago, talked about it, moved forward, and continued to have success both in their business and in their hobby projects.

But given that I’ve talked about one versus the other so much, I thought with worth sharing my take on why I’m opting to make this shift now and the rationale behind it.

1. Parity with the PHP Community

Over the past year or so, and really within the past few months of this year alone, I’ve become more accustomed to:

Ultimately, it’s about wanting to maintain parity (or a bit of it) with the greater PHP community-at-large while also writing readable, standards-based code on top of WordPress. And I’d also like to use some other tools and more recent versions of existing tools (that I’ll discuss later in this post).

2. Problems with Modern Environments

At the time of writing this post, the PHP CodeSniffer (which is required to run the WordPress Coding Standards) is at version 3.0.2. However, there are compatibility issues with PHPCS and with the WordPress Coding Standards. Specifically:

The new version of PHP CodeSniffer has some nice features, but introduces breaking changes which mean that the WordPress coding standards are not compatible.

To be clear (and because of the nature of software), it’s a matter of time before it’s fixed. But if you’re working on a codebase and you’re using Composer and the WordPress Coding Standards, you’ll need to explicitly set the PHP CodeSniffer version rather than whatever the most recent version currently is.

Furthermore, I’ve experienced issues with clients where my not adopting the PSRs in WordPress development has resulted in odd behavior when deploying code. Perhaps a case could be made that they should adjust the environment but if they are working to have the most modern tools available to the people who are using them, why regress?

3. Compatibility with Modern Tools

Finally, there are a number of modern tools that I’ve been unable to use, let alone unable to learn, because of what is and what isn’t supported by the nature of versioning.

Using PSRs in WordPress Development with Modern Tools

For example, we were using GrumPHP in a recent project which has support for a variety of tools but we were unable to use, say, PHPMD because of lack of adoption of the PSRs. As far as I’m concerned:

  • I want to continually level-up my skills as a developer (and, in this context, a PHP developer),
  • lack of support for more modern tools puts me in a holding pattern that I’d otherwise not experience,
  • I want to continue to work with WordPress but do so with a more modern workflow

And right now, not using the PSRs is creating a gap between what the rest of the PHP community is doing and what WordPress is doing. So I’d like to move forward while maintaining working on projects on top of software I still enjoy using.

What About The WordPress Coding Standards

So what’s this mean about the WordPress Coding Standards and previous posts? Nothing, really. The way I see it: The WordPress Coding Standards should be used whenever you’re working on WordPress Core or something that’s going to be closely integrated into it.

But if you’re working on something that sits on top of WordPress or something that uses WordPress as a foundation and you can use the PSRs in WordPress development along with tools that can help increase the quality of the codebase that you’re building.

So, at least for now, that’s the perspective I’m going to adopt. I’m eager to see how it pans out over the next few months. And, as for anything else I’ve shared, I’ll share the aspects of making this switch.