Welcome to the official blog for the Plugins Team.
The team acts as gate-keepers and fresh eyes on newly submitted plugins, as well as reviewing any reported security or guideline violations.
Quick Links
The team acts as gate-keepers and fresh eyes on newly submitted plugins, as well as reviewing any reported security or guideline violations.
Quick Links
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Normally we warn but yes, in some specific cases, we won’t. They include, but are not limited to:
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!
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.
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.
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.
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.
tl;dr: If you put a website as the official developer or 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. URLURL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org and it does not exist (or is under construction), your review will be pended.
We know that sounds really weird, but yes, we’re saying if you tell us that your domain is XYZ and that domain doesn’t exist, or isn’t public, your review is going to be paused until you finish the site.
The primary reason for that is because those URLs will be seen by all your users, and if a user sees a great looking plugin with an incomplete website, they will not trust you. That’s actually something that scammers do on the regular, and you’ve made yourself look like that.
So to protect you from an undeserved bad-rep, we check your domains.
The secondary reason is, if you’re a service, we really do need that live so we can review the website and ensure it and the plugin are compatible with our guidelines.
Most of the time, yes.
However if you’re a service and the service runs through that website, then not only will you be required to make the site public, but you will also need to include a terms of use and/or privacy page on your site.
Reply to the email with “Ooops, I typoed, the real URL is …” We’ll ask you to update the code and your account, so your users don’t get confused, and all will be well.
Then you used the wrong account to submit the plugin. Remember ALL official plugins have to be owned by the official company. If you were hired to make a plugin for BoogieDownBlues (a fake company) and the domain is boogiedownblues.com then the account that submits the plugin has to use that domain for their email.
That protects you and them from any legal action later on.
No. Again, we’re trying to protect you from being seen as an untrustworthy developer. Also we want to make sure your site isn’t violating rules.
This generally happens with service plugins, and if that’s the case, we will tell you no. The site has to exist so we can validate the service.
You do not, but we do recommend it. People prefer to know there are real humans behind things.
Maybe. It depends on what you put on the placeholder page and (again) if you’re a service. If the placeholder says ‘Coming soon!’ then no.
If your domain is filled with placeholder, we consider it to be incomplete and will point out the problem. Same goes for clearly fake addresses and those about pages that all have the same face.
Because you told us (and by extension all your users) “this is who I am!” If your personal site is ‘coming soon’ or has a placeholder, no one can make a judgement on you save to say you’re a dev who can’t make a website. And yes, that is patently unfair, we know, but that’s what people will think. Heck, they complain to us every time we miss it. We would rather you not start in a bad place.
Because using a trademark in the domain name violates trademark law.
Using a company’s trademark in a URL as a domain name in whole (or in part like wordpress-example.com) may constitute a violation of the company’s trademark rights. See Brookfield Communications, Inc. v. West Coast Entertainment Corp., 174 F.3d 1036 (9th Cir. 1999).
What you can do instead is have example.com/trademark/ — that is generally allowed.
Keep in mind, some organizations (like WordPress) will allow the ‘short’ versions so wpexample.com would be fine. Others (like WooCommerce) have more restrictions, and actually prohibit wooexample.com
Always check the trademark guidelines first!
#reminderX-comment from +make.wordpress.org/updates: Comment on WordCamp US Contributor Day 2022 Recap
tl;dr: Heroku’s free plan is going away. Please update your services and make sure all your 3rd party libraries are up to date.
From their recent post:
Starting October 26, 2022, we will begin deleting inactive accounts and associated storage for accounts that have been inactive for over a year. Starting November 28, 2022, we plan to stop offering free product plans and plan to start shutting down free dynos and data services. We will be sending out a series of email communications to affected users.
Roughly 300 plugins use heroku services, many for free. If you are one of those free users, please make sure you make arrangements to either pay for the plan or replace your service. As of December 2022, if people report 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. breaks because of that shut-down, we will close your plugin until it’s corrected.
There’s always the probability you’re not going to want to (or be able to) migrate services. That’s okay too. If you want to close your plugin, you can do that yourself! I would recommend pushing a final version that warns people on day X this will stop working, if that’s your choice.
The one thing that’s really going to trip people up are those libraries though. A lot of 3rd party libraries make use of Heroku, and not all are going to update.
We’re going to do a sweep and let as many people know as we can, but we wanted this to be public since a lot of people miss emails and also if your plugin isn’t impacted but one you coordinate with is, well… you should know too 🙂
Many WordPress plugins use the setlocale() function.
While it’s generally safe to use setlocale() to get various information about a specific locale, it’s essential to understand that using setlocale() to perform string manipulations has significant disadvantages.
The goal of this article is to raise awareness about those disadvantages.
So, what are they?
setlocale() is not thread-safe. If you run WordPress on shared hosting, you may experience sudden changes in locale settings, as though 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. never called setlocale().setlocale() to detect the current locale don’t process some characters correctly, even if the correct locale is set with setlocale().Take a look at this 3vl4.org example.
The expected output of the script is Ž, but the actual output is Ů.
These are some recommendations on using setlocale() that could make using it safer:
setlocale() to process strings in different encodings unless absolutely unavoidable.setlocale() with LC_ALL. Instead, specify the exact categoryCategory The 'category' taxonomy lets you group posts / content together that share a common bond. Categories are pre-defined and broad ranging. of functions you need (e.g., LC_MONETARY, LC_NUMERIC).C should be used as the default locale setting.X-comment from +make.wordpress.org/community: Comment on Contributor Teams: Submit WCUS 2022 Table Leads Signup Form by July 29
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).
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:
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:
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.
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.
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.
X-comment from +make.wordpress.org/core: Comment on Rollback Feature: Testing Call to Action
tl;dr Google, who already blocked anyone from emailing a zip with certain JS files inside (compressed/combined files), has moved to blocking them as ‘viruses’ entirely.
This week a new hassle popped up with anyone who uses Google Drive.
If you’re not the owner of a file, you may have seen a warning like this:

Or maybe this when trying to download:

In both cases, it’s Google being weird and sadly it’s not something we can fix.
What this means is that you will want to transition away from using Google Drive to distribute your zips, for 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 but also for regular sharing of a zip that has javascriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com. They used to only do this for Gmail, so it’s somewhat understandable they’d expand this to Drive. Sadly they’re a little shortsighted on implementation and while they may get around to fixing this, they may decide not to care about it and keep blocking.
There are other services like Dropbox or Wetransfer, but also please remember you can always use code repositories like Gitlab or GithubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged by the repository owner. https://github.com/ (both of which will build zips for you, so you shouldn’t upload the zip itself to the repos).
We’re sorry about Google getting weird like this.
ETA: Guess what else uses Google to manage attachments? HelpScoutHelp Scout A 3rd party service we use to process emails for plugin reviews.. I have a ticket in to ask to disable that, because hiiiiii. But right now, we’re having a banner day.
#download, #google-drive, #virus