This is _not_ a meeting about the plugin review process or guidelines. This is only about the revamp.
First off, please read Obenland’s post on the repo:
Obviously we have a long way to go.
As for the Guidelines, I wanted to be done and ready to release them to everyone before 4.6 dropped, but I’ve been using small focus groups at WordCamps first. This resulted in a lot of small changes that I want to take the time to go over with the Plugin Team before I unleash it to the world for nitpicking. A huge amount of thanks goes to @courtneydawn @logankipp and @lunacodes for being my first run of editors!
As we clean up the aftermath of the 4.6 emails (you have no idea…), I’ll be pinging people whom I know to be good copyeditors and have mentioned wanting to help before. If you think that’s you, please leave a comment here. I won’t be asking everyone as I’ve found that to be overwhelming for me to be able to process, so please don’t take it personally. Once I have it mostly good, I’ll flip it from Google Docs to a Git Repo and people can pull request!
Also a handbook! Oh me oh my I’ve been writing one! And I’m almost ready to ask Sam to flip the switch for it. It’s sparse and will need lots of attention too.
Thank you everyone for understanding the crazy that goes on with all this, and for being patient. It’s been a long 7 months for me working on all this.
Please review the proposed new repository and leave some comments so Obenland can make all more awesome.
In a very irregular feature, we’re posting about various plugin guidelines and what they really mean to you.
This week, we want to remind you about a long-standing guideline in the repository, which is covered in item #7 – Don’t phone home without consent.
No “phoning home” without user’s informed consent. This seemingly simple rule actually covers several different aspects:
The guideline goes on to break down what we mean in four main points:
- No unauthorized collection of user data
- All images and scripts shown should be part of the plugin
- No 3rd party ad tracking
- No ad-spam
That second item (which I emphasized) is what we want to remind you of today.
Your images, your scripts, your CSS, etc, should all be included locally. Besides not tracking users, keeping everything locally will make your plugins faster. It obviates the problem of external load. It means when your server is down for maintenance, you didn’t just slow down everyone’s wp-admin. It means you’ll never DDoS yourself on accident.
Unless you’re a service, your plugin has no business phoning home to your own servers to load data. If you are a service, you must have this clear in your readme as to what the service entails, preferably with a link to your ToS and and explanation as to what is tracked. This is for your protection. By remote loading files, you have the ability to track users. Data tracking is a huge deal, and while we understand you want to do it for metrics, it someone was taking your data without permission or consent and selling it or using it to promote their code, you’d be pretty ticked off.
You can (and should) re-read all the guidelines on https://developer.wordpress.org/plugins/wordpress-org/detailed-plugin-guidelines/ – we rarely change them though we may reword things for clarity.
If you have suggestions as to how we can be more clear about #7, please leave a comment and let us know.
Keep in mind, we’re not going to spell out everything to the letter, as in our experience that leads to people playing nit-picky fake-lawyers about everything, and still violating the ultimate rule of the guidelines which is ‘Don’t be a spammer.’ For example, we’re not going to make a rule for not stealing other people’s plugins. You already know stealing is bad, right? 😈
I want to thank everyone for coming to the first ever plugin review contributor workshop!
We did not get half as much covered as I’d like to but I hope that we were able to enlighten some of you as to how the repository and review system works.
I’m looking forward to the near future when we’ll be able to start adding some of the wonderful people who came to contributor day to the review team! Since that’s still a bit in the future, what we can do right now is welcome everyone to
That’s right, we have
#pluginreview as a channel now. This channel is for us (yes, you and us) to talk about plugins, finding issues like
base64 and creative commons code. At this time, in order not to put users at risk, please continue to send security issues to
I plan on posting some plugins for you to download and look at and discuss, as well as possibly have open hours or a scheduled time every once in a while to talk about reviewing a plugin as a group.
Also if you have a question about the plugin repository in general, please feel free to ask there. Please remember to be reasonable, though, and try not to ask “When will my plugin be reviewed?” 😁
In the mean time, what can you do to get started?
First, read the guidelines. Read all the guidelines. Memorize them. Be familiar with things like phoning home, and the difference between a serviceware API and a license check that cripples software needlessly. Don’t worry too much about that, but do get familiar with the guidelines.
Next! Grab the Mark Jaquith Plugin Directory Slurper. The repo is about 25 gigs, more or less, and will take you a few hours to download. By a few what I mean is set your laptop not to sleep, put it in a cool room with a fan, and go to bed. The Slurper doesn’t work well on Windows that I know of (sorry Windows people). Anyone who wants to improve that, pull requests and forks are welcome.
Now once you have the whole repo, start poking at things. Look for code you know is not allowed in the repository (non-GPL is a great start, pick a popular library you know isn’t GPL and grep or ack for it).
Talk about what you find in the Slack channel. Remember: Slack is public. Do not post anything rude, insulting, antagonistic, or mean there. Also don’t post security issues there. Please keep that to email.
Finally, if you’re really super into code ideas, download the (broken) Plugin Check plugin! Have a look at it. Try to figure out how you’d make it work, and maybe fork it onto GitHub and start tinkering. Start with the basics (check for non GPL, calling wp-load directly, including jquery etc) and see how far you can get. More hands make light work, after all.
When Will We Accept New Members?
Soon! I’m sorry, but I just don’t have an ETA.
We need the UX for the repository revamp to be usable and acceptable first. Until then, we’re on that lousy, single-threaded, bbPress setup. Once that changes, the plan is to start letting people apply (and yes, we will post requirements for that) and adding them with access to review privately. Think of it as moderated reviews. But trust me here, we can see the end and we have a plan.
We’re like Cylons.
Note: We are aware that some frameworks are current in the repository. We are asking you not submit any NEW at this time.
This isn’t a new ‘rule.’ It’s not a secret one either. It’s not listed in the guidelines specifically because any attempt to lay down each and every reason a plugin shouldn’t be in the repository just ends in people rule-lawyering. Should we have to tell people “Don’t ask users to write to your plugin files”? No. That should be self-evident. A plugin gets replaced when it’s upgraded, so writing to plugin files means the changes get destroyed. And in many ways, that’s our problem here.
The issue is as follows: Having a framework as a plugin is a poor experience for the user. Not the developer. The user. The user understands “I have an add-on for WooCommerce, I probably need Woo.” They do not always understand “I have plugin Slider Joe. Why do I need Advanced Custom Fields?” In addition, by having a library as a plugin, the onus of version compatibility is now on the person least likely to understand it: the user.
The plugin repository is not, currently, a library or framework repository. It’s not meant like the NPM package manager, or even Composer as a way to define what a plugin ‘needs’ in the same ways for a developer to build a project. The plugin repository is, plain and simple, meant for plugins that users will find useful. Plugins that add functionality to WordPress in a directly inter-actable way.
At this time, we are not accepting frameworks as we don’t feel frameworks, boilerplates, and libraries are appropriate for the Plugins Directory. We require that plugins be useful in and of themselves (even if only being a portal to an external service). And while there are many benefits to frameworks and libraries, without plugin dependency support in core or the directory, it becomes another level of hassle for users.
The parade of likely support issues:
- Not recognizing the framework plugin, and thus deleting it (causing the plugin(s) to break)
- Not recognizing the framework plugin and thinking they’ve been hacked
- Debugging drama, when we tell them to disable all their plugins and they find its a library problem
- Updating the framework plugin separately from the dependent plugins, possibly leading to breakage
- Updating a dependent plugin without updating the framework, possibly leading to breakage
- Plugins not keeping up with library changes to the point that they break
- Different plugins requiring different versions of the framework
And bearing in mind that the framework and plugin developers are different people, that’s another level of coordination/compatibility issues. A developer is (in theory) clever enough to write their plugin in a way that it includes the version of the library they need in a way that will not break everyone else. Of course, you developers know that’s a goal and not an absolute.
Frameworks and libraries should be packaged with each plugin (hopefully in a way that doesn’t conflict with other plugins using the framework or libraries). At least until core supports plugin dependencies.
Making this messier is the fact that once a library is in the repository, you shouldn’t put it in your plugin anymore. Why not? Well what happens if they install a library as a plugin, while having the library inside a plugin already? Which one takes precedent? What happens when they’re out of sync and so on? See the goal up above that isn’t an absolute. It gets even messier.
A library is a library, and should be in the plugin, not separate.
Maybe one day we’ll have proper plugin dependencies, but we simply are not there yet.
Sadly, many of the same reasons we could not add new members to the Plugin Team last year are still an issue (see 2014 Community Summit Wrapup). The codebase has been improved, but the process is slow. Just to give you some hope, the work done on the Theme Repo is being used to help us. So. Soon. Soon. We’re restructuring the backend to make it more clear as to who can do what, but most things are waiting on the re-vamp.
The only real ‘news’ is that we’ve been sneakily moving our documentation over to https://developer.wordpress.org/plugins/wordpress-org/ – Please check it out to keep up with all the information about what makes good plugins in the repo. Oh, and we’ve swapped reps. I’ll be taking over as the plugin team rep and that really changes… nothing at all. @boone did a great job and I thank him for it.
You Can Help
While we are still stuck on the old system, you can jump in and help us by emailing email@example.com when you find people playing fast and loose with the rules.
We encourage and welcome updates from everyone, but please don’t be snippy. Be serious. If someone has powered by links, or is phoning home, yes, please let us know. But don’t let your personal feelings get in the way. This is a big deal. A lot of people send us reports from a place of anger. Don’t be that person. That person makes it harder for us to figure out if someone has a personal vendetta against a plugin and/or developer, or a legit concern. We’re all passionate, but remember to channel that passion into something beneficial.
How to Report Issues
If you’ve found a plugin _doing_it_wrong(), email firstname.lastname@example.org and remember:
- Make your subject clear. (“XSS Vulnerability in Hello Derpy” or “Derpack Developer swearing at users in forums” are good)
- Always provide an exact link to the plugin.
- Report plugins with guideline violations.
- Report developers who are behaving badly.
- Be detailed. If you know what file and line of code is the problem, tell us.
- Provide examples of vulnerabilities. If you already know what’s hackable, show us. It makes it faster for us to verify and reproduce. Link to forum threads etc etc.
Remember: We don’t retroactively enforce guideline changes unless there is a legal, copyright, or security related reason. For example, we no longer allow new plugins to call wp-load.php directly, however we don’t hunt around for plugins that do so. If a plugin is closed for using a non-GPL library and, in the review, we note other best-practices violations, we will require them all to be fixed before reopening.
Also, we won’t be following up with you as to what happened most of the time. We’d love to. We can’t and keep up with emails. Please don’t take it personally. As we add more people to the team we may be able to change that, but right now it takes us away from validating security issues.
Rami asked “What do you guys even use to check plugins and look for bad things?” and the real answer is “Our eyes.” We don’t have a theme-check type plugin because there are very few ‘standard’ things to look for (possibly it could check for license issues, including jquery files, and calling wp-load directly sort of things).
- Mark Jaquith’s Directory Slurper – This will take you up to 17 hours for the first download. Good luck. It goes faster on SSD. Don’t try it on a hotspot.
- Developer Guidelines – Know these. Love these.
- Use Plugin Trac – You can link to specific lines in code!
- Use Private Eye (mac only) – Monitor network connections when testing on localhost (great for finding phoning-home plugins).
- Debug Bar Plugin – Nicer to read error messages
- Query Monitor Plugin – Help you track down weird errors in plugins
Remember: Thou Art Mortal
And so are we.
We’re people too. We make mistakes. We miss things. We have bad days. We get sick. We have families. If we don’t reply to you super fast, please sit on your hands and give us five days. Five. You should get some sort of reply from us within five, even if it’s ‘we’re still talking about this, sorry but it’ll take a while.’ Sending us an enough every 12 hours (yes, someone did that) is annoying.
Hunting us down on Twitter and Slack because we didn’t reply right away is similarly uncool and harassing. We use the email so that everyone on the team can read the conversations. Don’t take it off-line. Keep it in the email and that way, if you’re talking to Otto and he goes to a BBQ fest for two weeks days without access, Pippin can pick up the conversation and help you out.
Just be patient and calm. Especially if we’ve just closed your plugin. We know that sucks, and we totally get you’re angry sometimes. Just try to remember we’re all humans and treat us with respect like fellow humans.
Since the only way we have to get in touch with plugin authors is their emails, we’re going to be enforcing that you have a valid email that goes to a human being for you plugins.
This simple statement covers a multitude of situations but to clarify, we’re talking about the email associated with the user accounts that have commit access to your plugins.
Go to https://wordpress.org/plugins/YOUR-PLUGIN/admin/ and look at the people listed under Committers. Those accounts are who we email when there’s an issue with a plugin, or when we’re alerting you to new WordPress updates. Those emails must go to real human beings. It can be a shared email box (goodness knows plugins is a shared email box) but real people have to read those emails because without that, we cannot communicate with you.
We strongly suggest you whitelist
The following email situations may result in your plugin being closed if we can’t find a way to communicate with you:
If your email bounces, your plugin gets closed. We can only assume that a dead email means you’re done with things, and since we have no way to contact you, your plugin can only be considered unsupportable. If you notice your plugin is closed and you didn’t get an email from us, check your account’s email. If that’s not right, that’s probably why.
If your email has an auto-reply, such as the sort that goes to a support ticket generator, stop it. This makes it nigh impossible for us to communicate with you, we can never tell if a human has read the email, and we get a mail box filled with auto-replies which means you’re the reason plugin reviews are backlogged. We will normally email you one sternly worded warning about this. If it keeps up, your plugin may be closed.
If your email auto-replies and asks people to click or reply in a special way to ensure our email gets to you, guess what? Half the time that doesn’t work. We often get expired tokens because it takes us more than 24 hours to get through all the emails in our queue, and once that happens we have no way to get our email to you.
This is a touchy subject so I apologize in advance. If a plugin author has died and we can verify this, we remove their account’s access to their plugins (and usually reset their passwords to something random). This is in the interest of security, as doing so will prevent any possible issues if their account is hacked. We do not close the plugins. If there are co-committers, they will be notified. Otherwise the plugin will simply remain in place. Taking over those plugins is a similarly touchy subject, and priority will be given to their coworkers or close friends/family who are also WordPress developers.
Did you know we have no auto-replies at all sent from WordPress plugins?
Every single email, even the predefined ones, are written and picked and sent by hand. Even the one that goes out to all 22,573 user accounts with commit access to a plugin.
But you know what happens when we send out that nice reminder to test on WordPress 4.4?
We get a few hundred auto-replies from support systems.
THIS IS A GLOBAL REMINDER
Please change the address on your WordPress.org forums account to one that does not go to an automated support system. We need to be able to communicate directly with plugin authors, and having automated responses don’t help us much.
THIS IS A REQUIREMENT. If we continue to receive automated responses from your support system, we will have to shut down your plugin and remove it from the WordPress.org directory.
We require that we have the ability to contact you about updates on a regular basis. If we also get automated responses, then this eats up our time, and is a problem for us.
Please do whatever is necessary to STOP these automated responses. We would prefer that you use an email address on the forums that goes to actual people, not into a support system. Our forums send emails for all sorts of reasons, and automated responses eat up our bandwidth needlessly, since they don’t go anywhere.
Basically it’s this: If we can’t get in touch with you, we can’t host your plugin.
Please whitelist pluginsATwordpress.org and please exclude us from your auto-replies.
(A quick note – A personal autoreply, like “I’m at a wedding and won’t be back until December 3rd” is not the same thing. Those are fine!)