Thank you everyone for being patient about this.
This summer was spent re-writing and editing and tweaking the guidelines. I ripped them down, sat and spelled out what they meant, then I rewrote them to be more clear. Then I got the plugin review team to review the changes. Then I had a group of people at WCNYC Contributor Day review them.
Finally, I moved it all to a GitHub repo and started to ask smaller groups to review it. Then we had a quick rebranding and that all brings us here.
I would like everyone in the community to read these proposed updates to the Plugin Directory Guidelines.
At the risk of sounding trite, pull requests and issues are welcome.
If you feel a guideline’s explanation is unclear, please create an issue or a pull request with what you feel should be changed and why. All grammar/spelling corrections are greatly welcome. We’re trying to write these for all levels of developers, as well as people who may not speak English proficiently. Using words like ‘obsequious’ should be avoided (nb: That’s mostly to me who uses those words regularly).
All feedback should be opened as issues in the tracker.
Let the games begin!
The WordPress Plugin Repository is rebranding as the WordPress Plugin Directory.
As “directory” refers to the entire plugin hosting service (the site, VCS, etc) and “repository” conventionally refers more specifically to just a VCS (such as GitHub, SVN, etc), we feel this will be less confusing and more in-line with the other aspects of WordPress.org.
We’re in the process of updating all our documentation. I believe I’ve updated all the documentation. Can I nap now?
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.
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.
Unlike the title might suggest, this post is not about buying a plugin from a commercial author, or the viability of “freemium” plugins in the directory, or app stores, or anything of that sort.
This post is directed squarely at plugin authors.
Question: Who owns your plugin?
The answer is simple: You do. You wrote it. You hold the copyrights on it.
Now hold on a minute (one might say), everything in our directory is GPL or compatible. Isn’t that copyleft? Well, yes, and I’m not going to go into excessive amounts of legalese here (IANAL), but the GPL is built on top of copyright. It actually requires it. So yes, you do own the copyrights to your plugin, even when it’s available for free in the WordPress.org plugin directory.
And yes, that totally means you can sell those rights to somebody else. We won’t stop you. Heck, if you ask, we’ll even help you perform the transfer correctly.
Now, while we’ve talked about this before, it’s worth re-iterating because it has come up a lot recently: your name is on that plugin. If you sell it to some scummy spammer, then your name is likely to get dragged through the mud. Not by us, of course, we don’t name names. But other people do notice bad things happening, and they tell other people, and make posts in our forums, and leave bad reviews… and before you know it, you can get a bad rap for something you didn’t even do.
There have been a lot of reports of various unsolicited emails recently asking plugin authors if they would sell their plugins. Sometimes these are legitimate offers. Not often. Usually it’s from marketing agencies looking to add backlinks.
In a couple of notable cases, some of those plugin authors asked what the person was planning on doing to change the plugin. Surprisingly they responded and told them. Let’s just say that these plans are very much against our guidelines.
In at least one case, the plugin author told this prospective purchaser as much, and the person responded by asking how long it would be in the directory before we shut it down, and how many sites could he get the code to before getting this noticed and thus removed from the directory. He even asked whether it was a manual or automatic process (hint: it’s both).
Yes, this guy was actually that blunt about his plans.
While my evidence is slim, I believe this particular person is a Russian spammer or hacker looking to add malware into the plugins and get this code onto as many sites as possible before we put a stop to him.
What can I say? WordPress is a big target. Some are going to try to abuse the system. We’re used to that. Now you plugin authors will need to get used to it too, because you can be a target for this sort of thing as well.
People offering to buy your plugin are generally spammers. They’re probably using fake email accounts, and offering you false information as well. They may be able to pay you, but understand that what they’re looking for is to buy heaps of unrelated plugins, modify them all with SEO spam like backlinks or potentially even malware, and get our systems to push those things to as many sites as possible before we notice and shut them down hard.
Do you really want to sell your plugin to somebody like that? Do you want your hard work to be abused and to have your good name tarnished?
Think twice before selling your plugin. Know the person you’re selling it to very well. Ignore unsolicited emails from people you don’t know. If they are going to pay you based on the number of “Active Installs”, then just don’t even consider it.
Don’t worry about the plugin review team too much though. We can find and shut these things down very quickly, even in real-time. But it does help us quite a bit if you ignore these types of scammers too. 🙂
But if you do decide to give your plugin to somebody responsible and real and who actually cares about it, make sure they know about the Plugin Directory Guidelines. Because hosting a plugin in the WordPress.org Plugin Directory is a privilege, not a right. We can and will act to remove and stop plugins in our systems from doing bad things, no matter who “owns” them.
With the plugin directory now being converted to use language packs, it’s more and more likely that your plugin will be translated by others and available in our various international plugin directories. But banners are kind of a problem for a few of those directories.
Compare the Hebrew plugin directory to the English plugin directory. One thing you’ll probably notice right away is that the icons are on the other side. Hebrew is a Right to Left language, so the design for it is flipped. Click through to any of the plugin and you’ll notice something else: The banner image is the same, but the title is now on the opposite side of the page.
For some plugins, especially those who designed banners thinking that the title was in a fixed place, this can present a problem.
Probably the best solution is simply to make your banner work with either method. Compare Ninja Forms old banner vs. their new banner:
For another example, take a look at Yoast’s SEO plugin.
It’s an interesting stylistic difference, but the point is that they simply made the banner work for either case of title positioning. That’s honestly the best solution, IMO, because it also eliminates something from the banner that shouldn’t be there to begin with: Text.
Text in images is bad. It’s non-accessible. Screen-readers can’t read it. It’s non-translatable to other languages. It’s a pain. Avoid it.
However, sometimes people really like their designs. The design of a banner says a lot about the plugin, even though it’s just a big image. Some authors may want to be able to adjust their banner designs to adapt to the RTL language pages.
For this reason, a couple of weeks ago, we added RTL support to the banners. I’ve been holding off on announcing this here to make sure it worked okay, and it appears to work fine, so, here’s the announcement. 🙂
How to do it? There’s no magic to it. Just make your new banner, and name it with -rtl at the end of the name. Banner images live in the same directory as always, /assets. Nothing else changes.
An example if you want to see how this looks in the SVN: https://plugins.svn.wordpress.org/pluginception/assets/
And how it looks on the plugin page:
Strictly speaking, the banner on Pluginception didn’t need to be reversed. I only did so as a demonstration, to show you how it’s done. Nothing tricky to it.
In the future, adding support for specific locales may or may not happen. It is undecided if it is necessary, because, frankly, there’s a LOT of locales we have. Who wants to make individual banner images for 80+ languages? Best to just leave the text out of the banner instead.
Note that while the RTL banners are now active for WordPress.org, they have not yet made their way into core, so the banners won’t yet show up properly in WordPress installations. Working on it. 🙂
Did your ratings suddenly change dramatically? Hopefully not, but if they did, it’s because the ratings for all plugins were recently reset and rebuilt earlier this week. All ratings now correspond exactly with existing, non-deleted, reviews.
As Otto put it:
Back when we launched the review system 2.5 years ago, we tied ratings to reviews. However, up until that point, we had existing ratings in the system. At the time, some argued that the ratings should be wiped and everybody start fresh. I argued for the opposite, that we should leave the existing ratings in place until such time as we had enough reviews in the system to build up a good body of ratings.
That time has finally come. What you see now is the ratings that correspond to your reviews. The data comes directly from the reviews themselves, and is accurate. Any ratings previously left over from the pre-review world are no longer available.
Additionally, the ratings now will accurately reflect the actions of the moderation team. If a review is deleted for whatever reason, then the associated rating for it will not be reflected in the results.
Please keep in mind, this means that all of the people who thought making sockpuppets to spam the reviews with 5-stars on their own plugins (or 1-stars on their competitors) have had the biggest swings. It should go without saying that you should never leave multiple reviews on your own product (we’re pretty sure you like it 😉 ) and you should never attempt to hide behind proxies and fake accounts to leave reviews. Be honest. It works out better.