Felix Arntz 4:09 pm on July 5, 2022
Tags: performance, plugin check, proposal ( 2 )

Proposal for a WordPress plugin checker

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 be 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

Scott Kingsley Clark 4:20 pm on July 5, 2022

I absolutely love how this could help new and existing 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 devs!
- Felix Arntz 8:34 pm on July 12, 2022
  
  Thanks, great to have you on board!
Till Krüss 4:21 pm on July 5, 2022

I’d love to run this continuously for Redis Object Cache.
- Felix Arntz 8:35 pm on July 12, 2022
  
  Awesome! Early usage will be very helpful in identifying any quirks during development of the tool.
Thomas Patrick Levy 4:32 pm on July 5, 2022

As a 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 developer I wholeheartedly support this effort.

My team already runs a number of static checks such as PHPCSPHP Code Sniffer PHP Code Sniffer, a popular tool for analyzing code quality. The WordPress Coding Standards rely on PHPCS. based off the WPCSWPCS The collection of PHP_CodeSniffer rules (sniffs) used to format and validate PHP code developed for WordPress according to the WordPress Coding Standards.
May also be an acronym referring to the Accessibility, PHP, JavaScript, CSS, HTML, etc. coding standards as published in the WordPress Coding Standards Handbook. standards. We run a host of automated test suites as well.

For me this would be another tool I can integrate into our deployment process to ensure that we continue to adhere to standards and practices as they evolve and change.

I’d like to note that for use internally (on my team) we’d very much like to be able to customize and extend whatever the base rules are. I don’t have any particular examples off hand but I’m sure if it’s being developed as a WordPress plugin by WordPress devs it will by default be extensibleExtensible This is the ability to add additional functionality to the code. Plugins extend the WordPress core software.. But I thought I’d mention this anyway.

I’ll be following progress here. Thank you!
- Michael Nelson 4:50 pm on July 5, 2022
  
  Having a 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 to automate these checks sounds great. 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. Some of the WP coding standards make sense for historical reasons (that’s just how we’ve done it for so many years, like every file that contains a class needs “class” in its file name, and discouraging the use of custom tables and direct db queries). Many plugins have chosen to follow different coding standards (eg PSR) and I’d hate for potential users to be warned to not use them unless they adopt WP’s coding standards (some would rather die than use yoda conditionals! Jk, mostly).
  So I think it will be necessary to distinguish between WP coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. best practices and plugin best practices.
  - Josh Pollock 5:13 pm on July 5, 2022
    > I worry though that eventually this will mean WP 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 author devs will need to adopt WP’s code style too, which would be pretty annoying.
    
    I share this worry and would also be annoyed by having to follow WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. standards in a plugin that:
    
    Does not support PHP5
    
    Uses composer for dependency management and automation
    
    Shares PHPPHP PHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-purpose scripting language that is especially suited for web development and can be embedded into HTML. http://php.net/manual/en/intro-whatis.php. code with other frameworks.
    
    Is developed by PHP developers who use PHP for WordPress development and with other frameworks.
    - Devin Walker 9:24 pm on July 5, 2022
      
      I second all that Josh said above. We wouldn’t want to be flagged for any of the above items, which the common WP user could think would be slowing down their site.
      - Felix Arntz 8:12 pm on July 12, 2022
        
        Thank you all for your feedback. I should have clarified in the post, any enforcement of WP code style is entirely out of the question here, the same way that the existing WP theme check tool doesn’t enforce it.
        
        We are going to use PHPCodeSniffer, and we are probably also going to reuse some sniffssniff A module for PHP Code Sniffer that analyzes code for a specific problem. Multiple stiffs are combined to create a PHPCS standard. The term is named because it detects code smells, similar to how a dog would "sniff" out food. that come directly from WPCSWPCS The collection of PHP_CodeSniffer rules (sniffs) used to format and validate PHP code developed for WordPress according to the WordPress Coding Standards.
        May also be an acronym referring to the Accessibility, PHP, JavaScript, CSS, HTML, etc. coding standards as published in the WordPress Coding Standards Handbook., but those would all be related to security, performance, other functional best practices, not at all code style.
        
        I hope this alleviates your concerns – enforcing any code style was never the plan for this project, and the usage of PHPCodeSniffer here probably falsely raised the concern that it might. 🙂
  - charliespider 7:16 pm on July 5, 2022
    
    totally agree with everything Michael said.
    
    for the record, I am one of those developers who would rather die than use yoda conditionals!
  - Michael Ott 1:51 am on July 7, 2022
    
    I share these concerns, and I’d hate for this to be used as an excuse for conformity.
    
    No all plugins are developed equal. I’d hazard a guess that some of the best and most popular plugins don’t necessarily conform to WPs idealised standards.
    - Felix Arntz 8:14 pm on July 12, 2022
      
      See my reply in https://make.wordpress.org/plugins/2022/07/05/proposal-for-a-wordpress-plugin-checker/#comment-44083: The 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 checker is definitely not going to enforce any code styles, it’s only about standards that really matter for plugin quality, e.g. security, performance, 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) best practices. Where you put your spaces or whether you use Yoda conditions isn’t part of that 🙂
