Tackling team challenges together

TLDR: New team reps selected; strategies for working through 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 backlog; solid show of interest in joining the team.

The last few months since Mika announced she was stepping down from the team have been very exciting (and busy!) for all the new team members (@davidperez, @eherman24, @frantorres, @lukecarbis, @martatorre and @pacomarchante), and we wanted to share an update with you. 

The first couple of weeks were a bit nerve-wracking. We were daunted by the complexity of the task, the responsibility it entails, and the sheer volume of plugins that needed to be reviewed. But over time, we’ve become more comfortable with the processes and routines of plugin review.  We are very grateful we got all the support we needed from Mika, @otto42, @dd32, @zoonini, @mrfoxtalbot, and other contributors during this period. 

We’re also pleased to announce that after some discussion, Francisco Torres & Paco Marchante will be the new team reps. 

The challenges

When you start working on plugin reviews it suddenly strikes you how tremendously efficient Mika was at doing this. In the last year alone, She reviewed 5297 new plugins (that’s around 100 plugins per week). You have to take into account that most of the plugins the team receives require a back-and-forth of several emails before the plugin can be approved.

Fortunately, the team is quickly picking up its pace at reviewing plugins. At first, it would take us 2 hours to review each plugin, then 1 hour, and now we are down to 10-20 minutes for an initial review. It is important to remember that reviewing plugins is not just looking at the code, we also need to check for other things such as trademark violations and other guidelines regarding compliance.

Aside from plugin reviews, the team takes care of several other tasks: we review reports of guideline violations, reply to requests about closing or reassigning ownership of plugins, respond to questions in the #pluginreview SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. channel, work with the security team to address vulnerabilities, and send out (and monitor) pre-release emails to ensure all plugin authors are still reachable at their regular email address. We have spent a lot of time documenting and streamlining these tasks.

Solving these challenges

The first challenge we found during our onboarding was the fact that a lot of processes were not clearly documented. We asked A LOT of questions during this process and ensured that all the answers Mika shared with us were added to the team’s internal docs. This effort should make it a lot easier for new contributors to join the team down the road.

We have also improved our internal tools to catch the most common coding mistakes and have built our predefined responses into the output provided by this tool. We still review this content manually before sending out replies, but by merging the two tasks into one (reviewing the code and drafting the message) we have been able to cut down review time considerably.

Another thing we decided to do was speed up our first reviews. As it turns out, about half of all plugin authors don’t reply to the initial review email with feedback on what they need to fix. In order to tackle the backlog faster, we’re now spending less time on initial reviews. We begin checking issues that take us less time, and then as soon as we spot one or two issues with the plugin that would prevent it from being approved, we email the plugin author to ask them to fix the initial issues. If the author gets back to us with those first fixes, then we proceed with an in-depth review.

20+ Submissions

When the team was announced, an application form was created for those considering joining the team. We are excited to announce that we have received more than 20 submissions from generous contributors wanting to help. We are currently reviewing them and our goal is to expand the team in the near future.


To recap, we are making our best effort to reduce the current backlog by improving our tools and expanding the team. Our goal is to lower the waiting period significantly over the next few months. We sincerely want to thank you all for your patience and understanding during this transition period. 

#update

Plugin Review Team Update: The next phase begins

tl;dr My time on 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 Review team is ending. Meet the new members, and check out the application to join the team.

The time has come. As outlined in several other posts over the last few months (March, May), I’m stepping down from the Plugin Review team. It’s been a fun and wild ride for the last decade as the rep, and before that as someone who annoyed Otto until he made me learn how to properly review.

After several months of onboarding, I’m excited to welcome six new and enthusiastic team members: David Pérez, Evan Herman, Francisco Torres, Luke Carbis, Marta Torre, and Paco Marchante. These sponsored volunteers – a group of experienced WordPress developers from around the globe – are contributing over 50 hours a week to the project. 

Plugin Review across the WordPress project is a big task. We know we hit a pretty rough backlog, and even as the new team members start to catch up and shorten the queue, more folks are needed to help. If you have at least five hours a week to devote to the team and would like to join in the Plugin Review effort, you’re welcome to submit an application

Given the nature of the work the team does, joining this team is a little different than some of the others: each new member will go through a vetting process by current team members before being selected. Some of the things the team is looking for are: a solid track record as a plugin developer; the ability to communicate clearly, kindly and constructively – both with other developers and users; interest in improving tools and processes; and excellent collaborative and conflict-management skills. 

If you think this describes you, check out the submission form.

Stay tuned for more team news soon, including the announcement of the new team repTeam Rep A Team Rep is a person who represents the Make WordPress team to the rest of the project, make sure issues are raised and addressed as needed, and coordinates cross-team efforts..

@zoonini contributed to this post.

#onboarding, #update

Advance Notice of Retirement

tl;dr: I will be stepping down from 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 reviews by 1 July, 2023.

I will be stepping down from plugin reviews this year. I have been a part of this team for over a decade (and the rep for the majority of the time) and recognize a departure like this can be confusing, and could cause people jump to a whole lot of assumptions about the why.

This is a personal decision and has nothing to do with my passion for WordPress. It is a 100% personal, non-WordPress related, decision I made long ago (I told the team in July ’22). Suffice to say there is life ‘stuff’ going on and I cannot devote the time I once could to plugin reviews.

Many people have noticed and complained, with varying degrees of empathy, about the sudden uptick in delays with reviews (be they new plugins or security related). Those delays are directly related to that ‘stuff’ going on. I simply am not available as much as I was, and out of fairness to myself and the community, it’s time for me to retire from plugins.

We’re trying to figure out an onboarding doc, some demo plugins to help people test, getting people in a place where they can fill in the gaps. But this is not a fast process. We’ve actually never had real onboarding (I was thrown into the fire when I stepped in), and it’s going to be a challenge get a team to the place where they have as much weird plugin knowledge and gotchas as I have from my 10 years of experience.

There will absolutely be a learning curve for the people who step in after me. Things will be missed, things will be confusing, and mistakes will happen. I ask everyone be kind and patient.

I understand it became a one-woman show and I apologize for not asking for help and stepping down sooner before it became a crisis. At that point, it was impossible to set up a flag for help without causing these kinds of delays. But things like this happen out of your control, even when you plan. None of us expected the world to spiral like it did in 2019/20.

What’s next for me and WordPress? Writing and managing my plugins, developing code, and being around for some questions. I won’t vanish in the night, but after a decade? I think it will be good for us all to have someone fresh in there.

Some quick answers:

  • I’m not sick or dying.
  • We don’t have an announcement of the new rep.
  • We are still working on onboarding and figuring that out.
  • We have reached out to people and they are actively being onboarded right now.

So again, I ask we all please be patient with all the changes coming. Once we sort out onboarding, we hope to be able to invite even more people, just like you, to the team!

#announcement, #team-reps

Reminder about Final Notices

tl;dr? If you get a final notice from 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 team, please take it seriously. That really is you reaching your final chance with us.

There has been some confusion about what a ‘final notice’ means with regards to plugins or what it means to be banned.

The Plugin Team does not capriciously ban anyone. Actually we hate banning people. It’s a lot of work, it’s frustrating, it comes with anger no matter how we do it, and people always get hurt, especially users. That’s why we’ve established a warning system and do our best to ensure all developers are aware of infractions and allowed to course-correct.

What is a final warning?

A final warning, like it sounds, is an email with a rather stern content telling you that you’re on your very last chance.

The plugin directory emails out final warnings to developers/companies/groups who have either demonstrated a repeatable, constant, habit of violating guidelines, or who have committed an incredibly egregious violation. Those emails contain a reminder (usually in the form of a list of all existing problems) and a notice that if the plugins team has to contact them for any reason other than security related, the developer/company will be banned and all plugins closed.

If you keep making the same mistakes, and you keep violating forum, plugin, theme, 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., or any other official guideline of 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/, we will cease to host your plugins here anymore. You would have repeatedly proven that you aren’t able (or willing) to follow the guidelines, and we feel it’s unfair to put the burden of monitoring you on the volunteers, as well as subject your users to that kind of behavior.

What happens after a final warning?

In general, people are quite responsive to those emails. They recognize the issue, modify their behavior, and it doesn’t come up ever again.

The warnings are a wake-up call as to the risks involved, as well as our expectations, and while they can scare people, it’s somewhat of a needed scare. By the time someone gets to that point, we have usually sent multiple warnings about various issues (be they fake reviews, asking for admin access, spamming users, or sharing developer accounts) prior to the final-notice, in the hopes that people will change their behavior before we have to get to the final notice.

Sadly, there are always people who don’t take those emails seriously, or think that if enough time has passed, the finality has faded and it’s okay to make the same mistakes and we will forget about it and forgive everything.

Why do people get banned after a final warning?

Given the size and scale of WordPress, it’s impractical to have to keep reminding people over and over that they actually do have to comply with the guidelines they agreed to, and it takes away time from frankly more important matters, like security.

Do people get warned first?

Most of the time, yes. The rare exception is if something is so terrible, we have to pull the plug right away. Usually that means someone snuck back in after being banned, or made a death threat.

But the majority of users get an email with the subject [WordPress.org Plugin Directory] Notice: (your plugin name) and that contains a warning of a specific behavior.

I got a warning about something. Is that a final warning?

Unless the email said “This is your final warning” then no.

We regularly warn people about issues, from trademark abuse to fake reviews. Those are just warnings. As long as they don’t repeat, we don’t have any issues. People make mistakes and it’s okay, as long as you learn from them and stop making them.

I’ve been mod-watched in the forums. Is that a warning?

No, not a plugin one. That just means the forum moderation are concerned about your actions and want to keep tabs on you. That could be anything from asking to admin access to swearing or jumping on other people’s topics all the times.

That said, if the forum team flags you like that, and you keep making the same mistakes, they may come to the plugin team for backup.

What kind of events cause a final warning?

Usually it’s not a single event, but a demonstrable pattern of violations. By that we mean the person(s) involved have broken many guidelines, over and over, for a sustained period of time.

Just for an example, let’s think about asking someone for admin access. That is prohibited in the forum guidelines for safety. Asking once is a mistake, and we know mistakes happens, so the person will get a warning from the forum mods. If they happen to ignore (or miss) the warning and do it again, their account gets put into a ‘moderated’ status, and all posts have to be approved by a moderator. That moderation flag is not a punishment. It’s there to make sure the mistakes stop, and to help protect the developer from harming themselves. After that, though, if it keeps happening, the plugin team is asked to step in and issue a warning.

But even so, our first warning is not a final notice! It’s a first warning.

From them on, if the person keeps violating the guideline, that is when that they will get that dreaded ‘final warning’ from plugins.

Why did I get a final warning without previous notifications?

That means you did something really bad, but not quite ban-worthy yet.

Sometimes it happens when someone gets a warning (like ‘don’t ask for admin access’) and replies “I cannot be held responsible for what my staff does.” That gets a final warning right away and a reminder that you absolutely will be held responsible for the people who represent you and your product. If you cannot trust your people, don’t let them represent you.

Other times, it’s a mistake so large, and so fraught with danger or concern, we feel that the only proper recourse is to jump directly to the final notice. Those are incredibly rare, and I’ll explain a little more about that later in this post.

How do I avoid a final warning?

Besides ‘never violate the guidelines,’ the easiest way would be to acknowledge and rectify any issue that a moderator or plugin rep brings up. If someone tells you not to ask for admin access? Stop asking for admin access. If they tell you not to call users vulgar names? Stop calling people names.

Basically listen to the warnings, take them all seriously, learn from them, and change your behavior as needed.

