2019 Insights

There’s been a lot of quiet change going on for Plugins, so now is as good a time as any to get into it!

If you’re interested in any details missing, leave a comment. I do ask you try not to speculate too much into the why’s and wherefores of what people do with plugins. I’ve been at this a while, and the one thing I can promise is people do weird things.

New Email System

We finally migrated off of the old system and on to HelpScout in March, which allows us the ability to sort and organize emails into teams. It also lets us properly filter bad actors so not everyone has to deal with them. We make heavy use of automated filters now, which has let us do the impossible …

New Team Members

We onboarded two new team members in November and have been easing them in to the weird workload of Plugins. They’ve been instrumental in sorting out what filters and team assignments do and don’t work well for Plugins.

New Tools

I’ve been using a new bash script to expedite scanning plugins. While we’d love to use WPCS (and I personally recommend it to for everyone), even with a heavily parred down version it hasn’t quite met our needs. The goal for next year is to move the bash script into a PHP plugin we can use to automate a lot more.

New Replies

Our saved replies (the standard ones you get for closures and reviews) have all been cleaned up, spellchecked, and formatted for easier reading. Now, when you get an alert that your plugin has been closed, we attempt to direct you on exactly how to resolve the issues. This is still a bit of a work in progress, but we’ve made great strides on consistent tone and softer language.

New Restrictions

Sadly as many people found out, we got dinged hard by some trademark owners, and are taking action against people who violate trademarks. Around 1000 plugins were closed due to that, and it’s one of those things we can’t protect you from. We’ve changed the plugin uploader for new submissions to block a lot of that.

Remember the basic rule: If it’s not your company/product/library, don’t begin your plugin Display Name or permalink with it!

(Trademark owners: Please ask the developer to changes things before coming to us. Communication will help everyone.)

The Stats!

A lot of people like this part. Here’s the overall outlook from 2019:

Chart showing the Requested, Rejected, Closed, Approved, and Pending plugins each week for 2019.

And in a slightly more consumable summary table:

Requested Rejected Closed Approved Pending
Most in a week 194 109 480 118 718
Least in a week 129 2 9 25 527
Average 161 25 117 76 623
Year to Date 8048 1221 6038 3836 N/A

We’ve had 1000 more plugins submitted in 2019 than 2018, however the Rejected and Approved numbers only went up by 100.

So where are the extra 800 plugins? On average, pending plugins did go down but only by about 25 a week. Most of the missing counts are there, but they’re also in the dreaded “Closed” section.

A higher than expected number of developers have submitted plugins for review and then asked them to be closed within a 6 month timeframe. This has led to us pushing back on people and making notes in their accounts about that kind of behavior. There hasn’t yet been a common thread to why that’s happening, so we’re keeping an eye out.

HelpScout Overall

HelpScout also helpfully provides their own statistics for how much we used them. This is just since March when we switched over:

  • Customers: 6665
  • Conversations per Day: 35
  • Busiest Day: Thursday
  • Email Conversations: 12,829
  • Messages Received: 17,439
  • Replies Sent: 18,931
  • Emails Created: 6650
  • Resolved: 6642
  • Resolved on First Reply: 31%
  • Closed: 11,818

HelpScout Saved Replies

We make heavy use of Saved Replies to speed up reviews and processing. These were brought in to use in chunks, and I’m omitting the exact numbers. They won’t do you any good to know we sent 2,679 “Approval after send” emails when you realize we also only sent 628 “Intro to new Review”. All that means is we pulled in the Approval email first. Next year these stats will be more useful.

All that said, I think having a look at what the most common sorts of issues are might be a little enlightening. Everything is ordered from most use to least.

Closed and Warned

These emails are sent out when a plugin is closed or the developer needs to be warned about issues/behavior.

  • Closed: Trademark Abuse (All)
  • Closed: Removal Request Completed
  • Closed: Security Exploit
  • Warning: Sockpuppets
  • Warning: Trademark Violation
  • Notice: Closed Becuase Email Bounced
  • Warning: Security Issue (NOT CLOSED)
  • Closed: General Guideline Violation

Reviews