Robin W 5:40 pm on July 5, 2022

hmmmm…….. If this HELPS 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 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.

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

eg ‘Code integrated into the WordPress ecosystem – including WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress., 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/ websites, and official plugins, is expected to conform to the Web Content 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) Guidelines (WCAGWCAG WCAG is an acronym for Web Content Accessibility Guidelines. These guidelines are helping make sure the internet is accessible to all people no matter how they would need to access the internet (screen-reader, keyboard only, etc) https://www.w3.org/TR/WCAG21/.), version 2.1, at level AA.’
and
‘The WordPress A11yAccessibility 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) team is in the process of developing a library of recommended accessibility patterns to help describe the WordPress recommended way to accomplish a variety of interfaces. ‘ – really? – WTF does that mean ??????? seriously – what does that mean???

If you start rejecting plugins because for instance they don’t use the ‘brace’ standards, then I’ll just give up.

I already have several plugins that I have not uploaded to WP, as it takes far too long to code to ‘standards’ eg internationization – I write code to work and be useful to others and for fun, not to obey rules that whilst laudable take forever to code.

Plugin devs are not paid, and the original wp concept of loads of useful open software code that augments WP seems to be getting lost in a rules based regime.

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

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.
- Felix Arntz 8:18 pm on July 12, 2022
  
  To clarify, the plan for this 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 checker is not at all to enforce any code styles, also see https://make.wordpress.org/plugins/2022/07/05/proposal-for-a-wordpress-plugin-checker/#comment-44083.
  
  For some of your other concerns, 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) and internationalization are vital for a ton of users around the globe to use a plugin, so it is likely that some of those checks will be part of the plugin checker.
  
  With that said, not at all every check in this tool will be required for plugin submission, one of the main features here will be that the checks are customizable. So the plugin submission infrastructure could specify their own set of required rules, and so could you depending on how you prefer to develop.
Jonathan Desrosiers 7:50 pm on July 5, 2022

+make.wordpress.org/core
Tellyworth 10:48 pm on July 5, 2022

How would the set of guidelines and recommendations for coding standards be decided?

There was an earlier proposal for discussion that was not well received: https://make.wordpress.org/meta/2021/04/27/automatically-catching-bugs-in-plugins/

The work of building scanning and reporting tools is of course interesting and important. But, having spent some time down that rabbit hole, the hardest part of the problem is effectively communicating code problems to users and developers, and directing them to useful documentation on how to fix their code.

I’m on mobile this week but will be very happy to discuss some more when I’m back at a proper keyboard.
- Felix Arntz 8:28 pm on July 12, 2022
  
  One of the main features of the tool proposed here is that it would allow customization of which guidelines/recommendations to consider. The tool would have a set of defaults, and there would also be differentiation between what is a “guideline” (i.e. error if the code doesn’t follow it) vs a “recommendation” (i.e. just a warning, not causing an overall failure). If the 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 submission infrastructure eventually used this, I would envision that it would exclude certain checks that are less critical for every plugin to respect – theoretically it could even only enforce the same checks it already has today using this tool.
  
  Coding standards is a bit of a tricky term in that sense, since there are aspects in there that deal with quality factors (e.g. escaping, sanitizing, caching DB queries) while others are just about preference (e.g. code style, Yoda conditions). The latter should definitely not be part of this.
  
  I hear you about effectively communicating code problems to users and developers. Realistically, only developers of the plugin tested could address their own plugin’s issues. A good approach could be to only ever add checks to the tool for which there is documentation on how to address it, and every check would need a documentation URLURL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org to point to in order to be accepted. This would set a foundation for addressing problems rather than just pointing them out.
  
  Definitely happy to chat about this further.
Jason Adams 10:52 pm on July 5, 2022

If this does great things like catch basic static analysis issues (e.g. invalid function signatures), WP deprecations, and assistance for things like escaping and sanitization, then I’m all for it.

If it attempts to enforce any kind of a coding standard such as the WPCSWPCS The collection of PHP_CodeSniffer rules (sniffs) used to format and validate PHP code developed for WordPress according to the WordPress Coding Standards.
May also be an acronym referring to the Accessibility, PHP, JavaScript, CSS, HTML, etc. coding standards as published in the WordPress Coding Standards Handbook., then it’s out to make enemies. Even the shops that I know which use the WPCS deviate even a bit (e.g. short array syntax).
- Felix Arntz 8:29 pm on July 12, 2022
  
  See my reply in https://make.wordpress.org/plugins/2022/07/05/proposal-for-a-wordpress-plugin-checker/#comment-44083, the plan here is definitely the first thing you said. Any code style enforcement is out of scope for this tool.
OllieJones 10:12 am on July 6, 2022