We know that everyone makes mistakes, and we will forgive a lot. But at the same time, that kind of forgiveness requires you to make changes. If you apologize and just do it again, we’re not going to be able to trust you, and that’s how you end up with a final warning.

I keep getting warnings because of my support staff, what do I do?

If that happens, it means you’ve somehow failed to impart on your support staff the reality that they have to follow the guidelines too. They are your responsibility, and if you cannot ensure they follow the guidelines, we simply won’t allow them to use the forums at all anymore, and you will be told why.

As for how to fix it? You need to address the issue on your end. Why are you staff not aware they have to follow the guidelines? Why are they not listening to the warnings issued? Why are they continuing to have this kind of problem?

Make sure everyone who represents you (in the forums, on social media, wherever) knows that their actions reflect on your whole company, and they have to follow the guidelines too. After all, if your intern violates Twitter’s guidelines using the company account, it’s your company account that gets suspended.

Other people are making the same mistake I am! Why aren’t they getting banned/warned?

They probably are, actually.

We respect everyone’s privacy and we don’t blast anyone on socials, so all conversations are in confidence as much as can be. After all, if you make mistakes and change your ways, you wouldn’t want the whole world knowing how much you messed up, right? It would be terrible embarrassing! Instead, we treat you like an adult, take you to the side, and talk to you privately.

Most people actually listen to the first warnings. If a forum mod tells them to please stop doing a thing, they apologize and stop. The plugins team never gets involved, and honestly that’s the best way.

I made similar mistakes. Why did I never get warned?

Luck? Or maybe we saw you made it once, and never again.

Mistakes happen. Most mistakes, as long as they aren’t repeated, are recoverable. Don’t panic if you made one mistake. As long as you keep learning, adjust as needed, and don’t do it again, you’re going to be fine.

Why did I get a second final notice?

Most of the time, that means we changed the guidelines since the first one, and felt it would be inhumane to not warn you about them. We will do this even if your violations are unrelated to the changes to the guidelines.

The other time would be if we think you really did change enough since the last notice, but you’re running down another wrong path. Basically? We think you are capable of change based on your historical behavior, and we want to give you another chance.

Why did I get banned without a final warning?

Normally we warn but yes, in some specific cases, we won’t. They include, but are not limited to:

  • physical altercatoions at official WordPress events
  • banned users attempting to circumvent their ban
  • intentional security violations (ex. making a backdoor in your plugin on purpose)
  • cyberstalking/harassing anyone from wordpress.org
  • doxxing anyone
  • all plugins/themes are non-credited forks or wholesale copies
  • outright vulgarity/hostility/threats towards any member of the community

In those cases, we will always email and tell you exactly why you were banned.

The people who get those insta-bans are often ones who got a plugin review and replied with vulgarities or suggestions of sexual activities involving a cactus. Not a joke. It was in response to being told to not include their own jQuery, to boot. We do get that people have bad days, and we try to help them get back from it, but that kind of abuse is untenable. If you’re willing to talk to us like that, we shudder to think how you’d behave to users!

What can I do after I got banned after a final warning?

Honestly? Not a whole lot. It’s incredibly hard to make anyone trust you after you reached that point.

If you got the final warning and kept violating guidelines, then you just squandered your last chance. The whole reason you got that warning, and not an instant ban, was that we were trying really hard to get you to correct your behavior. When you don’t listen to those warnings, we believe you are who you act like, and we ban you.

Now of course there are always exceptions. They are incredibly rare, and come with a lot of provisions and caveats. If you really think you should be given a second final-chance, reply to the email and explain why. Just be aware that the odds are against you, since you have already demonstrated you cannot (or will not) follow guidelines.

Why don’t you publicly declare why someone was banned?

Historically because we don’t want to keep hurting them.

Angry people lash out see, and while we’re ‘fine’ with taking it on the chin when people lash at us because we don’t explain the details about a ban (except in very rare cases), if we made things public that mob would go after the banned dev.

