WordPress Performance Team Proposes Developing a New Plugin Checker Tool

WordPress’ Performance team is kickstarting a proposal for developing a plugin checker tool similar to the theme check plugin, which ensures themes are meeting the latest standards and best practices.

In 2021, WordPress’ Meta team built a code scanner that detects potential security risks, such as unescaped SQL queries in plugin code, with the goal of reducing the Plugin Team’s load through automation. That particular tool wasn’t developed to encourage best practices but rather to ensure plugins entering the directory meet the bare minimum standards necessary for security.

The Performance team is proposing building a different kind of plugin that would flag any violations of the plugin development requirements and suggest best practices with errors or warnings.

“It should cover various aspects of plugin development, from basic requirements like correct usage of internationalization functions to accessibility, performance, and security best practices,” Google-sponsored contributor Felix Arntz said. He identified three main goals for the plugin:

  • Provide plugin developers with feedback on requirements and best practices during development.
  • Provide the wordpress.org plugin review team with an additional automated tool to identify certain problems or weaknesses in a plugin ahead of a manual review.
  • Provide technical site owners with a tool to assess plugins based on those requirements and best practices.

The Performance team recommends the plugin also work from the command line (using WP-CLI) and that it go beyond static code analysis to include runtime checks that execute code.

The proposal has received mixed feedback so far. Several participants in the discussion welcome development on such a tool and would be eager to use it with their own plugins. Others are worried about the checks becoming too heavy-handed and negatively impacting the plugin ecosystem.

“Having a plugin to automate these checks sounds great,” WordPress developer Michael Nelson said. “I worry though that eventually this will mean WP plugin author devs will need to adopt WP’s code style too, which would be pretty annoying.”

WordPress developer Josh Pollock commented that he shares these concerns and is worried about how these standards may be applied towards plugins that were not created to support PHP5, use composer for dependency management and automation, and share PHP code with other frameworks.

“If this HELPS plugin developers, then fine, but if it is used as a weapon to insist on standards, then I suspect it will be a nail in WP’s coffin,” plugin developer Robin W said.

“If you want to insist on stuff that is not security critical, then the current documentation is far from useful to rookies.

“Now if the tool rewrote the code to standard, so the dev got a ‘this is a better version’ then I would be on board.

“But one that just says ‘you are not escaping your code correctly’ and then makes the plugin dev try and find what and where it is wrong will just drive less innovation.”

The Performance team is requesting feedback from the community, particularly plugin developers, plugin reviewers, and the meta team. If they are able to reach a consensus, Arntz said the next step is to design the infrastructure for the plugin checker in a GitHub repository.

“The performance team would be excited to take the lead on this project, but it is vital that additional contributors from other teams help with its development, especially when it comes to defining and implementing the different checks,” Arntz said.

“This is certainly an ambitious project, and it is not the first time that a plugin checker has come up. It also needs to be clarified that it will likely take a few months at least to get to a first version. However, we are optimistic that with a solid foundation and collaboration from the start, we can create a tool that will meet the requirements for reliable automated plugin checks.”

7

7 responses to “WordPress Performance Team Proposes Developing a New Plugin Checker Tool”

  1. I tend to worry about such centralized and automated efforts. I am a lowly user, so the only way it would affect me would be if it removed a plug-in that I already use (and not all of us use just the newest, though updating old ones when possible is a routine for me).
    Regarding the above, absolutely it should not just identify that there is a problem and not let the developer know what and if possible how to fix; I could see that discouraging people from submitting a plug-in, and consequently from even developing one.

  2. I believe it’s about time for such a tool, with shared usage between plugin review team and plugin authors, as it will bring clear guides on what are best security and coding practices. It should reduce time, efforts and amount of money invested in developing and reviewing the plugins, and eventually contribute to better user experience.
    Thumbs up!

  3. I hope that if this plugin is actually developed it will cut down on review time when developers create new plugins or update old ones.

    I’ve submitted a plugin on wordpress.org it took a few days to review. After doing several revisions finally accepted.

    I think the WordPress review team really needs this plugin to make their work easier. I really support the making of this plugin.

  4. The story ignores the elephant in the room, which is what is going on with the plugin review team.

    This is at least the third proposal from inside WordPress that tries to address the poor handling of the security of WordPress plugins and other issues with those plugins. None of which has come from the team that is supposed to be handling that. There have been outside efforts as well.

    One problem here is that the team is incredibly undersized, with only 4 members. [1] That isn’t because no one else is willing to get involved, it’s that the current team restricts others from joining.

    Another problem is that there isn’t even agreement about what they are currently doing in terms of reviewing plugins. Matt Mullenweg was quoted here last year saying that they don’t usually review plugins before allowing them in to the directory [2], while the team’s documentation says they do a manual review before allowing them in. [3] The Five for the Future page claims that one member of the team has somehow done reviews of 46,800 plugins. [4] Matt Mullenweg should be aware of what is going on with the team, as 2 of the 4 members are direct employees of his (which isn’t disclosed when the team is telling people the team doesn’t work for his company, either in the form of Automattic or WordPress.com [5]).

    A better course of action might be to first address the governance of that team and then work on improving automated tools to assist a team that is able and willing to tackle the work.

    https://make.wordpress.org/plugins/handbook/the-team/https://wptavern.com/upsells-barriers-and-the-end-beginning-of-the-quality-free-themes-erahttps://developer.wordpress.org/plugins/wordpress-org/plugin-developer-faq/#what-happens-after-submissionhttps://wordpress.org/five-for-the-future/https://developer.wordpress.org/plugins/wordpress-org/plugin-developer-faq/#does-the-review-team-work-for-automattic

  5. I am not sure if best approach would be a plugin. Maybe an WP-CLI tool launched on demand will get better results with no overhead.

  6. If you launch a phpcs with the right rules you already have this.
    The problem is, what are you going to enforce?
    Seems to me it’s just more work just to seems busy.

Leave a Reply

Your email address will not be published.

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

Newsletter

Subscribe Via Email

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

%d bloggers like this: