Cancel

Justin Tadlock

Proposal to Update the WordPress Coding Standards for Modern PHP

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 use statements
  • Traits and interfaces
  • Type declarations
  • Declare statements / strict typing
  • The ::class constant
  • 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.

Category:
19

19 responses to “Proposal to Update the WordPress Coding Standards for Modern PHP”

    • That would be a massive undertaking and would require a large group of developers. Time would likely be better spent working on core WordPress and improving areas where they can. The spread operator changes linked in the post is a good example of that. Those changes cleaned up several functions without breaking things.

      Create forum topic from comment

      • True. But the longer the wait, the more massive the elephant gets. When a product is responsible for such a significant percentage of the internet at what point is it responsible and/or obligated to move itself – and all who depend on it – into the 21st Century?

        Create forum topic from comment

  3. WordPress should go with PSR coding standards (1-12) like the rest of the PHP world goes: https://www.php-fig.org/psr/

    As the name says, the PSR is THE standard recommendations for PHP coding styles.

    There is no need to waste resources by implementing a custom WordPress coding standard that is not compatible with the PSR. If WordPress wants to attract more professional developers it’s the only correct answer.

    Create forum topic from comment

  5. PSR-4 naming convention is something I think should be included in the WordPress coding guidelines. Autoloading is often considered a core php functionality these days.

    I wonder what other changes to WordPress coding standards will be necessitated by this single change. My father referred to this sort of thing as the “Pillow Effect” where he would end up remodeling the entire living room after my step mother goes shopping for a new throw pillow. (The new pillow doesn’t really match the current sofa, necessitating a new sofa, the new sofa doesn’t really look right with the old coffee table, so a new coffee table is needed, and so on & so on…)

    Create forum topic from comment

  9. There are some rules in the WPCS like file naming, namespace naming, etc. which makes me ignore them. I still find things like spaces in WPCS is good.

    If possible, for “new” things like namespaces, autoload, I’d suggest WP to follow PSR. It works out of the box with a simple line in composer.json. WP doesn’t have that and we all have to write our custom code to autoload classes.

    Create forum topic from comment

  13. I think that will do wonders for WordPress. The main issue right now is that is the wild west. Everyone codes to their standards, or no standards and you end up with code that has a high level of complexity, code should be easy to work with in order to add new features quickly and fix bugs.
    Less time working on code means more time working on adding more value and fixing bugs faster. Right now there are functions that go for hundreds of lines, that can moved into a whole group of service of classes that will make it a lot easier to work with.
    Also, this means that it can get faster because its not enough to just run the latest PHP, you also need to follow the standards and the new ways to work with that code, by doing so you are taking full advantage of the language’s caching and faster functions.
    Overall, I hope they do this soon. WordPress is screaming for it as it is very popular but very poorly written. We need a SOLID codebase.

    Create forum topic from comment

You may also like

Newsletter

Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.