See, if everyone knew that a person or even a company was banned after we argued with them every few months for three years about not asking people for admin access on the forums, or not tracking users in their plugins, they would have a very different view of the developers.

If everyone knew a company was banned for telling the plugin team they could perform sexual acts on their parents (wish I was joking), then what? Making that public in a place where they cannot refute means they have no ability to make amends. And yes, sometimes people do come back and apologize sincerely for that behavior.

We don’t disclose because of a kindness, and a desire not to destroy someone’s reputation (or livelihood). Perhaps we’re now at the point where that policy needs to change, in order to minimize the false narratives running around, but I’m really divided about that one, personally.

Someone says they were banned. Should I stop using their plugins?

I can’t answer that for you.

Personally, I would take their explanations with a grain of salt. Everyone (and this includes the Plugin Team) tends to tell a story to paint themselves in a better light. If someone is arguing they did no wrong and were banned, they’re probably leaving some information out. Then again, there are developers who tell people they messed up and got banned and deserved it.

Questions?

I know this is a lot to think about, and some of it sounds incredibly petty.

No one on the plugin team wants to close plugins, especially the well-known ones. It’s harmful to the community as well as the developers. At the same time, there is a practical limit as to how much the volunteers on WordPress.org are willing to put up with someone’s misbehavior. That’s why we have taken to formally warning people that they are on their last chance.

It’s our fervent hope that with the information in the final warning, people will correct their behavior and stop violating guidelines.

#final-notice, #reminder

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

Journal Entry: Removal of the Zamir Plugin

Around 17:30 UTC on March 23, 2022, I was notified of 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 in the WordPress ecosystem that contributors flagged as potentially violating the plugin directory guidelines. The initial conversation can be found in Slack. Following my review as the Executive Director, the plugin was removed from the directory about an hour later. This post is to provide information about what happened and anticipated next steps.

tl;dr: The Zamir plugin used a loophole in the plugin guidelines created to protect members of the WordPress community. There are no present guidelines that bar the “support” of political leaning or cause, which is what this plugin’s description claimed it was doing. Since Z is emerging as a new symbol of hate and violence, it was considered a grey area in initial checks and on further review was removed.


Does this plugin violate WordPress guidelines?

Yes! Many community members shared how the Z symbol has come to stand as a symbol in support of Russia’s ongoing war in Ukraine. As a reminder, WordPress guidelines call upon all community members–including extenders like plugin authors– to “be kind, helpful, and respectful.” A symbol that is connected to an ongoing war and humanitarian crisis is none of those things.  

What actions were taken?

With the help of WordPress contributors and community members, the plugin has since been removed from the plugin directory. While decisions to remove plugins are normally adjudicated in a slower, more collaborative investigation process—quick and decisive action was appropriate to prevent further harm to the community.

Thank you to @santanainniss for pulling together the timeline of the morning and to @ipstenu for working to resolve the issue. Additional thanks to @cbringmann @helen @angelasjin and @eidolonnight for their review. And thank you to our community of contributors for voicing their concerns.

Trunk vs Tags? Which is Better? (Answer: Tags)

tl;dr – We strongly recommend you use tagged folders for your releases of your plugins. Future you will thank you.

While we have always advocated for people to use a tag folder with their plugins instead of trunk, it persists that a number of developers like using the “Stable TagTag Tag is one of the pre-defined taxonomies in WordPress. Users can add tags to their WordPress posts along with categories. However, while a category may cover a broad range of topics, tags are smaller in scope and focused to specific topics. Think of them as keywords used for topics discussed in a particular post.” of trunk. There are logical reasons for this. Having your stable tag be trunk feels like it’s one less thing to keep in mind when you update your 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 for a new release.

The problem with that setup is that you suddenly made it harder for everyone else to keep tabs on your plugin, to make sure they downloaded the correct version, and worst of all … you made it nearly impossible to roll back to a previous release. And with the advent of automated plugin updates, that last one is going to be damaging to you in the long run.

