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.
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:
- more experienced PHP-oriented developer friends endorsing tools that expect the PSRs to be adopted,
- the use of //@codingStandardsIgnoreStart and //@codingStandardsIgnoreEnd in my code,
- custom rulesets for my projects based on the environments to which they are behind deployed,
- and more.
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.
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.
Agree with you. WordPress coding standards were created specifically for WordPress and the PHP version it supports, which is the very old 5.2. While PSR is pushing things forward, it enables us to use modern tools like Composer to manage dependencies better. In the next few years, when the minimim requirements for WordPress is not PHP 5.2, things might change.
Thanks for this post. I decided to use PSRs for my code a while ago (something like 1 year ago), because of more or less the same reasons.
I think PSRs is a good set of standards and a lot of wise developer use them. So they cannot be completely wrong.
But one aspect, which lead me to the decision switching completely to PSRs is that I now develop Laravel Apps as well as WordPress Plugins and I don’t want to switch everytime my coding style. It helps me to think about the logic and not worrying about the style I use.
Just a few weeks ago I was looking for a nice PSR-4 WordPress plugin template, which I found here: https://github.com/dmhendricks/wordpress-base-plugin
Maybe this is also interesting for you.
It would be really great if WordPress adopted PSR 1 and 2. It’s sooo annoying toggling syntax check if coding for WP :(
It’s a struggle. I’m very accustomed to reading WP style code to the point that anything else just “looks wrong”. That said I’d welcome converting core to PSR 1/2 an adopting those. That seems pretty simple and probably worthwhile to me. PSR 4 would be harder, but I think that’d be worthwhile too, it just might take a while to do all the needed refactoring.
BTW, have you tried WP-Enforcer https://github.com/stevegrunwell/wp-enforcer ?
The timing of your post is a bit unfortunate as the WordPress Coding Standards will be compatible with PHPCS 3.x (as well as PHPCS 2.x) once we release the new version next week.
If you want to try it out, check out the WPCS
developbranch on GitHub to see it working ;-)The other thing I’d like to point out is that one does not preclude the other.
What I mean by that, is that you can still use the WordPress Coding Standards with all the best practice sniff it includes – things like checking that output is escaped, that no deprecated WP functions are used, that all globals are prefixed -, while using PSR2 for the more code-style related checks.
This would, of course, require a custom ruleset, but shouldn’t be that hard to set up.
Nearly all best practice related sniffs within the WordPress Coding Standards have been set up to be code-style independent, so should work just as well when you use PSR-2.
(and for the few which don’t, we’re working on that)