All these emails are sent when a plugin is being reviewed.

  • Approval: Approval after send
  • Review: End Of Review (goes at the end of all reviews)
  • Review: Intro to new review (all new reviews start here)
  • Review: Please sanitize, escape, and validate your POST calls
  • Review: Generic function/class/define names
  • Review: Incomplete Readme
  • Review: Including your own CURL code
  • Review: Not using wp_enqueue commands
  • Review: Calling remote files (js, css, images, etc)
  • Review: Including Libraries Already In WP Core (i.e. jquery)
  • Review: Calling file locations poorly (also hardcoding in paths)
  • Review: Including out of date libraries
  • Review: Undocumented use of a 3rd Party or external service
  • Review: Not using Nonces and/or checking permissions
  • Review: Using file_get_contents on remote files
  • Review: Calling core loading files directly (wp-config, wp-load, wp-blog- etc etc)
  • Review: Display Name infringes on trademarks (slug is fine)
  • Review: Using esc_ to sanitize (not esc_url)

Pended

A pended plugin is one we stop before even reviewing the code. This usually happens because someone’s infringing on trademarks, or using a personal account to submit a company owned plugin.

  • Pended: Name Infringes on Trademarks (slug and name need to be changed)
  • Pended: Never replied to previous review (was rejected)
  • Pended: Not Official Owner

Rejected

This should give you an idea of why plugins are rejected. Top of the list? People who don’t reply.

  • Rejected: Review never completed within 6 months
  • Rejected: Not Your Plugin (Tried to upload vs host)
  • Rejected: Generic for plugins we’re just not hosting
  • Rejected: Framework or Library Plugins
  • Rejected: New/renamed version of their own plugin

Miscellanous

The rest of the emails are lumped together. You’ll notice we have prefixes to what each email is. That helps us find them faster.

  • Notice: Plugin Restored
  • Reply: Plugin Slug Renamed
  • Reply: Rescan (Plugins must be checked before being reopened)
  • Thank You: Security Report
  • Thank You: Guideline Report
  • Reply: Don’t call people ‘sir’
  • Thank You: Generic, Will Review
  • Notice: AutoReply Sucks
  • Notice: Already Mailed Review
  • Approved: Resend Approval
  • Question: Why Close?
  • Reply: Cannot Rename Plugins (for people who email RIGHT after approval)

#statistics, #year-in-review

Trademark Enforcement

Many of you have received an email from us regarding plugin closures for trademark violations. These emails were absolutely not made in error.

Due to recent demands by trademark owners, we will now be more strictly enforcing trademark abuse when it comes to plugins. While it should be sufficient to tell you “Don’t abuse someone’s trademarks.” the reality is that those things are complex and confusing.

We will have altered our system to prevent the submission of those plugins that violate trademarks. This is not something we do lightly, however we have been compelled to close a great many plugins recently. It’s more efficient to prevent potential abuse than to clean it up after the fact.

How Trademarks Apply

Trademarks apply to the following aspects of your plugin:

  • The Slug – Your plugin slug may not begin with someone else’s trademarked (or commonly recognized) term
  • The URL – You may not use someone’s trademark in your domain name
  • The Display Name – You may not begin the display name with someone else’s trademarked (or commonly recognized) term and, in many cases, you may not use the name AT ALL.
  • All Images – You may not use trademarked logos/images in your banner, screenshots, logos, etc

We do our best to take care of the first one – the slug – when you submit your plugin. Plugins approved pre 2015 with trademarks in the URL are ‘grandfathered’ in and permitted to remain. All plugins approved after 2015 are required to meet this restriction. All plugins, no matter when they were approved, must comply with trademark usage in display names and images.

We also keep our eye on similar names. There’s a concept known as brand confusion, so naming your company or plugin similar to another company (like Facerange, say) you can still be legally compelled to change the name. This is why, for example, you cannot use ‘pagespeed’ in your URL for a site optimization tool, even though Google’s only trademark is on ‘page speed’ (two words). The name is similar enough that we have been required to close plugins.

Additional Restrictions

In addition to the above, many brands have an above-and-beyond requirement. You must also avoid representing the brand in a way that:

  • Makes the brand the most distinctive or prominent feature
  • Implies partnership, sponsorship or endorsement
  • Puts the brand in a negative context as part of a script or storyline

Also many have statements like this when regarding applications specifically:

  • Don’t modify, abbreviate or translate the brand name to a different language or by using non-English characters, or use any logos to replace it.
  • Don’t combine shortened versions of the brand with your own brand.
  • Don’t use our ‘wordmark’