In fact, here’s what you’re making worse:

  • No easy way to download older versions to debug compatibility issues
  • Translators cannot work in ‘advance’ of a release, meaning as soon as you push your code, the translations are out of date until volunteers can work on it
  • You increase your risk of an accidental release
  • No way to allow people to download the ‘pre-release’ version from official 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/ sources
  • No ability to ‘roll back’ versions

So what’s the right way?

  1. Make sure your readme.txt has the stable tag to your stable version in the main plugin file (those need to match)
  2. Put everything into your trunk folder on your local checkout (use svn add and so on as needed)
  3. Run svn cp trunk tags/1.2.3 — this will copy from trunk to the tag folder
  4. Run svn ci -m "Releasing new version" — this will push both trunk and tag

That’s it. You’re done. Now you can upload and edit trunk all you want, for a dev version, and as long as the readme points to the proper stable tag, your users won’t get any updates.

Okay, but what if you want to have a trunk version for testing? Do not edit the stable tag in the trunk readme! It’s that value that tells WordPress which version is ‘stable’ and if you’re working on 1.2.3, keep stable as 1.2.2 in trunk and no one will get the new code until you’re ready.

#release, #svn, #tags

RESOLVED! Plugin Update Issues – 18 June 2020

As of 21:45 ET on 18 June, this SHOULD be resolved.

The original post remains below.


We are currently experiencing issues 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/ or can be cost-based plugin from a third-party updates properly displaying on the front end.

Systems is looking into this. We will have this resolved as soon as possible, however we do not have an ETA at this time. We ask for your patience and understanding.

12:31 ET – The issue has been identified, and the people to address it are being brought in. At this time, we ask you NOT attempt to push your code again. It won’t help.

12:46 ET – While we’re working on a permanent fix, we are attempting to manually clear the backlog. You may see some plugins updating, but this does not mean the issue is resolved.

13:10 ET – We’ve cleared out as much of the backlog as possible, however the issue has not been resolved. No new commits will go through. Again, please don’t try to push code. It’s still down.

15:15 ET – Some preemptive patches have been applied for when the fix is finalized, however updates are still not functioning properly.

17:10 ET – The situation is still ongoing. Our attempted fixes did not correct the issue.

19:20 ET – No ETA, fix is still being worked on. In the meantime, we’re devising a way to let us manually run the jobs without the need for system intervention, in order to ensure security fixes are pushed in a timely fashion.

21:45 ET – A commit has been made to properly trigger the cron job that does the magic. We believe the situation to be resolved.

Please thank @otto42, @ocean90, and @dd32 for their hard work!

#systems #downtime

The Proposed New Guidelines Must Be Revised

Following WCEU and in reviewing the number of changes people have brought up regarding the proposed new guidelines, I have determined that they will need some more work and a re-proposal in the coming months.

The main issues people have raised are:

  1. Limiting what kind of notices are permitted unbalances the state in a manner that would give an unfair advantage to larger plugins, or developer that have multiple plugins.
  2. Permanent dismissibility is really easy to work around by using content spinners or just changing the language slightly. That would be impossible to monitor and wouldn’t help users at all.

In addition there were a LOT of small language fixes involved in the process, which I feel should be re-reviewed from the top down.

In the coming months, I’ll be making a new pull request with a new attempt at this, taking all that advice into account.

Thank you everyone for your help on this! It’s not an easy process to craft guidelines that are equitable and understandable, and I hope we’ll have a better version soon.

Proposal to Modify Plugin Guidelines

This post is a proposal of changes to be made to 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 Guidelines.

The majority of changes are intended to address significant issues faced by ESL (English as a Second Language) developers. This proposal also contains a significant rewrite to the lamented 11th Guideline (hijacking the admin dashboard).

This proposal will remain open until after 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. EU 2019, at which point it will be closed and either re-proposed (if there are significant changes), implemented, or scrapped.

The rest of this post will go over an overview of intent, the proposed changes (with summary), and information as to how to contribute. All community members are welcome to participate.

Continue reading

#guidelines, #proposal