WordPress Coding Standards Maintainer Warns Maintenance Will Be Halted Without Funding: “This Is an Unsustainable Situation.”

WordPressCS 3.0.0 was released this week with what its maintainer, Juliette Reinders Folmer, says are significant changes to improve the accuracy, performance, stability, and maintainability of all sniffs, and its handling of modern PHP. The project is a collection of PHP_CodeSniffer rules (sniffs) that are used to validate code developed for WordPress, helping developers meet the requirements of the official WordPress Coding Standards.

This update adds many of the non-controversial rules proposed in March 2020 to the Coding standards guidelines but leaves those that generated more discussion or objections for a future release. Many of the new rules are now available as sniffs in WordPressCS.

Version 3.0.0 includes important architecture changes. Most notably, Composer is now the only supported way to install WordPressCS, as this update includes four run-time dependencies. The release contains breaking changes for those using ignore annotations and those who maintain custom rulesets or have created a custom PHPCS standard based on the project. A detailed upgrade guide is available for these various scenarios.

WordPressCS is largely maintained by Folmer and a small group of volunteers, but the future of the project is in jeopardy if they cannot get funding. Folmer said it is currently in a good place with this release but this will not last long with the pace at which PHP is moving.

“WordPressCS 3.0.0 has cost thousands of hours of work and the vast majority of work has been done by one, mostly unpaid, contributor, with code review support from two fellow maintainers,” she said.

“Unless funding is found to continue maintaining WordPressCS and its dependencies, the future is bleak and maintenance will be halted.”

Folmer is calling on corporation and agency users of WordPressCS to find a way to fund the project’s continued maintenance and development. She elaborated on the dire need to have more contributors involved:

If we are being realistic, the bus factor of WordPressCS is 1, which is the most dangerous situation for any project to be in.

A large part of the WordPress community, including WordPress Core, relies heavily on the WordPress Coding Standards for code quality and security checks and while the community has been pretty vocal with copious complaints about the delayed release, barely anyone has stepped up and actually contributed.

The majority of the work for WordPressCS requires specialized knowledge. Knowledge which can be learned with enough time investment, but in recent years nobody has stepped up to do so.

This is an unsustainable situation and it ends now.

WordPressCS has become one of the most highly used open source tools in the WordPress ecosystem that is now in a vulnerable place with so few contributors. Although many developers commented on the release, thanking Folmer for her efforts, no contributors or corporations have publicly stepped forward to support the project’s continued develpment.

“With over 15 million installations on Packagist and a 400% increase in monthly installation in the past three years alone, WPCS’s popularity is surging and shows no sign of stopping,” Lucas Bustamante, a backend developer specialized in automated tests, commented on the post. “The situation is alarming as WPCS is a foundational tool that flags not only code style issues but also critical security issues, making WordPress a more secure CMS. Letting WPCS fall into limbo poses a risk to the entire WordPress ecosystem.”


22 responses to “WordPress Coding Standards Maintainer Warns Maintenance Will Be Halted Without Funding: “This Is an Unsustainable Situation.””

  1. Here is one of those situations in which I am so far out of my depth to really not understand how it might affect my sites or how I can support.

    code standards, sniffs, etc.—I’ve never heard of any of it before, and my first experience with WordPress (posting to a blog that others set up) was in 2008. Since then, I have been involved in site maintenance for a number of grassroots groups, but really still consider myself at most an intermediate maintainer; this is WAY above my “pay grade”, but it sounds important; like something of which everyone who maintains a site should at least be aware. I’m not even sure of where to go to learn. . . . .

    • This is a great question.

      Last month flaws in code from a single source library, used by many plugins to handle licensing, had the dev side rushing to release plugin updates. The flaws would have been caught had the library code been properly linted. Devs also need to lint library code the include via composer, many just ignore the vendor directory with an assumption that “it’s all good in there”.

      • If you are referring to the Freemius library, we warned the developer about the flaws more than a year before they finally fixed them. We found them while doing a security review of a plugin using the library. Unfortunately, catching security issues doesn’t mean they will be fixed.

        Considering that plenty of the biggest plugin developers are not getting their own code reviewed for security issues, it seems unlikely the developers are ignoring the vendor directory. They are just not checking things in general.

    • Yes and no. Certainly most volunteers cannot spend great swaths of time on such things, but it is amazing how much motivated volunteers can accomplish—just look at something like Occupy Sandy, or indeed, so many WordCamps. of course, some volunteer tasks are more rewarding thian others, and often working in groups makes the less-rewarding tasks more congenial, so I think generally a mix of paid/volunteer folks working together as equals (with those with the most time, generally the paid folks) coördinating for continuity can accomplish a lot.

    • I see you are not familiar with PHP_CodeSniffer. Juliette is (realistically) the only one who maintains this too atm. Not only that but PHP_Compatibility and other standards. So stopping using WordPressCS and just using PSR 12 (or whatever would be chosen), wouldn’t solve the bus factor problem…

    • Well, first there is a big difference between WPCS and PSR – not just in style, but in content.
      * PSR only checks for code style/formatting issues and even then is incomplete with no rules about array formatting and some other things.
      * WPCS also checks for code style, but on top of that checks for lots of general coding best practices, can find common mistakes and scans the code for certain security issues.

      So switching to PSR would – aside from a lot of disruption – actually leave devs in the WP Community worse off as they would be missing lots of important checks.

      Secondly, your question includes an assumption: “as there are more maintainers there”. Unfortunately, that assumption is largely incorrect. While there may be more outside contributors to the automated tooling to check PSR, the majority of the work is done by one person – the same person who maintains WPCS… (as WPCS uses part of the PSR sniffs, so its part of the work done for WPCS).

    • Sure WordPress differs from PHPs coding standards in some nonsensical ways (yoda conditions, looking at you) but a lot of what WordPress does improves on what PHP provides. For example the escaping and sanitisation functions are all WordPress functions, not core PHP functions. If we just use PHP coding standards we would be going backwards and would be highly detrimental to the security of the entire ecosystem.

  2. Specialization is unsustainable, yes, people can’t stick to a goal for too long. Presumably people aren’t attracted to this work for good reason, and it’s formulaic nature, which is a process of matching not making or creating, holds out the possibility of automation of mechanical repetition, or at least, worker augmentation and decentralization of this task.

  3. Thank you Juliette for this tool. You’re amazing. For the people that don’t understand the importancy: put your site on PHP8.1 or PHP8.2, switch on your debug log and you will probably find out why.
    If you’re still not convinced: check the PHP end of life times on https://www.php.net/supported-versions.php. Or listen to the podcast of Remkus de Vries with Juliette, that podcast episode still gives me shivers if you really can hear where this can …-let’s use the word- could “END”, certainly when PHP9 comes out.
    Supporting this project is VERY important, and it’s possible via The WP Community Collective.

  4. Maybe the latest version changes things, but up until this point, this has had a decidedly questionable impact on the security of plugins from what we have seen. While it can help identify some security issues, it also can produce some pretty poor results. It sometimes will flag insecure code as being insecure, but for a reason that isn’t actually an issue. So you can end up with developers making change and thinking their code is now secure, when the code still contains a serious vulnerability.

    While misuse of a tool is hard to avoid, it doesn’t seem that it is clearly articulated the significant limitations of it when it comes to its role in reviewing the security of code.

    • Contributions welcome (once you’ve reviewed the latest version with all the hard work that has been put into it instead of generalising about an older version and dismissing all of the recent volunteer efforts…) on the repo!

Leave a Reply

Your email address will not be published. Required fields are marked *

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


Subscribe Via Email

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

%d bloggers like this: