Welcome to the official blog for the PluginPluginA 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 Review Team.
The review team acts as gate-keepers and fresh eyes on newly submitted plugins, as well as reviewing any reported security or guideline violations.
We can be reached by email at plugins＠wordpress.orgWordPress.orgThe 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/, or via the #pluginreview channel on Slack.
It’s been a transformative year of growth in the WordPress Plugins Directory, particularly as the Plugins Team welcomed several new members onboard. Throughout this time, we remained focused on our primary goals: enhancing security, improving the review process, and fostering community engagement.
Our security efforts have focused on creating tools to benefit all developers, including the introduction of mandatory PluginPluginA 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 for new plugin submissions, 2FA in SVNSVNShort for "SubVersioN", it's the code management system used to maintain the plugins hosted on WordPress.org. It's similar to git. and our renovated Internal Scanner Tool. These features, detailed here, enhance security and streamline the submission process. Additionally, the SVN Password feature has become a critical measure to prevent account theft and related issues.
When it comes to reviews, it remains our most time-intensive task, reflecting our commitment to maintaining quality and trust within the Plugins directory.
Since September 2023, the plugin review queue—once around 1,300—has seen significant improvements thanks to enhanced tools, refined workflows, and better submissions. In October 2024, the queue even briefly hit zero. The Plugin Check plugin has been key, enabling developers to improve code quality and security pre-submission, which in turn has sped up reviews. Over the past year, 2,983 plugins have been approved, and the number of reviews required per plugin has increased. That means that we now detect more issues per plugin.
The Plugin Check plugin has significantly reduced the time for reviews, bringing the average wait time down from 37 weeks to 9 weeks, even as plugin submissions have almost doubled. In the past year, we’ve reviewed 7,382 plugins—59,1% more than the previous year—while detecting more issues through both automated and manual reviews than ever before. This has resulted in faster, more thorough reviews despite the increased volume of submissions.
We have continued refining our Internal Scanner tool, a magnificent legacy created by Mika Ipstein, to streamline reviews and boost productivity. Recent updates, encompassing over 400 commits, include new checks for issues like sanitize and escape, along with enhanced examples and personalized guides to help plugin authors effectively resolve identified issues.
The tool now features over 200 checks, detecting a wide range of potential security-related issues while also supporting reviewers in conducting thorough manual reviews.
The issues highlighted in the chart below account for approximately 80% of all issues detected.
For more reading about these and other common issues, you can click here.
With regard to improving the plugin development community, we have focused on migrating and maintaining the Developer Handbook to GitHubGitHubGitHub 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/ which can now accept contributions.
The team is also participating in the Plugins tables at various contributor days at WordCamps, helping and encouraging users to create their plugins whilst using WordPress best practices.
We will aim to do this type of review each year, and until the next one, please remember to use Plugin Check! Adding it to your development workflow will save you effort, and countless hours. As our roadmap outlines, we promise to increase its capacity, and usefulness.
PluginPluginA 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 headerHeaderThe 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.orgThe 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 UXUXUX 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 categoryCategoryThe '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 CoreCoreCore 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 GutenbergGutenbergThe 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 UIUIUI 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 CLICLICommand Line Interface. Terminal (Bash) in Mac, Command Prompt in Windows, or WP-CLI for WordPress. command
As a one click GitHubGitHubGitHub 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-SVNSVNShort 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.
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.
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.
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.
Introduce Experimental Checks: Add an experimental checks feature to let plugin authors betaBetaA 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.
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.
On September 17th, David Perez wrote a post on Make Plugins introducing Plugin Check (PCP), which also detailed how pluginPluginA 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 authors could get started using Plugin Check within their development process. The article also explained our new 1-Click GitHubGitHubGitHub 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, hosted in the GitHub Marketplace. If you have not already read his post, I would recommend reading it first.
Over the last year, the Plugins Team, in concert with other teams (MetaMetaMeta 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., Performance, and Systems among others), have been working on promoting best practices plugins hosted within the Plugin Directory, and improving its security of the Plugins Directory, while reducing the review queue for new plugins. Today, we’re excited to announce some changes to the process for submitting a new plugin into the WordPress.orgWordPress.orgThe 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 Directory which furthers these goals.
Firstly, as we announced on September 3, 2024, Two Factor Authentication (2FA) is now required on all plugin owner and committer accounts, as of today, October 1, 2024. This means that it must be enabled on a WordPress.org account that would like to submit a new plugin into the Plugin Directory. Instructions for enabling 2FA on your WordPress.org account can be found on that announcement post. We encourage all plugin owners and committers to turn on 2FA for their WordPress.org accounts if you have not already, as well as using the new SVN password feature. Please also audit your plugins for committers who may not need commit access anymore, and familiarize yourself with the Release Confirmation feature. You can learn about performing the last two steps in the post, Keeping Your Plugin Committer Accounts Secure.
Secondly, as of today, when you submit a new plugin to the Plugins Directory, it will first be run through Plugin Check’s Plugin Repo categoryCategoryThe 'category' taxonomy lets you group posts / content together that share a common bond. Categories are pre-defined and broad ranging.. If the new plugin has an error level item in this category, the submission will be blocked from being submitted for review, until it is fixed. The Plugin Team’s goal over the last year has been working on reducing the review queue length for new plugins. Alongside onboarding new team members and improving processes, adding Plugin Check to pre-check all new submissions now allows the team to reduce the initial queue by making it easy for plugin authors to identify and fix those issues most commonly seen in new plugins issues. The Plugin Repo category in Plugin Check catches recurring issues like mismatched versions between the plugin headerHeaderThe 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. and the readme.txt file, plugins using the wrong text domain, and using the wrong ‘Tested To’ values in the readme file. To be clear, the addition of Plugin Check as a pre-check will not replace manual review of all plugins, or change any of those processes, but instead it allows us to save time. By increasing the percentage of plugins submitted for review that require no changes, this reduces the number of changes needed overall.
An example of what this pre-check looks like is found below:
We’ve run Plugin Check behind-the-scenes on lots of plugins to refine it’s detection, but as with any new process, there may be some false positives. These will be fixed in the first few days, and we thank everyone in advance for their patience.
Over time, we will incorporate more checks into the plugin, for the pre-submission process, by adding additional checks for common Guideline Violations into the Plugin Repo category currently being used, and enabling the Security category as an additional requirement as well.
While this pre-submission check applies only to new plugins being submitted into the WordPress.org Directory, our goal is to continue to expand our use of Plugin Check on existing plugins as well. In the last several months, we have already required all plugins that were pulled from the Plugin Directory for a security vulnerability, to pass the Security category before it can be re-listed. This is, regardless of the connection of items it flags to the originally reported vulnerability. We have seen extremely positive results from doing this.
Lastly, we will be publishing a roadmap for the Plugin Check plugin, on how it will be run more broadly on existing plugins, in a future dedicated post. In the meantime, we recommend that developers integrate the use of Plugin Check into their active development workflows. You can also help us make Plugin Check even better by contributing to it on it’s GitHub Repo.
After the original proposal for a WordPress plugin check a little over two years ago, the Plugin Check plugin (or PCP for short) has become a reality. It saw its first stable release earlier this year and has since been used by hundreds of developers. This post provides more context about PluginPluginA 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 and why you should start using it.
Plugin Check is a tool for testing whether your plugin meets the required standards for the WordPress.orgWordPress.orgThe 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 directory. With this plugin you will be able to run most of the checks used for new submissions, and check if your plugin meets the requirements. The plugins team is currently working on making it an integral part of the review process. If you are considering submitting a new plugin to the plugin directory, run these checks yourself beforehand to save time later on.
But there is more! In addition to things relevant for the review process, the tool flags violations or concerns around plugin development best practices, from basic requirements like correct usage of internationalization functions to accessibilityAccessibilityAccessibility (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. It does so using both static checks using PHP_CodeSniffer and dynamic checks, where it actually activates your plugin to test it “live”.
Because of this, PCP is useful even beyond the initial plugin submission, which is why it’s recommended to make it a part of your development workflow. This shortens your feedback loopLoopThe Loop is PHP code used by WordPress to display posts. Using The Loop, WordPress processes each post to be displayed on the current page, and formats it according to how it matches specified criteria within The Loop tags. Any HTML or PHP code in the Loop will be processed on each post. https://codex.wordpress.org/The_Loop. as you can immediately address potential bugs as they come up, before they affect your users. To achieve this, simply install the plugin on a local environment and regularly run it against your plugin. The checks can be run either via WordPress admin or WP-CLIWP-CLIWP-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/.
For even more peace of mind you can continuously monitor your plugin using a dedicated GitHub action. It automatically runs Plugin Check against your plugin for every commit or PR, and posts all results as annotations on your source files so you know exactly where to look for resolving any errors or warnings.
Plugin Check is not a replacement for the manual review process, but it will help you speed up the process of getting your plugin approved for the WordPress.org plugin repository, and it will also help you avoid some common mistakes. Even if you do not intend to host your plugin in the WordPress.org directory, you are encouraged to use it so that your plugin follows the base requirements and best practices for WordPress plugins. Keep in mind that automated tools like this aren’t perfect, so there may occasionally be false positives.
All development for this plugin is handled via GitHub, and any bug reports or feature requests should be reported there. The GitHubGitHubGitHub 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 is maintained in its own repository.
TL;DR: Clarification on installing another pluginPluginA 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 from within a plugin, and community consultation on how to better inform and consent users in this regard.
There are plugins in the directory that ask to install other plugins. This can happen for various reasons, and there are different contexts and cases.
We would like to explore this with the community, analyze the cases where this happens, get feedback from different perspectives, and hopefully make an informed decision about what should and should not be allowed in certain cases. Please share your feedback before September 23rd 30rd. After this process, this post will be updated with specific details in those cases.
There are two specific cases we want to mention because they will be useful in analyzing the different casuistries:
Inform users and ask for permission: Users must be adequately informed of the actions they are taking and be able to decide whether they want to perform that action or not, otherwise that would be considered dishonest towards the users.
The guideline regarding executable code via third-party systems, mentions this specific case which won’t be allowed: “Serving updates or otherwise installing plugins, themes, or add-ons from servers other than WordPress.orgWordPress.orgThe 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/’s”. This simply means that a plugin will not be able to perform the installation of another plugin that is not in the directory. The way to install plugins that are not part of the directory will be a manual installation by the user.
Why install other plugins?
We have narrowed it down to two main reasons: Extended plugins and Recommendations.
Extended plugins
There are plugins that extend other plugins. Technically, they need the extended plugin to work.
A common example of this is a payment gateway integration for WooCommerce, which of course requires the WooCommerce plugin as it’s extending it.
In this case, the installation of that other plugin is a requirement, since the plugin won’t be able to work without it.
There are many different cases within this classification, here are some:
Cooperating plugins: There are plugins that can do more when used with other plugins; they are designed to integrate and work well together. They do not need the other plugin to work, but if they have it, they can integrate its functionality. An example of this is Contact Form 7, which integrates with Akismet to detect spam when available.
Plugin ecosystems: There are plugins that, even if they are not integrated and they do different things, they may be from the same author, same set of plugins, they offer the same experience to the user, and they just recommend the user to try these other plugins that are in this so-called ecosystem.
Other recommendations: Just nice and friendly recommendations of other plugins, in some cases also paid recommendations.
Pro / Premium versions of the plugin: Another version of the plugin or an add-on for the plugin that provides additional functionality.
In any case, after reading this list, you can probably forget about it completely, because while there are different reasons behind it, they all fall into the same categoryCategoryThe 'category' taxonomy lets you group posts / content together that share a common bond. Categories are pre-defined and broad ranging.: a plugin recommendation and their installation should be optional.
How are other plugins installed?
We have narrowed this down to the following 4 cases in essence.
Manually
The plugin informs the user that another plugin is recommended or required. Then the plugin must be manually installed by the user, either using the search plugins feature (if the plugin is in the directory), uploading a zip file, or uploading it to the /plugins/ directory.
Using the CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress.UXUXUX 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.
This also informs the user that another plugin is recommended or required, but instead of asking the user to manually install it, it uses the interface that the WordPress core already provides to install it.
In this case, the user seems to be well informed right out of the box. They can see the plugin’s name, description, version, etc. and the call to action is a clear button with the text “Install Now”.
Using a Custom UX
In this case, the install functionality is built into a custom interface that takes care of displaying information about the plugin being installed and asking the user for permission to install it. This is often embedded in an options page and in setup wizards or onboarding processes.
In this interface it’s important to get the user’s consent after providing them with sufficient information about what’s being installed.
No-asking
Automatically install plugins without informing the user and/or asking for their permission. This is expressly not allowed.
Let’s summarize
Ok, too much information: typologies, interfaces, guidelines. Let’s narrow this down.
Why install other plugins?
Extended plugins
Recommended plugins
As a requirement
✅
❌
Optionally
N/A
✅
How are other plugins installed?
Manually
Core UX
Custom UX
No-asking
Plugins in the directory
✅
✅
✅
❌
External plugins
✅
❌
❌
❌
What do we need your help for?
Now that we’ve clarified what is and isn’t allowed in terms of installing other plugins under the current guidelines, let’s take a closer look at a common case that we know is causing confusion for both plugin authors and users: information and consent regarding plugins that are installed using a Custom UX.
This is because while the general rule is “get the user’s consent after providing them with sufficient information about what’s being installed”, we recognize that this is on a case-by-case basis, and is somewhat subjective.
This team does not have specific details about what these interfaces should contain or how they should work, which leads to different criteria. We also realize that interfaces are complicated to regulate; it’s challenging to define specific details for them that are applicable in all cases, sufficiently clear, easily understandable and applicable and durable over time.
The number one goal we want to achieve with your help is to improve user information and consent, so that users have all the information they need to make a decision about installing a plugin, and a clear and easy way to give their consent. The lack of information or processes where the user was not aware of the action they were taking is an issue that users have reported to us and, after investigation, we believe needs to be addressed.
We have some suggestions on what plugin authors can do to achieve this goal (if applicable to their case). Please feel free to mix and match these suggestions and make your own, any feedback towards this goal is welcome. Note that there are suggestions that can be combined with each other.
Suggestion 1: Make clearer that it’s going to install a plugin
We have found cases where it is mentioned that a plugin will be installed, but it is done in a way that is not clear to the user, as it is mentioned in a smaller font, separated from the option, and/or using other techniques that in practice do not make it clear what the main action will be.
One suggestion would be to make the information about installing a plugin the most prominent information in the area where the user chooses to install it.
Before
After
Suggestion 2: Avoid pre-selected options
We have found cases where the option to install a plugin is pre-selected and the user has to explicitly uncheck it to avoid installation.
A suggestion would be to make that option not selected by default, so that the user has to take explicit action regarding that particular plugin in order to install it.
Before
After
Suggestion 3: Avoid multi-install, install one at a time instead
There are cases where several different plugins are installed at the same time during the process.
One suggestion would be to require plugins to be installed one at a time in a process that requires explicit user action to install them, by clicking a button that clearly states what it does.
Before
After
Suggestion 4: Provide additional information about the plugin
We see cases where the information about the plugin is pretty much limited to the name, there is other information that could be really useful for the user to make an informed decision about the plugin they are about to install.
One suggestion is to provide access to all information about the plugin, and perhaps the easiest way to do that would be to clearly link to the WordPress.org plugin page for that plugin.
Before
After
Suggestion 5: Use the Core UX to install the plugin.
The WordPress core includes an interface that can be used to install a plugin, and it meets most of the suggestions already mentioned: It’s clear, it’s not pre-selected, install them one by one and it gives all the information. Also, it would be a really clear definition of what’s allowed (the definition: only this).
The downside is that users lose the integrated interface and experience that a plugin could provide to perform those operations. There are some plugins that create really great onboarding forms, and users can lose a bit of that experience by having a modal window with a different aspect when asked to install another plugin.
The suggestion in this case would be to route any plugin installation process through this interface.
Before
After
Next steps
This post will be updated after getting your feedback and the team makes a decision.
After that, there will be a 3-month period during which plugin authors will be able to make the necessary changes to meet this common goal of improving user information and consent.
Please share your feedback in the comments. Thanks!
WordPress.orgWordPress.orgThe 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/ is committed to protecting accounts that play a crucial role in the WordPress ecosystem. Accounts with commit access can push updates and changes to plugins and themes used by millions of WordPress sites worldwide. Securing these accounts is essential to preventing unauthorized access and maintaining the security and trust of the WordPress.org community.
As part of this ongoing effort, we are introducing a new security requirement: mandatory two-factor authentication (2FA) for pluginPluginA 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 theme authors, starting on October 1st, 2024.
In addition to mandatory 2FA, we’re introducing SVNSVNShort for "SubVersioN", it's the code management system used to maintain the plugins hosted on WordPress.org. It's similar to git. passwords, replacing your user account password with an SVN-specific password for committing changes.
Please ensure you store your backup codes securely, if you lose access to your two-factor authentication method and your backup codes, the process to regain access to your account may not be easy.
Separating SVN Password from Your WordPress.org Account
We’ve introduced an SVN password feature to separate your commit access from your main WordPress.org account credentials. This password functions like an application or additional user account password. It protects your main password from exposure and allows you to easily revoke SVN access without having to change your WordPress.org credentials. Generate your SVN password in your WordPress.org profile.
If you’re using a deployment script, such as a GitHubGitHubGitHub 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, you’ll need to update your stored password with this SVN password as well.
Why not use 2FA with SVN?
Due to technical limitations, 2FA cannot be applied to our existing code repositories, that’s why we’ve chosen to secure WordPress.org code through a combination of account-level two-factor authentication, high-entropy SVN passwords, and other deployDeployLaunching code from a local development environment to the production web server, so that it's available to visitors.-time security features (such as Release Confirmations).
If you find any bugs, have feedback or need more support, please reach out in the #meta slack channel or follow up here (don’t share any private information though).
As a follow-up on the Andrew Wilder (NerdPress) and Chloe Chamberland (WordFence) reports that uncovered a limited number of compromised plugins, the PluginPluginA 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 Review team would like to provide more details about the case.
We identified that some plugin authors were reusing passwords exposed in data breaches elsewhere. The compromised accounts were not the result of an exploit on WordPress.orgWordPress.orgThe 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/. Instead, the attackers used recycled passwords to add malicious code to a few plugins on the WordPress.org Plugin Directory.
First, out of an abundance of caution, additional plugin releases have been paused, and all new plugin commits temporarily need approval by the team. This way, we have the opportunity to confirm that the attackers cannot add malicious code to more plugins.
Update: Plugin releases are no longer paused. The SVNSVNShort for "SubVersioN", it's the code management system used to maintain the plugins hosted on WordPress.org. It's similar to git. repository works as usual.
We have begun to force reset passwords for all plugin authors, as well as other users whose information was found by security researchers in data breaches. This will affect some users’ ability to interact with WordPress.org or perform commits until their password is reset.
Information about password deactivations
You will receive an email from the Plugin Directory when it is time for you to reset your password. There is no need to take action before you’re notified.
Your password was deactivated if you are a plugin author or committer. If you have an existing open session on WordPress.org, you will be logged out and need to reset your password.
To reset your password and regain access to your account, follow these steps:
On June 23 and 24, 2024, five WordPress.orgWordPress.orgThe 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/ user accounts were compromised by an attacker trying username and password combinations that had been previously compromised in data breaches on other websites. The attacker used access to these 5 accounts to issue malicious updates to 5 plugins those users had committer access to.
The affected plugins have had security updates issued by the Plugins Team to protect user security.
The Plugins Team would like to use this opportunity to spread awareness around best practices for WordPress.org accounts, particularly those with pluginPluginA 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 committer and owner level access.
As a reminder, Plugin Owners can set a WordPress.org user to have a special permission role for their plugin which include: – Owner: a plugin has one Owner which grants that user the ability to perform destructive actions such as to permanently close or transfer the plugin, as well as the ability to issue plugin updates and manage support for that plugin on WordPress.org. For company owned plugins, this should be a company branded WordPress.org account that only the company’s owner, CEO or CTO (or a single person in a similar role) has access to, which uses an email address only that individual has access to (ie not support@{companyname}.com) – Committer: this role grants the user the ability to manage support for that plugin on WordPress.org as well as the ability to issue new plugin versions by updating the plugin’s code in SVNSVNShort for "SubVersioN", it's the code management system used to maintain the plugins hosted on WordPress.org. It's similar to git.. – Support Rep: this role grants the user the ability to manage support for that plugin on WordPress.org only.
Limit the Number of and Audit Your Plugin’s Committers Regularly
As we’ve mentioned in the past, plugin commit access, which is the ability to issue updates on behalf of your plugin should only be given to developers, and more specifically, only the developers who are actively responsible for issuing plugin updates for your plugins.
Committer accounts should not be shared by more than one user, and should not use an email address that more than one person has access to. We’ve seen developers in the past use emails such as a support@ for their wp.org account with Committer or Owner access, which would mean anyone with access to your support tool can click on reset password, get the password, change it, and blow up your plugin (or permanently close it). Obviously that’s a major security issue (and could also be a Guidelines violation that gets your plugin pulled from the repository if it sends back an auto-responder email).
Additionally, the Plugins Team sends emails to all committers for a plugin if we ever need clarification on Guideline issues with your plugin or have a reported security vulnerability for your plugin. So the best practice is to limit the number of committer users you have on a plugin to the minimum number of developers possible, and have those developers ensure that emails from plugins@wordpress.org do not go to spam in their email client.
Users who do not need commit level access should instead be given Support Rep access, which allows them to respond to and manage support topics for your plugins on WordPress.org. This account level does not allow those users to issue plugin updates.
We recommend routinely auditing the committers for each of your WordPress plugins on a regular basis, removing commit access (or downgrading them to Support Rep access) when they don’t need active commit access. The owner of the plugin can manage the committers for the plugin on the Advanced tab of the plugin’s WordPress.org page.
Enable Release Confirmation For Your Plugins
In April, 2021, the Plugins Directory introduced opt-in support for Release Confirmations.
Release Confirmations, when opted-in for a WordPress.org plugin, allows for a second factor of security against the ability for an unauthorized user to issue plugin updates.
After opting in, a plugin committer wishing to issue a new version of the plugin would commit and tag the plugin update in SVN as normal. Once the tag has been pushed to the WordPress Plugins Directory, the Directory then emails a unique tokenized link to all plugin committers for that plugin which brings the committers to a special dashboard that allows them to confirm the new release. Only once the version is confirmed will the update then be issued.
You can see which that you have Committer (or Owner) access to have Release Confirmations enabled on the Release Confirmations dashboard.
Use Secure Passwords and 2FA
If you are the owner or a committer of a WordPress plugin, it is imperative you use a unique password that is complex and not re-used on any other website.
As mentioned in WordPress’s Password Best Practices guide, we recommend using a password that is: – is at least 20 characters (preferably substantially more) – uses lowercase and uppercase letters as well as numbers – contains special characters such as `!”#$%&'()*+,-./:;?@[]^_{}|~ – does not contain names, words or years that are easily linked to you
This password should not be used on any other site.
To make it easy to use secure, complex passwords, we recommend using a password manager to generate and store this password in. This helps avoid the temptation of password re-use and makes it easy to generate unique, complex passwords for each website that you use.
We also strongly recommend all accounts on WordPress.org setup and use two-factor authentication (2FA) which has been supported since May, 2023. This helps keep your WordPress.org account secure by requiring a second piece of evidence to login to your account such as a rotating 6 digit TOTP code using an authenticator app or a hardware key. To setup 2FA for your WordPress.org account, follow this step-by-step-guide.
