“Not Updated In …” Warning

The old warning that a plugin has not been updated in 2+ years has been changed to an indication of what version of WordPress a plugin has been tested up to. If that version is more than 3 major releases old, a plugin will be flagged as being maybe out of date.

Why the change?

Two years was rather arbitrary, but also wasn’t helpful to as many people. That is, two years had little meaning, since there were many plugins that didn’t need updates.

In addition, developers failed to understand what we meant by the multiple emails (the ones we send every major release) asking them to bump the tested-up-to value, without releasing new code. By doing that, the 2-year warning would go away. With this change, developers have a clearer one-to-one understanding of why their plugin is showing up as ‘old’ and users can see that a plugin has or has not been tested with the version of WP they’re using.

What do I put in for ‘tested up to’ versions?

We recommend the MAJOR release. For example, WordPress is currently on version 4.9.4. If you put in 4.9, then it will show as compatible. Don’t use words like “WP 4.9” – just use the version number.

Can I put in 5.0 as a version?

Yes, but it won’t do what you think it does. That is, you won’t show as compatible with 4.9. Don’t try to be clever on that one.

Does this make more work for developers?

No. A year ago I would have said yes, but now that we’re not releasing new major releases of WordPress 3 times a year, it works out to needing to update plugins’ readmes every 18 months or so. That changes the time by roughly six months, depending on the status of projects.

Can we indicate version compatibility with other plugins?

You mean like bbPress, WooCommerce, and so on? No. We recommend doing that within your plugin code.

Will this change the functionality of plugins?

No. This will neither alert your users nor will it disable your plugin within WordPress itself. You still have to handle that manually.

Is this a guideline change?

Nope. If you don’t want to update it ever, we don’t mind. The only reason we’d close a plugin for being ‘old’ is if it was broken or your email bounced.


Plugin Submissions ETA Reopening Early Next Week

really want to say “We’ll reopen on Monday!” but right now we’re aiming for Monday.

What’s going on?

We found some bugs that didn’t happen in testing.

For example, when we did the final import of all the pending plugins, they were in a maybe-wrong state. That meant we had to go through all our emails and logs to make sure we’d emailed everyone about their plugin status or not. That took us until Friday afternoon.

At the same time, we found some process flow bugs that were just going to make things worse all around and had to address those. It doesn’t do you any good to submit a plugin if we can’t review it, or if approvals don’t generate your SVN folder, for example! We had to document all of those to make sure things would get fixed in the right order (some of them we can live with, obviously).

The good news is that we did clean out the queue, so everyone who had a submission pending has now been emailed. Some of you twice. Sorry about that. If you didn’t get one and you think your plugin is pending, email us at plugins@wordpress.org and we can look.

Thank You Systems/Meta

Systems and Meta have been wonderful, plowing through the tickets raised. Right now, we’re prioritizing “Fix what’s broken” so the only tickets you see in the Plugin Directory v 3.0 milestone are items we feel must be fixed as soon as possible. If I’ve moved your ticket out, it’s simply because it’s not deemed mission critical at this moment, and not that it will never be addressed. It’s triage, and we were just as brutal about it on ourselves.

Thank You Too

I really do appreciate everyones patience and understanding.

Obviously things didn’t go perfectly, but considering the magnitude of this change, it’s gone smoother than I predicted (I may owe people dinner now). If you want to help us out, right now please spread the word to your fellow developers. Remember, if you can get everyone to read this blog first before they email/dm/ping for status, you make reviews go faster!

#directory, #repository

Plugin Directory Chat: Nov 2

Next plugin directory chat 2016-11-02

We skipped this week and we will next meet at 2016-11-02 22:00:00 UTC


Reviewing the Revamped Guidelines

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.

WordPress.org Plugin 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!

#directory, #guidelines

WordPress Plugin Directory

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?


Plugin Directory Revamp Meeting Today

Plugin Directory Chat Agenda

This is _not_ a meeting about the plugin review process or guidelines. This is only about the revamp.

#directory, #reminder, #repository

Status on the Plugin Repo Revamp, Guidelines, and Handbooks

First off, please read Obenland’s post on the repo:

Plugin Directory v3: Next Steps

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.

#directory, #guidelines, #repository

New Repo Open Beta

Please review the proposed new repository and leave some comments so Obenland can make all more awesome.

Plugin Directory v3 Open Beta


#directory, #repository

Please do not submit frameworks

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.

We don’t allow people to add javascript or fonts on their own to the repository and, I suspect, most of you would nod and say “Well of course not. A font and javascript should be included in the plugin or theme!” We feel the same way about most full blown library and framework plugins too. The user doesn’t need to know or care about the libraries. They shouldn’t be expected to be responsible for it.

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.

#directory, #reminder, #repository

On the Topic of Selling Your Plugins…

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.

#directory, #plugins, #selling, #spam