This is where it all gets crazy weird. But an example would be the brand Facerange. With the above restrictions, naming your plugin (which is an application) “WordRange” or “FacePress” and having it be a plugin to work with Facerange would be a violation of their terms.

It all comes back to making it painfully clear that you and your work have NO relationship to their products. Some allow you to use their product name wherever you want, and some won’t permit it at all. When in doubt, the best course of action is to assume you don’t have permission and not to use it.

Quick FAQ

Can I use ‘for BRAND’ in my plugin display name?

Sometimes. It depends on the brand. We don’t have a complete list, which makes this very complex. It’s important to pay attention to the rules for brand usage and application uses. Some brands have separate rules. In general, if they’ve trademarked their wordmark then no, you cannot use it for an application. And yes, a plugin is an application.

What’s a wordmark?

That’s the name. So Facerange’s wordmark would be “FACERANGE.”

I have permission from PayBuddy to use their wordmark/logo, is that okay?

We’d rather you not use it on your PLUGIN pages. It’s impossible for us to verify, and many agreements with brand owners are rescinded. Brand your webpage all you want, but leave their official logos and word marks off your plugin.

A brand contacted me directly and asked me to change things. Is that a real demand?

More than likely they are. They’ll usually include links and directions and contact information. Use that and comply with them, because if you don’t, they’ll come to us.

What about existing violations?

We’re handling them in batches. You don’t need to report them to us.

But if you haven’t closed them, why are you closing my plugin?

Because there are thousands of plugins and we do them in small batches for sanity. Also brand owners sometimes give us a priority list, and you just happened to be higher than someone else.

Don’t they get an SEO boost?

No. Write a better readme that uses the brands properly and contextually, and you’ll be fine.

Someone’s infringing on MY brand, what do I do?

Contact them first. Ask them to stop (nicely please). Link them to your brand documentation. If they ignore you, email us the same. We’ll close the plugin until they fix it.

We recommend you BE CLEAR about what you require. Remember, most people aren’t familiar with trademark laws and their intricacies, so it’s very easy for them to get confused.

#guidelines, #trademarks

Reminder: Developers Must Comply with the FORUM Guidelines

The forums team has notified us of an uptick in developers unnecessarily reporting posts and reviews. This post is to remind you that if you chose to use the WordPress.org support forums and review systems, you are required to comply with their guidelines.

This means abuse of volunteer services, or misusing the ‘report this post’ feature will result in formal warnings from the plugins team. If the behaviour persists, your account will be suspended and your plugin closed. This includes directly asking forum moderators to remove reviews via Slack DMs. Yes, we know.

We know that sometimes people leave really annoying reviews that are frustrating and inaccurate. But attacking your users, calling them names, claiming they’re fake, and reporting the review is far less helpful than you might think. Bad reviews, reviews that should be support, and angry users are a part of maintaining a plugin. It’s the annoying part, and no one likes it, but if you’re giving your plugin away for use, people are going to have opinions.

A review is someone’s opinion of your plugin and the experience using the plugin.
A bad review WILL NOT BE DELETED. Negative feedback reviews will not be reviewed.

The only time a review is removed is when it is, of itself, in violation of the forums guidelines. Not liking your plugin is not a violation. It’s just someone who doesn’t like your plugin.
Please try to be more respectful of the volunteers’ time, and don’t needlessly flag forum posts and reviews for moderation. If you’re not sure if something is a violation, you can come to Slack and ask in the #forums channel.

Proposal to Modify Plugin Guidelines

This post is a proposal of changes to be made to the Plugin 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 WordCamp 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

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.

Don’t Get Scammed

There’s a company who regularly emails people telling them that for $50 or $100 they’ll review your plugin or theme and you’ll get 5 star ratings on WordPress.org. They’ll tell you that doing this will get you SEO and traffic and they’ll link to their domain as proof of their success.

They’re lying.

Don’t fall for this. Never pay anyone for a review, it’s all a scam and the worst case scenario is that they actually do write a review. Why is that worst? Because if we find out you paid for reviews, we remove your plugins from hosting.

If you got a mail from a certain company offering a Valentine’s sale, know that we already know about them. They’ve been banned from here for years but we’ll be monitoring reviews just in case they slip through.

