For a long time, WordPress has had the theme check plugin, a tool which statically analyzes a given WordPress theme to determine if it follows certain theme development requirements and best practices.

This post proposes defining and implementing a similar tool for WordPress plugins that analyzes a given WordPress 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 and flags any violations of plugin development requirements and best practices with errors or warnings. It should cover various aspects of plugin development, from basic requirements like correct usage of internationalization functions to accessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility), performance, and security best practices.

This post is based on an earlier proposal document that has been reviewed and discussed by the performance working group over the last several weeks (see original Slack message sharing the proposal).

Goal and use cases

The goal of the plugin checker would be largely equivalent to that of the existing theme checker, fulfilling similar purposes for plugins. Specifically, the primary goals would be to:

• Provide plugin developers with feedback on requirements and best practices during development.
• Provide the 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/ 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 plugin checker should be implemented as a plugin itself, allowing it to be used by similar environments to the theme checker. However, the scope of the plugin checker should preferably be slightly expanded so that it can better adapt to different environments to satisfy the following use cases:

• It should support checking a plugin both from a WP Admin 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. and from the command line (using WP-CLIWP-CLI WP-CLI is the Command Line Interface for WordPress, used to do administrative and development tasks in a programmatic way. The project page is http://wp-cli.org/ https://make.wordpress.org/cli/), so that it can be conveniently run during local development or for Continuous Integration, e.g. a 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 by the repository owner. https://github.com/ action.
• It should include checks that go beyond static code analysisStatic code analysis "...the analysis of computer software that is performed without actually executing programs, in contrast with dynamic analysis, which is analysis performed on programs while they are executing." - Wikipedia, such as runtime checks in which code from the plugin is actually executed, to allow for additional best practices to be covered.
• It should allow for customization of which checks are run for a plugin, including allowing optional or experimental best practices checks to be opted in to, or excluding certain checks for more of a baseline audit.

Project breakdown

The idea is that this plugin checker plugin would be developed in a GitHub repository and eventually be published either as a plugin in the wordpress.org plugin repository, as a Composer package on Packagist, or both. An additional means of distribution could be to also publish it as a configurable GitHub action. From there, both developers and site owners would have access to it and could use it as they prefer.

Once the plugin is more established, opportunities for this new tool to be integrated into the wordpress.org plugin submission infrastructure should be explored in order to automate parts of the largely manual plugin review process and potentially catch additional problems. The customization of which checks to run is critical particularly for this purpose, as there is a good chance that the plugin repository would run a different set of checks than the default configuration, emphasizing the more foundational requirements for all plugins.

While the initial purpose of the plugin checker will be for plugin developers and site owners to use the plugin checker, all of the above use cases need to be considered during all stages of development of the tool.

Proposed approach

As outlined above, the plugin checker should be implemented as a plugin itself, primarily so that it is easy to install and usable within WP Admin UI for site owners or developers. In addition, it should provide a WP-CLI command so that plugin checks can also be conducted from the command line.

The tool’s static code analysis checks should rely on an internalized version of PHP_CodeSniffer, providing more flexibility and simplifying maintenance, as this is an established tool. There are already existing WordPress tools for automated plugin analysis, and several of them also use PHP_CodeSniffer, which would mean that the new tool could use some already established checks. In addition, usage of PHP_CodeSniffer would allow even environments that are not WordPress to run at least the static analysis checks.

While many plugin requirements can be checked through static code analysis, this method has its limitations, especially when it comes to certain accessibility and performance best practices. That is where having dynamic runtime checks available in addition to static code analysis will be critical. Dynamic runtime checks are different in that they actually run the plugin and thus can detect additional issues such as uncached or slow database queries. They can also more reliably identify problems around excessive scripts and stylesheets being enqueued.

One of the main complexities around plugins compared to themes is that plugins essentially have an almost unlimited feature set – they can do anything. This makes it impossible to predict their expected behavior. It also complicates defining a reliable set of rules and guidelines to check for. However, there are certain ways to at least to detect what a plugin does, for example when using certain WordPress APIs, such as to register post types or blocks. Such detection mechanisms would benefit from runtime checks as well; for example a plugin may not affect the homepage of the website in any way, but it could cause several issues just in posts of a certain post type. Dynamic checks allow for such problems to be identified.

In addition to static analysis and server-side runtime checks, it could also be beneficial to include client-side checks. Again, there are certain accessibility and performance best practices that could only be reliably detected through such checks. One complexity of client-side checks, though, is that they would only work in a browser environment, so it would be challenging to run them from the command line except in an environment where a headless browser is configured. This makes running such checks infeasible in certain environments. For this reason, the proposed approach for the plugin checker would be to start with a focus on static analysis checks and server-side runtime checks, but build the infrastructure in a way that client-side checks could potentially be added in the future.

For some additional context on the different types of checks, see the earlier proposal document.

Next steps

At this point, the performance team would like to gather feedback on this proposal from the wider community, especially from plugin developers, the plugin review team, and the metaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. team. Please share your thoughts, questions, or concerns in the comments.

Once there is consensus on a path forward, the next step would be to design the infrastructure for the plugin checker plugin and start implementing it in a new WordPress 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.

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.

Props to @shetheliving, @mehulkaklotar, @manuilov, and @ipstenu for review and proofreading.

#performance, #plugin-check, #proposal