Title: Make WordPress Plugins – Page 4 – Resources for WordPress.org plugin developers

---

 [  ](https://profiles.wordpress.org/psykro/) [Jonathan Bossenger](https://profiles.wordpress.org/psykro/)
8:04 am _on_ July 30, 2024     
Tags: [make.wordpress.org/training ( 3 )](https://make.wordpress.org/plugins/tag/make-wordpress-org-training/),
[p2-xpost ( 88 )](https://make.wordpress.org/plugins/tag/p2-xpost/)   

# 󠀁[X-post: Call for contributors: Intermediate Plugin Developer learning pathway](https://make.wordpress.org/plugins/2024/07/30/xpost-call-for-contributors-intermediate-plugin-developer-learning-pathway/)󠁿

X-post from [+make.wordpress.org/training](https://make.wordpress.org/training/):
[Call for contributors: Intermediate Plugin Developer learning pathway](https://make.wordpress.org/training/2024/07/30/call-for-contributors-intermediate-plugin-developer-learning-pathway/)

 [  ](https://profiles.wordpress.org/frantorres/) [Francisco Torres](https://profiles.wordpress.org/frantorres/)
4:39 am _on_ June 29, 2024      

# 󠀁[Password Reset Required for Plugin Authors](https://make.wordpress.org/plugins/2024/06/29/password-reset-required-for-plugin-authors/)󠁿

As a follow-up on the Andrew Wilder (NerdPress) and Chloe Chamberland (WordFence)
reports that uncovered a limited number of compromised plugins, 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/](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.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/](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 SVNSVN Short 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:

 1. Go to [login.wordpress.org](https://login.wordpress.org)
 2. Click on the link “Lost password?”
 3. Enter your WordPress.org username
 4. Click the “Get new password” button
 5. Open your email and click the link to set a new password

Once you have reset your password, we encourage you to enable 2FA for your accounts
and [follow the recently outlined best practices](https://make.wordpress.org/plugins/2024/06/26/keeping-your-plugin-committer-accounts-secure/).
If you encounter any issues, please contact [forum-password-resets@wordpress.org](https://make.wordpress.org/plugins/page/4/forum-password-resets@wordpress.org?output_format=md).
We will never ask you for your password via email.

 [  ](https://profiles.wordpress.org/chriscct7/) [chriscct7](https://profiles.wordpress.org/chriscct7/)
5:33 pm _on_ June 26, 2024      

# 󠀁[Keeping Your Plugin Committer Accounts Secure](https://make.wordpress.org/plugins/2024/06/26/keeping-your-plugin-committer-accounts-secure/)󠁿

On June 23 and 24, 2024, five 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/](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 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/](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](https://developer.wordpress.org/plugins/wordpress-org/special-user-roles-capabilities/)
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 SVNSVN Short 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.You can also acknowledge users who contributed to the plugin without giving
that user any special abilities for the plugin on WordPress.org by [using your plugin’s readme.txt to mark them as a Contributor](https://developer.wordpress.org/plugins/wordpress-org/special-user-roles-capabilities/#committer).

## Limit the Number of and Audit Your Plugin’s Committers Regularly

As we’ve [mentioned in the past](https://make.wordpress.org/plugins/2015/11/23/your-plugin-committers-should-be-your-developers/),
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](https://make.wordpress.org/plugins/2015/11/23/your-plugin-committers-should-be-your-developers/)
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](https://developer.wordpress.org/plugins/wordpress-org/special-user-roles-capabilities/#committer:~:text=This%20is%20done%20from%20the%20Advanced%20Page%20on%20the%20sidebar%3A).

## Enable Release Confirmation For Your Plugins

In April, 2021, the Plugins Directory introduced opt-in support for [Release Confirmations](https://developer.wordpress.org/plugins/wordpress-org/release-confirmation-emails/).

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.

For additional security, the Plugin Directory also [supports the ability to require 2 plugin committers to confirm the release](https://developer.wordpress.org/plugins/wordpress-org/release-confirmation-emails/#:~:text=If%20a%20group%20would%20like%20to%20require%20multiple%20committers%20to%20approve%20a%20release%2C%20please%20contact%20the%20Plugins%20team%20with%20your%20request.)
in order to issue the update — if you’re interested in requiring that for your plugin,
please email plugins@wordpress.org with your request.

You can see which that you have Committer (or Owner) access to have Release Confirmations
enabled on the [Release Confirmations dashboard](https://wordpress.org/plugins/developers/releases/).

## 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](https://wordpress.org/documentation/article/password-best-practices/),
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](https://wordpress.org/documentation/article/password-best-practices/#keeping-track-of-your-passwords)
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](https://make.wordpress.org/meta/2023/09/26/set-up-two-factor-authentication-wordpress-org/).

 [  ](https://profiles.wordpress.org/sumitsingh/) [Sumit Singh](https://profiles.wordpress.org/sumitsingh/)
5:14 am _on_ June 5, 2024     
Tags: [make.wordpress.org/updates ( 15 )](https://make.wordpress.org/plugins/tag/make-wordpress-org-updates/),
[p2-xpost ( 88 )](https://make.wordpress.org/plugins/tag/p2-xpost/)   

# 󠀁[X-post: Training Team Update – June 2024](https://make.wordpress.org/plugins/2024/06/05/xpost-training-team-update-june-2024/)󠁿

X-comment from [+make.wordpress.org/updates](https://make.wordpress.org/updates/):
Comment on [Training Team Update – June 2024](https://make.wordpress.org/updates/2024/06/04/training-team-update-june-2024/#comment-6706)

 [  ](https://profiles.wordpress.org/felipevelzani/) [Felipe Velzani](https://profiles.wordpress.org/felipevelzani/)
1:08 am _on_ June 3, 2024      

# 󠀁[How should we shape the future of the Plugin Review team?](https://make.wordpress.org/plugins/2024/06/03/how-should-we-shape-the-future-of-the-plugin-review-team/)󠁿

The deadline has been extended from June 17 to July 2 due to several contributors
being occupied with WordCampWordCamp WordCamps are casual, locally-organized conferences
covering everything related to WordPress. They're one of the places where the WordPress
community comes together to teach one another what they’ve learned throughout the
year and share the joy. [Learn more](https://central.wordcamp.org/about/). Europe
and unable to provide feedback on this post within the initial deadline.

Since we began restructuring 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/](https://wordpress.org/plugins/)
or can be cost-based plugin from a third-party. Review team with our advisors and
new team members, we’ve had to make some tough collective decisions. These decisions,
while based on strong intuition from our contributions, could have more alignment
with the whole community.

This post aims to discuss and explore some important goals to improve our effectiveness
and efficiency. **This is a proposal, not a final set of goals.**

We hope to receive community feedback, which will help us reach a general understanding.
If possible, when commenting and adding suggestions around specific goals, please
also provide the reasons behind your suggestions.

Comments will be open for feedback until July 2, 2024. Thank you for your contribution
to the Plugin Review team!

### 1. Review timeframes

The plugin review process consists of two main queues (not including the security
queues). First, we have an initial review queue, during which we check the issues
and assign a specific reviewer to the plugin review. Then, if everything is good,
we will approve the plugin, or it will go to a subsequent review queue assigned 
to the initial reviewer to continue the conversation until it reaches a satisfactory
level.

We need to have different timeline goals for each of these steps.

 * **For the initial reply to plugin submissions, it would likely make sense to 
   happen within seven days.** This timeframe can be considered at three levels:
   the regular level would be up to 7 days, the warning level would be between 7
   and 14 days, and the critical level for more than 14 days. The idea behind the
   regular level being up to one week is that some team members contribute more 
   during weekends, and we need to allow enough time for this to compensate for 
   the increase in submissions during the week.
 * **If the plugin is not initially approved, we propose that the assigned team 
   member have a follow-up reply within 10 days as a goal on the subsequent review
   queue.** We need to consider that some team members are distributing their pledged
   time over one day per week, so it might not be viable to lower this number as
   we try to keep the same reviewer handling the entire review process for a specific
   plugin.

If we can’t meet the expected timeframes, we must implement contingency plans. When
we reach the warning level, we will ask team members who are involved in other team
projects to reprioritize and focus on reviews as much as possible. If the situation
worsens and we reach a critical level, we propose to create urgent calls to add 
new team members and explore even deeper actions to reverse this as soon as possible.
We would love suggestions on other contingency plans.

**Suggested monthly goal: 95% of initial reviews completed within 7 days and 90%
of subsequent reviews completed within 10 days.**

### 2. Improving initial submission quality

The team’s work is primarily focused on providing a safe and reliable experience
while following some basic standards and guidelines. 

One of the team goals is to make [Plugin Check (also known as PCP)](https://wordpress.org/plugins/plugin-check/)
a big part of the submission process, and we expect this to improve the quality (
and speed) of the whole process. Having more AI-based tools also has some potential,
even if we don’t yet know exactly how, but we’re open to suggestions.

Apart from that, we would like to improve our interactions with plugin authors by
consolidating information and providing practical tips through small videos (like
Instagram/TikTok) on common issues such as sanitizing and escaping.

This means that part of our goal is to invest in this direction and ask some of 
our contributors to dedicate time to it.

Right now, it takes an average of about three interactions per review when looking
at the last six months, so it would be ideal to change that closer to two interactions
per review.

**Suggested monthly goal: Improve the quality of applications so that there are 
only two interactions (one initial review and one subsequent follow-up review) as
average per application.**

### 3. Keeping track of popular plugins

The team has historically only reviewed the initial version of plugins by default,
then only checked based on specific reports or specific cases.

This means some plugins with many active installations haven’t had a full review
from our team in a really long time. 

The team would like to start dedicating resources to scheduled reviews whenever 
a plugin achieves 20k active installations. Of course, this is more challenging 
while there is still a backlog, but it is one of the plans we consider throughout
a plugin’s journey on the WP.org directory.

**Suggested monthly goal: Complete scheduled additional reviews for all of the plugins
with over 20k active installations at least once every two years.**

### 4. Distribution of contribution

Ideally, no single person should be responsible for the majority of active reviews.
We need to avoid overloading a few individuals and relying on only a few people 
to keep the work going. 

A health number might be not more than 25% of reviews, as this distribution ensures
consistency and protects us if someone steps out temporarily or permanently.
This
means we will explore internally (and even add new team members if needed) until
we accomplish this goal.

**Suggested monthly goal: Ensure no team member handles more than 25% of active 
reviews at any time.**

 [  ](https://profiles.wordpress.org/courane01/) [Courtney Robertson](https://profiles.wordpress.org/courane01/)
1:18 pm _on_ May 14, 2024     
Tags: make.wordpress.org/sustainability, [p2-xpost ( 88 )](https://make.wordpress.org/plugins/tag/p2-xpost/)

# 󠀁[X-post: Recognizing Contributions and Acknowledging Challenges](https://make.wordpress.org/plugins/2024/05/14/xpost-recognizing-contributions-and-acknowledging-challenges/)󠁿

X-comment from [+make.wordpress.org/sustainability](https://make.wordpress.org/sustainability/):
Comment on [Recognizing Contributions and Acknowledging Challenges](https://make.wordpress.org/sustainability/2024/05/10/recognizing-contributions-and-acknowledging-challenges/#comment-141)

 [  ](https://profiles.wordpress.org/ndiego/) [Nick Diego](https://profiles.wordpress.org/ndiego/)
4:02 am _on_ April 30, 2024     
Tags: [make.wordpress.org/meta ( 13 )](https://make.wordpress.org/plugins/tag/make-wordpress-orgmeta/),
[p2-xpost ( 88 )](https://make.wordpress.org/plugins/tag/p2-xpost/)   

# 󠀁[X-post: The Plugin Directory gets a refresh](https://make.wordpress.org/plugins/2024/04/30/xpost-the-plugin-directory-gets-a-refresh/)󠁿

X-post from [+make.wordpress.org/meta](https://make.wordpress.org/meta/): [The Plugin Directory gets a refresh](https://make.wordpress.org/meta/2024/04/30/the-plugin-directory-gets-a-refresh/)

 [  ](https://profiles.wordpress.org/frantorres/) [Francisco Torres](https://profiles.wordpress.org/frantorres/)
7:07 pm _on_ March 5, 2024      

# 󠀁[WordCamp Asia 2024: Plugin’s team table on contributor day](https://make.wordpress.org/plugins/2024/03/05/wordcamp-asia-2024-plugins-team-table-on-contributor-day/)󠁿

With [WordCamp Asia 2024](https://asia.wordcamp.org/2024/) coming soon, we need 
to get ready for contributor dayContributor Day Contributor Days are standalone 
days, frequently held before or after WordCamps but they can also happen at any 
time. They are events where people get together to work on various areas of [https://make.wordpress.org/](https://make.wordpress.org/)
There are many teams that people can participate in, each with a different focus.
[https://make.wordpress.org/support/handbook/getting-started/getting-started-at-a-contributor-day/](https://make.wordpress.org/support/handbook/getting-started/getting-started-at-a-contributor-day/)!

To ensure a smooth experience on the day, we recommend installing a local development
environment on your laptop in advance. The conference venue’s Wi-Fi may not always
be optimal, especially when many people are using it simultaneously. Achieving this
prerequisite over a stable and fast connection is much simpler.
Here’s the checklist:

 1. Latest Local WordPress Setup: You can use tools like MAMP, XAMPP, Local by Flywheel,
    Docker, or WP-Now.
 2. Latest Stable Version of Node.js and npm: You can find it here: [Node.js](https://nodejs.org/en)(
    LTS version is the one used by coreCore Core is the set of software required to
    run WordPress. The Core Development Team builds WordPress. and GutenbergGutenberg
    The Gutenberg project is the new Editor Interface for WordPress. The editor improves
    the process and experience of creating new content, making writing rich content
    much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML
    etc. [https://wordpress.org/gutenberg/](https://wordpress.org/gutenberg/)).
 3. Code Editor: Consider using VSCode or Sublime.4. GitGit Git is a free and open 
    source distributed version control system designed to handle everything from small
    to very large projects with speed and efficiency. Git is easy to learn and has 
    a tiny footprint with lightning fast performance. Most modern plugin and theme 
    development is being done with this version control system. [https://git-scm.com/](https://git-scm.com/):
    its optional but good to have

We eagerly anticipate your presence at the event!

_Thanks to [@kafleg](https://profiles.wordpress.org/kafleg/) for your help drafting
this post_.

 [  ](https://profiles.wordpress.org/sterndata/) [Steven Stern (sterndata)](https://profiles.wordpress.org/sterndata/)
10:34 pm _on_ February 8, 2024     
Tags: [make.wordpress.org/support ( 5 )](https://make.wordpress.org/plugins/tag/make-wordpress-org-support/),
[p2-xpost ( 88 )](https://make.wordpress.org/plugins/tag/p2-xpost/)   

# 󠀁[X-post: Guideline change: Reviews of Commercial/Pro Plugins](https://make.wordpress.org/plugins/2024/02/08/xpost-guideline-change-reviews-of-commercial-pro-plugins/)󠁿

X-comment from [+make.wordpress.org/support](https://make.wordpress.org/support/):
Comment on [Guideline change: Reviews of Commercial/Pro Plugins](https://make.wordpress.org/support/2024/02/guideline-change-reviews-of-commercial-pro-plugins/#comment-173496)

 [  ](https://profiles.wordpress.org/jordesign/) [jordesign](https://profiles.wordpress.org/jordesign/)
2:42 pm _on_ February 4, 2024     
Tags: [make.wordpress.org/support ( 5 )](https://make.wordpress.org/plugins/tag/make-wordpress-org-support/),
[p2-xpost ( 88 )](https://make.wordpress.org/plugins/tag/p2-xpost/)   

# 󠀁[X-post: Suggestion for a change in the guidelines:](https://make.wordpress.org/plugins/2024/02/04/xpost-suggestion-for-a-change-in-the-guidelines/)󠁿

X-comment from [+make.wordpress.org/support](https://make.wordpress.org/support/):
Comment on [Suggestion for a change in the guidelines:](https://make.wordpress.org/support/2024/02/suggestion-for-a-change-in-the-guidelines/#comment-173490)

## Post navigation

[← Older posts](https://make.wordpress.org/plugins/page/5/?output_format=md)

[Newer posts →](https://make.wordpress.org/plugins/page/3/?output_format=md)