Plugin Check Goals & Roadmap

PluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party Check, a multi-team effort within the WordPress project, is designed to allow plugin authors to check the plugins they develop to catch and self-service commonly found issues seen in plugin initial submissions and re-reviews for WordPress Plugin Directory Guideline violations, security issues, and plugin development best practices. If you have not already done so, I recommend reading the Introducing Plugin Check (PCP) post and the post outlining PCP becoming a pre-submission requirement for new plugins to Plugin Directory before reading the rest of this post.

Goals of Plugin Check

The goals of the Plugin Check Plugin (PCP) within the Plugins Team are primarily to:

  • Allow developers to self-service issues found in initial plugin reviews
  • Improve the security of plugin code
  • Promote best practices within plugins and ensure Directory Guidelines compliance

Let’s dive into each of these to explore them in more detail, and talk about how they correspond to goals found in the roadmap for Plugin Check.

Allow Developers to Self-Service Issues Found in Initial Plugin Reviews

The majority of the issues that are caught with plugins in the initial review of a new plugin are violations of the Guidelines or issues with Plugin Directory rules (such as: not using a unique prefix for names of classes/functions; an invalid readme; plugin versions in the readme not matching the plugin headerHeader The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes.; etc).

Our goal is to allow plugin developers to test for the majority of these before they submit their plugin with one click using Plugin Check. As a backup, a more limited set of these checks (the ones that almost or neverdeliver a false positive) are automatically run against a plugin before it can be submitted into the queue (this part is already live on WordPress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/). 

This process helps developers address issues before submission, reducing back-and-forth and speeding up reviews. It saves time for the Plugins Team and allows new plugins to go live on the repository more quickly. To improve upon this, one of the goals for Plugin Check is to further this goal by adding more checks, making the UXUX UX is an acronym for User Experience - the way the user uses the UI. Think ‘what they are doing’ and less about how they do it. of the plugin better, and building more ways for plugin authors to build Plugin Check into their development flow.

Improving The Security of Plugin Code

While no static analysis or rule set tool will ever be able to catch 100% of security vulnerabilities in plugins, our goal with Plugin Check is to aggressively work on tackling the ones we see most commonly. The majority of security issues generally found in plugins are things like missing nonce/capability checks or missing sanitization/escaping/validation— issues that are oftentimes easier to build detection around. By helping developers catch and address potential security issues, especially before release, we can make plugins more secure overall.

During Phase 1 of the security categoryCategory The 'category' taxonomy lets you group posts / content together that share a common bond. Categories are pre-defined and broad ranging. rollout for developers submitting plugins for security re-review, the team has observed that even the limited checks in Plugin Check significantly improve plugin security and reduce the time reviewers spend on these reviews by minimizing follow-up messages.

In Phase 2, we will focus on adding more comprehensive checks for additional common security issues found in the .org repository.

Promote best practices within plugins and ensure Directory Guidelines compliance

The Plugin Directory now hosts over 60,000 plugins crafted by a diverse group of authors, ranging from first-time developers to seasoned commercial plugin companies. These plugins span a wide spectrum—some offer simple quick fixes, while others are robust SaaS replacements. They also reflect varying levels of community involvement, from WordPress CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Committers to software companies integrating their services with WordPress.

Because the Plugin Review Team reviews plugins from authors with varying levels of experience, we occasionally encounter plugins that violate the Plugin Directory Guidelines or contain code that deviates from WordPress development or security best practices. Most violations or oversights come from authors unfamiliar with the Guidelines, so the team approaches these cases as teaching opportunities rather than punitive actions.

With WordPress Core and GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ evolving rapidly, even experienced plugin authors may struggle to keep up with the latest best practices. While the Plugin Team and Core Teams provide resources like Make Posts and pre-release emails to communicate key updates, the Plugin Check project aims to simplify this process. Plugin Check allows authors to quickly scan their plugins for performance improvements and best practice opportunities.

The Plugin Team has collaborated with teams like the Performance Team, co-developers of Plugin Check, to identify performance enhancements and catch common Directory guideline violations. In Phase 2, we plan to expand these checks and collaborate with additional teams to further support plugin authors.

We’ve recommended that plugin developers integrate Plugin Check into their development workflow and have worked to make it as accessible as possible by enabling multiple ways to run it:

  • As a standard WordPress plugin (with UIUI UI is an acronym for User Interface - the layout of the page the user interacts with. Think ‘how are they doing that’ and less about what they are doing.)
  • As a WordPress CLICLI Command Line Interface. Terminal (Bash) in Mac, Command Prompt in Windows, or WP-CLI for WordPress. command
  • As a one click GitHubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ Action (to integrate with development workflows — repository link / GitHub Marketplace link)

We’ll continue improving Plugin Check in Phase 2 by simplifying output customization for easier integration.

Phase 2 Roadmap Overview

In Phase 1, Plugin Check was released to the community as a plugin available through WordPress.org. It became a requirement for new plugin submissions to the Plugin Directory and for relisting plugins that were pulled due to security issues, requiring all Security category checks to be passed.

In Phase 2, Plugin Check will expand to cover updates made by plugin authors to plugins already in the Directory. The initial rollout will include a post-SVNSVN Short for "SubVersioN", it's the code management system used to maintain the plugins hosted on WordPress.org. It's similar to git. check-in process, where Plugin Check will email plugin authors about detected issues and notify Plugin Team members based on severity.

Specific rollout timelines and processes for Phase 2 will be shared in a future Make Plugins post as its release approaches.

To roll out Phase 2, the Plugins Team will prioritize essential updates to Plugin Check, considered prerequisites for this phase. These updates will collectively define the Phase 2 priorities.

  1. Improve Documentation and Messaging: Ensure every Plugin Check rule has clear documentation and intuitive messaging to make it self-service. Each check should explain what is wrong, how to fix it, and where to find updated resources. This reduces questions about individual checks.
  2. Develop Conditional Rule Application: Create a system to exclude or conditionally apply rules. This allows flexibility for custom check categories and handles evolving guidelines, such as varying prefix length requirements based on a plugin’s addition to the Directory.
  3. Enhance User Interface: Improve Plugin Check’s UI to help plugin authors quickly understand check categories, distinguish required vs. optional checks, and create a cohesive experience for custom rulesets added by developers or companies.
  4. Introduce Experimental Checks: Add an experimental checks feature to let plugin authors betaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process.-test new rules before they become mandatory. This helps identify edge cases, encourages contributions from new developers, and supports iterative rule development.
  5. Build Retroactive Directory Integration: Enable Plugin Check to run on plugins already in the Directory after a release. Alerts based on the severity of issues detected will notify the Plugin Team and/or plugin authors. This integration ensures ongoing improvement of plugins, leveraging the success of Plugin Check for new submissions and enhancing the overall quality of the Directory.

We’re excited to kick off development of Phase 2 of Plugin Check! If you’re a plugin author, we encourage you to integrate Plugin Check into your development workflow. The GitHub Action is a great starting point, and running Plugin Check against your existing plugins can help identify improvement opportunities (repository link / GitHub Marketplace link). Additionally, spreading awareness is crucial—tell other plugin authors you know about Plugin Check. The more developers who use it, the better the tool becomes for the entire community.

For those interested in contributing directly to Plugin Check, you can find the GitHub repository here. Whether you have ideas for new checks, want to write or test code, or help improve documentation, there are always tasks needing assistance. We’re grateful for any contributions to help improve Plugin Check and support the WordPress ecosystem.