#reminder

Reminder about Behavior

This really shouldn’t need to be said however, based on three recent incidents, it is clear we need a reminder.

You are responsible for your own actions and choices. If you decide to do a thing, you are assuming responsibility for the outcome and, like it or not, the repercussions fall on you and you alone.

When you work with a team of people to support and maintain your plugin, everyone is required to follow the plugin and forum guidelines. Choices made by the team will impact the group as a whole, for good or ill.

Recently a company was banned due to having never briefed their employees on the plugin guidelines. This led to a new, un-monitored employee, egregiously violating the guidelines, harassing and abusing the volunteers of the forums as well as the end-users, who were just trying to get help with the plugin.

The company had been warned about this kind of behaviour before. In fact, they had been issued a final warning. As this was a repeat of the exact behaviour they’d been warned on, their plugin was closed and the company prohibited from hosting anymore.

Sadly this isn’t the only time that’s happened in the last 4 months.

If you work with a team of people, the company/group is responsible for each other. If one person in your group/company violates the guidelines, it’s the whole group who will suffer as you’ve demonstrated an inability to manage your team. The same is true if a rogue intern or SEO marketer spams the forums. They’re doing those actions in the name of the company, which makes the company accountable for their actions.

Don’t hire random people from companies like Fourer to do your marketing. Don’t let people loose in the forums without making sure they understand the guidelines and our expectations.

Abuse, name calling, harassment, stalking, and spamming the forum moderators is not permitted behaviour by anyone. Users are banned for this, and developers will find their companies and all plugins similarly removed. We feel it’s unfair of people to put the burden of monitoring and managing their team on the volunteers of the forums and the plugin team. This is especially true of companies.

Please make sure the people who work with you understand not just the guidelines, but the stakes. Quite often we find an enthusiastic intern is the cause of sockpuppeting, or a well-meaning SEO consultant who took the wrong lessons to heart and made a readme filled with spam.

If we have to contact you multiple times about your behaviour, or that of the people you’re working with, we’re simply not going to permit you to use our services any longer.

#guidelines, #policy, #reminder

Year End Summary – 2018

Well 2019 is almost here so it’s time to look at a years worth of plugin reviews.

Everything

Here’s the chart of everything for the whole year. That gap in January-March is due to a snafu in the system. It wasn’t properly recording anything, so we weren’t able to collect stats.

Highs and Lows

Due to the above gap, our ‘least’ for the weeks are a little off, but you’ll get the general idea of how much we review a week:

Requested Rejected Closed Approved Pending
Most / week 281 99 1171 149 730
Least / week 101 2 9 36 566
Average / week 164 21 341 87 651
YEAR TOTAL 7095 1062 13034 3752 566

What it Means?

We can see that roughly 52% of all submitted plugins are actually approved.

Why are only about half of all plugins approved? I could give you a lot of math explanations, but the crux of it is this: people don’t reply to emails.

Around 35-40% of plugin submissions are pended, either for more information or for code issues, and the majority of those simply never finish a review.

This year, though, we have an abnormally high number of closed plugins (see those gold spikes). This comes from a lot of cleanup of unused plugins (ones where code was never committed) as well as plugins with email-bounces. Due to GDPR, many email servers changed their reporting so we’re finally getting some accurate data on bounced emails.

Of the closed plugins, about .003% of developers reached out to us about them, and of those, the majority were because emails were out of date. This is why I’m always harping on people to make sure their account emails work and don’t auto-reply or bounce.

If your email bounces, we’re not going to email you or hunt you down to figure out who’s supposed to own a plugin. It’s not an efficient use of our time for people who aren’t maintaining their accounts. We’re aware it’s not very nice, but since our accuracy rate is well into the 99th percentile, it’s more effective to close the plugin.

What’s the take away from this? Check your emails. If you submitted a plugin and didn’t get an automatic reply telling you it was received and what the plugin slug was, then you’re having trouble getting our emails and you should add plugins@wordpress.org to your email’s never-spam list. If you did get that email, count 7 days from that. You will have another email from us by then, either as an approval or a rejection (which always comes with a reason why).

Bounces, AutoReplies, and You

Over 150 plugins were closed during WCUS due to auto replies, bounces, and confusing plugin ownership.

In our plugin developer expectations, we say this:

