WordPress is a dinosaur. If you are a PHP programmer and have had the opportunity to work outside of WordPress in the past 10 years, there are likely one or two or a few dozen things that frustrate you when diving back into the project’s 16-year-old codebase. At a time when WordPress is gifting JavaScript programmers with the latest and greatest goodies, those doing PHP work can feel left behind.
There is a good reason for the legacy code in WordPress: it is backward compatible with over a decade of third-party extensions. Plus, old code does not necessarily equate to bad code. If it ain’t broke — well, you know how the rest goes.
Last year, WordPress bumped the minimum requirement for running the software to PHP 5.6 or newer. Many developers cheered in support of features such as short array syntax, namespacing, and the spread operator. Others wanted to jump to PHP 7+, but PHP 5.6 was a good stepping stone to more modern PHP code.
This change opened some new questions. When will core WordPress begin using new features? What coding standards should the project follow?
WordPress 5.3 made use of the new spread operator, which cleaned up and simplified several functions. It showed a willingness of the core leads to update some outdated code while avoiding backward-compatible issues.
An Updated Set of Standards
To begin using modern PHP features in WordPress, the platform’s coding standards must evolve. On March 20, Juliette Reinders Folmer proposed an extensive set of guidelines. The proposal is a draft and will need to be fine-tuned based on feedback from developers and core contributors.
“While it may still be a while before some of these features will actually be adopted for use in WordPress Core,” wrote Folmer, “defining the coding standards in advance will allow for a consistent code base when they do get adopted and will allow for plugins and themes, which are not necessarily bound to the PHP 5.6 minimum, to safeguard their code consistency when they start using more modern PHP already.”
The proposed standards are broken down into the following topics:
- Namespace declarations
- Import
usestatements - Traits and interfaces
- Type declarations
- Declare statements / strict typing
- The
::classconstant - Operators
- Additional new rules covering various items
Any code that goes directly into WordPress must follow the project’s coding standards. It is strongly recommended that plugin and theme developers adopt the same standards, but it is not a requirement for inclusion in the official plugin and theme directories. Coding standards across an ecosystem make it easier for one developer to pick up code from other developers without having to learn unique styles between extensions.
On the whole, the update look solid. There is a lot to like about this proposal, and it would be a welcome addition to a set of guidelines that sorely needed a refresh.
One of my biggest gripes is around file naming. The WordPress project should drop the use of class-, interface-, and trait- prefixes from PHP filenames. Instead, we should use this opportunity to adopt the PSR-4 autoloading standard’s naming convention. In that standard, the filename matches the class, interface, or trait’s name exactly. At the very least, the prefixed filenames should not be a recommendation that goes out to WordPress developers everywhere. Keep it for core if necessary for tradition, but don’t recommend widespread usage of a system that is years out of touch with modern PHP.
I would also like to see WordPress adopt the use of Pascal case (i.e., ExampleProject) over camel caps (i.e., Example_Project) for namespaces. However, given the tradition of camel caps for class names, I do not see this changing. This is a bit nit-picky, but it feels out of place in comparison to other, more modern PHP projects.
The biggest thing the WordPress developer community can do right now is to discuss the proposal and offer feedback. Most of the work is done. It is up to the community to help push it forward.
