Want to Close Your Plugins? Email!

Hi everyone, it’s winter at last, and there’s snow in the mountains! This is the perfect time to sit by the fire and look at your plugins and get rid of the ones you don’t want to be on the hook for any more.

Did you make a plugin for an event that happened a long time ago, like the 2008 Olympics? Did you make a featured plugin that got wrapped into core and you’re done?

Email plugins@wordpress.org with a link to the plugin and we’ll close it for you!

Doing this means you won’t get any new people complaining about how the plugin doesn’t work and disables itself in WP 4.3 and up (even though you documented it…). It’s less work for you and it’s okay to EoL plugins. We’ll close ’em for you and you’ll be done.

A lovely winter present for everyone.

(If you think the plugin has a use and life, but you don’t want to support it anymore, consider adding the tag ‘adopt me’ to your readme. Just update your readme file with that and maybe someone will come and offer a new home for your old plugin. Check out https://wordpress.org/plugins/tags/adopt-me to see the plugins out there looking for you!)

#reminder

The Perils of Partnership

If you’ve ever received an email offering to partner with you or to join an affiliate network or to help you earn money for your plugin, it’s probably a scam.

In the last three months, we’ve seen a serious uptick in emails like “please join our affiliate network” or “I can help you earn money” or “increase your plugin’s SEO” sent to plugin developers. On review, every last one that looked iffy has turned out to be by a nefarious or malicious group of people, who want to either install backdoors into plugins or black hat SEO links.

These deals should sound too good to be true, and they are. They can irreparably harm you, your reputation, and your standing on WordPress.org. Our reaction, when we see it, is to remove the plugin and revoke all SVN access from the developers involved. We don’t always restore access, especially if we feel you may fall for such a scam again or your online behavior is inherently insecure.

I know some of you are reading this thinking “Who falls for stupid stuff like that!” and the reality is anyone. All it takes is one mistake, one moment where you’re not thinking all the way through, and you’ve shot yourself in the foot.

There are some simple tips you can take to protect yourself.

  • Never let anyone else use your SVN account. If you work with a team, everyone should use their own account. This will help you track changes too.
  • Look up the people. Check that they seem legit. Are they using wordpress in their domain name (which you know is not permitted)? Do they already have any plugins? Are they active in the community?
  • What other kinds of plugins do they own? If the plugins are all over the place, ask yourself: Why would they want MY plugin? Companies that make a grab for a lot of different plugins are often trying to find ones with a high user count in order to spam.
  • Preview the code. Never add anything you’re not 100% sure is safe. If the code that gets added has links that look like http://api.wp' . '-example.com/api/upd' . 'ate or 'ht'.'tp://wpcdn.example.com/api/update/ then it’s not trustworthy (those aren’t the real URLs).
  • Does the email look like a form letter? WordPress is such a small community that people generally reach out like human beings. If someone’s spam-blasting a form, it’s sketchy.
  • Check spelling and grammar. If it’s `Wordpress` with a lower case P, or `JetPack` with an uppercase one, it might just be an innocent mistake, but it might not. Businesses should care about these things. After all, you do.

Above all, if you see something, say something. If you get an email like that, forward it on to plugins@wordpress.org with as much information as possible. We would love to see some code samples, for example, as we can add it to our scan routines.

#reminder, #security

Plugin Directory Chat on Oct 5th

I know, it got quiet. There were things.

Plugin directory chat on 2016-10-05

They’ll be picking back up next month though! Come with your thinking hats on. Can’t make it? Leave comments on the above post 😁

#plugin-directory, #reminder

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

Reminder: WordPress 4.6 is imminent. Are your plugins ready? (also make sure your email is valid)

The email went out last night to everyone with commit access to a plugin.

After testing your plugins and ensuring compatibility, it only takes a few moments to change the readme “Tested up to:” value to 4.6. This information provides peace of mind to users and helps encourage them to update to the latest version.

For each plugin that is compatible, you don’t need to release a new version — just change the stable version’s readme value.

Looking to get more familiar with 4.6? Read this roundup post on the core development blog to check out the changes made to register_meta(), native fonts, persistent comment cache, Customizer APIs, WP_HTTP API, and much, much more: https://make.wordpress.org/core/2016/07/26/wordpress-4-6-field-guide/

Thank you for all you do for the WordPress community, and we hope you enjoy 4.6 as much as we do.

Also, as we’ve been warning for the last two cycles, some plugins have been closed. It’s a requirement that we be able to contact you. We’ve also been pushing back on auto-replies, since they make it impossible for us to tell if there’s a human reading. Frankly, based on the content of the auto-replies, this is the cycle we see:

We email you and receive an auto reply of “A support ticket has been created…” We email a warning “Hey, please remove us from this auto reply…” and we get another auto reply. We don’t reply to that one, but 3 months later when we send another email, the cycle starts anew. This tells us that you are not actually reading your support emails. Which means we have no way to contact you (and your users probably hate you, just FYI). So this time, plugins have been closed.

Your plugin has been closed (or you were removed from a plugin) based on the following criteria:

  • If you have auto-replied to our ‘Are your plugin ready?’ email 4+ times, and your plugin has not been updated in 2+ years
  • If your email bounced
  • If your auto-reply says “I’m on vacation until…” and it’s a invalid future date (example: someone’s out of office said they’d be back August 2014…)
  • If your auto-reply said you no longer work at a company
  • If your auto-reply says the company no longer exists

If the only valid emails for the plugin meet those criteria, the plugin was closed. If it was only one committer, they were removed and everyone else was emailed and notified.

In all cases we absolutely emailed each and every one of you. I did it myself. I directly contacted over 80 plugins about this situation and expressly told them if their plugins were closed or if people were removed, and why.

If you find your plugin was closed and you didn’t get an email, check spam, because they were all sent. Even to people who auto-replied. Which was really annoying.

#notice, #reminder, #updates

Repository Guideline Reminder: Do Not Remote Load Content

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:

  1. No unauthorized collection of user data
  2. All images and scripts shown should be part of the plugin
  3. No 3rd party ad tracking
  4. 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? 😈

#guidelines, #reminder, #repository

Policy Reminder: Tracking Users

Do not, under any circumstances, track usage of your plugin without explicit consent.

If you want to ask your users if you can track them, by all means ask. But you may not require it, and you shouldn’t make it look like they have to in order to use your plugin. That’s being dishonest.

This has been a guideline for a very long time, it’s not negotiable. Assume people do not want to be tracked and have it to be an opt-in feature.

If your plugin uses Google Analytics, emails you on plugin activation, triggers some complex check on your servers when a plugin is updated, or tracks usage in any other way when a user has not clearly said “Yes, I allow you to track me,” your plugin will be removed from the repository and you will have to correct this in order to get it back.

This extends to ads provided by a third party service. If your plugin includes advertising from a third party service, then it has to default to completely disabled. This is to prevent tracking information from being collected from the user without their consent. Again, this is all about people opting into being tracked.

(For those thinking about using Adsense, don’t. Re-read their Adsense Display Guidelines and note that they do not want you to put ads on non-content pages … which is what the whole WP Dashboard is.)

Don’t assume that just because someone said they agreed to have usage tracked by you that they’re okay with usage tracked by someone else. Don’t be shady or vague. Tell people upfront “This is who will get the following data…”

Remember, user trust is paramount to your plugin’s success. If people find out you’re sneaky tracking them, you will lose that trust in a heartbeat and there’s nothing anyone can do to help you restore it.

#guidelines, #reminder

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

Reminder: Many Javascript Libraries Are Included in Core

WordPress includes jQuery with core. Most everyone knows this. But did you also know WordPress includes a great deal of other libraries for your use.

You should take the time to check the documentation on wp_enqueue_script().

But that list actually isn’t complete! For a complete list of registered files inspect `$GLOBALS[‘wp_scripts’]` in the admin UI. Registered scripts might change per requested page. You can also check out the massive amounts of files in wp-includes to see even more.

My point, though, is that 90% of the time, you don’t need ‘your own’ version of something. We have it.

Even datepicker folks (jquery-ui-datepicker).

Check if core works. If you call it right, most of the time it will.

#libraries, #reminder

Reminder: Policy About Tags In Plugin Readmes

This is a reminder of current policy.

We ask that users limit tags in their plugins to no more than 12 (twelve), with some exceptions. Any time your plugin has a high number of tags, you’re seen as trying to game the system.

How do you fix this?

  1. Remove any ‘common misspellings’ from your tag list
  2. Remove duplicate tags
  3. Don’t use ‘wordpress’ or ‘wp’ in your tags
  4. Don’t use tags that don’t apply
  5. Don’t use your competitors in your tags (if you’re not a woocommerce plugin, don’t list it)
  6. Don’t list everything under the sun related to your plugin
  7. Do use tags that clearly identify what your plugin is

As much as some people like to think, “tags” are not the same as “search terms” in our system, so including lots of them doesn’t really benefit you much. By adding multiple tags, you reduce the efficacy of searches and tags for everyone and make the experience of looking for a plugin suck. Yeah. You did that to yourself.

If you’re looking to improve your search rankings, we suggest improving the parts of the readme intended for human beings to read. The short and long descriptions should be clear and useful. Addressing common problems in the “FAQ” section helps too. The entire contents of the readme file is considered for the search, and tags are really only a small part of that. Removing irrelevant pieces such as lists of languages (like links) or feature bullet points may help a lot as well, to reduce the overall length and to help eliminate irrelevant information about the plugin.

Make the readme for people, not for machines, and it will help you rank higher in the search results. People actually search for solutions to their problems, not simply for keywords.

#reminder, #tags