It is the responsibility of the plugin developer to ensure their contact information on WordPress.org is up to date and accurate, in order that they receive all notifications from the plugins team. Auto-replies and emails that route to a support system are not permitted as they historically prevent humans from addressing emails in a timely fashion.

Your email has to work. If we can’t get a hold of you, we’re going to either remove you from your plugin or, if you’re the owner, close it. This is especially true if we can’t figure out who’s meant to own a plugin, or the ‘official’ company account is bouncing.

If your email sends an auto-reply, or a partial bounce (that is, you have a group email and one address in the group bounces) we ALWAYS email you with as much detail as needed to resolve the issue.

Since we sent out a mass email in October, pre 5.0, and another last week, we had a 50 day window for many people to correct the issues.

Let’s hit up some of the reasons why we do this:

Auto-Replies are a bad developer practice

Two reasons, besides the fact that they’re spammy, that a developer account should never auto-reply:

1. Security
2. Communication

Security is the biggest. An auto-reply generally comes from a SUPPORT account. A support account should NEVER be receiving our emails because they’re likely to be related to insecurity in your plugins. We don’t 0-day you, ever, that would be cruel. We want you to fix things ASAP, though, for your users, and if support gets that message, now you have more people, who may not understand not to tell customers about the problems. Also we have no way to be sure the developer got the email. You’re trusting support to escalate properly every time.

Communication is obviously related. We’ve got to be able to get a hold of you, and putting layers between us and you isn’t going to help.

Auto-replies cause developers to not get notifications

We actually DO inform everyone about the status of auto-replies. Once we determine what plugin causes the reply, we email everyone with commit access (i.e. your developers) that there is a problem and to please resolve it. The fact that a high number of you aren’t seeing those emails is indicative of the problem.

Developers aren’t support

For the majority of plugins, this is actually not true. That is, most people are developers and their own support. But those aren’t the people who make auto-replies. The people who have auto-replies tend to be companies. And for a company, there’s a reason they want the auto-replies for people contacting support. That’s perfectly sensible.

The disconnect here is that we expect the people who have commit access to be developers. We

Thankfully we have a solution for you! You can add your support users as Support Representatives for your plugin!

WordPress isn’t your user

All of that said, having an auto-reply on the account you use here to manage your plugin and support your users creates a poor experience. People can’t email you from WordPress.org and while you can chose to get emails for all new posts in your plugin’s forum, having that sent to an auto-reply is rather odd. Why would you want to auto-reply to an automated notification email?

Shared accounts are dangerous

This goes back to security. Don’t share accounts. NEVER share accounts. Give developers individual access to commit code. Add support reps individually. Doing this gives you an easy way to track who commits what code, who answered what question, and you can now hold them accountable for their individual actions! Got one support tech who goes off the rails? You can explain that it was one person and you’re handling it. Or the forums team can help you block their account if needed.

Bounces are harder to unravel than you think

Sometimes a bounce is obvious. If a user no longer exists, we can close the plugin. If a domain no longer exists, you’d think we could close it, but what if that happened because a company renamed themselves and forgot to update the emails? And what about when the bounce is from the domain, but doesn’t say WHICH user account bounced? It takes time.

We know a handful of people have been upset to find out we closed their plugins instead of trying to sort out who actually should own the plugin when the email bounced. We are sorry about that, but it was a case of prioritizing and expediency. It’s much more efficient for us to close the plugin and let you contact us than to spend a couple hours untangling who represents a company and is legally responsible for managing a plugin.

Questions?

As always, if your plugin was closed and you don’t know why, email us with a link to the plugin and ask. We’d rather have them up and active and usable too!

#reminder #email

Blocks, Plugins, and You

WordPress 5.0 has been released and with it the new block editor for composing posts has been released.

There are exciting possibilities afforded by the new interface and we like to show off new things. So, we’re showcasing plugins that are block-enabled.

If you’ve written a plugin that introduces or improves blocks, or know of a plugin that does, email us at plugins@wordpress.org. Note that these must be plugins with their block-enabled version currently available in the Plugin Directory.

We’re featuring these plugins in a new “Blocks-Enabled Plugins” section in the directory, as well as in a new section on the WordPress Plugins homepage.

We will be doing something similar with themes soon, so stay tuned!

#blocks