Great stuff!

Something to consider: drop-in modules like SQL Monitor and various persistent object cache plugins?

Will this inspect the code of drop-ins?

Will this work properly to inspect other code when drop-ins are active?
- Felix Arntz 8:33 pm on July 12, 2022
  
  Those are great questions.
  
  I haven’t thought about checking drop-ins yet. That’s probably out of scope since they work very differently, in addition there are only very few drop-ins available compared to plugins. Potentially a separate tool could be built for this that could reuse several similar checks.
  
  Regarding the behavior when drop-ins are active, the 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 checker tool should definitely still work. This will need to be considered for the eventual implementation.
Sajjad Hossain Sagor 12:28 pm on July 6, 2022

As A 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 Developer I 100% Support This! It Would Be Very Much Less Time Consuming & Productive To Build New Plugins Without Breaking Coding Standards!
- Felix Arntz 8:30 pm on July 12, 2022
  
  Note that this will be less about WordPress coding standardsWordPress Coding Standards The Accessibility, PHP, JavaScript, CSS, HTML, etc. coding standards as published in the WordPress Coding Standards Handbook.
  May also refer to The collection of PHP_CodeSniffer rules (sniffs) used to format and validate PHP code developed for WordPress according to the PHP coding standards., but rather about best practices. For example, enforcing the WordPress code style would not be part of this tool, since 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 developers should be free to use whichever code standard they prefer. Also see my reply in https://make.wordpress.org/plugins/2022/07/05/proposal-for-a-wordpress-plugin-checker/#comment-44083
rawrly 11:45 pm on July 6, 2022

This is a great idea.

I believe you will hit a hurdle with dynamic code analysis, and I think you’re aware of this when you mention the “almost unlimited feature set” of plugins and their “impossible to predict their expected behavior” nature. The earlier proposal document you linked mentions the solution indirectly: unit tests.

Having a tool in wp-admin (and 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/) that could run through a 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’s unit tests and provide the output could be useful for plugin developers. The developer should be able to choose their preferred unit test framework, and this pluign-checker-plugin could detect the framework, run the tests and show the output.

Utilizing existing unit testing for dynamic or server-side code analysis solves the almost unlimited features and behavior prediction problems. The developer would be responsible for writing the tests, knows the context well enough to write sufficient tests, and could be given the freedom to choose which unit testing framework they wish to use.

Developers choosing not to write unit tests could become the hurdle, but it may encourage developers who use this plugin to write unit tests for their plugins, and might be their first introduction to writing test driven code.
- Felix Arntz 8:40 pm on July 12, 2022
  
  I think the plan here is indeed to implement dynamic checks that to a degree would rely on infrastructure similar to unit tests – with the caveat that they, like most WordPress “unit” tests, are rather integration tests, and even at a higher level for a general 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 checker like this which cannot predict what the plugin to test does.
  
  Running a plugin’s unit tests could be potentially helpful, but the concern I see with that is that it would no longer be a centralized set of checks. Since every plugin would still be responsible for how many (or how little) unit tests it adds, it would merely be a tool to run unit tests, but wouldn’t be an indicator of quality for the plugin.
  
  I like your idea though, maybe there is room here to have certain checks which a plugin developer has to “support” or opt in to, which can then provide even more quality assurance for the developers and users of the plugin.
Courtney Robertson 3:39 am on July 13, 2022

Yesterday I was asked how this would differ from Tide. Could you elaborate for the wider community’s understanding?
- Felix Arntz 7:05 pm on August 31, 2022
  Apologies for the late reply to your question here, I hadn’t seen it before today.
  Tide is a centralized web service with the goal to run certain checks across the entire 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 repository and making this data publicly available.
  For the new plugin checker proposed here, we’re envisioning a decentralized approach (more similar to WordPress), i.e. the checker could be simply a plugin itself which you can use in different ways:
  - Site owners could activate it on their WordPress site to scan plugins they have installed or they consider installing.
  - Plugin developers could run the checks via the command line or automatically via CI as part of their development process (this isn’t really possible with Tide as it only operates on the plugin repository).
  A long-term goal would also be to integrate in some capacity with the plugin repository, however this would likely take an advisory role as well – e.g. it could be used to alert a plugin developer about potential issues privately via email, rather than calling out any such issues publicly.
  
  I’d say while the motivation for the Tide service and the plugin checker proposed here are somewhat similar, the vision and approach are notably different. We really want to focus on meeting plugin developers where they are, and educate and help them achieve better quality for their plugins, which in the long run helps site owners and WordPress sites out there.
Bethany Chobanian Lang 3:35 pm on July 22, 2022

+https://make.wordpress.org/performance/
vistawaplord 11:27 am on August 26, 2022

I already have a WordPress website of my own, and one day would like to make free plugins for the community. Any ideas or resources that can help me in the journey?

Comments are closed.

Communication

Goal and use cases

Project breakdown

Proposed approach

Next steps

Share this: