Plugin Directory Revamp Meeting Today

Plugin Directory Chat Agenda

This is _not_ a meeting about the pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party 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 pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party.

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 releaseRelease A release is the distribution of the final version of an application. A software release may be either public or private and generally constitutes the initial or new generation of a new or upgraded application. A release is preceded by the distribution of alpha and then beta versions of the software. 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 pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party
  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 CSSCSS CSS is an acronym for cascading style sheets. This is what controls the design or look and feel of a site., 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 DDoSDistributed Denial of Service A type of online attack where a large number of infected computers are used to overwhelm a target computer, to the point where it no longer has the resources to perform its normal job. Read more. 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 pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party 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 pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party 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 javascriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/. 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 coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. 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 coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.. 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 UIUI UI is an acronym for User Interface - the layout of the page the user interacts with. Think ‘how are they doing that’ and less about what they are doing.. 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 pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party 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

Reminder: Your Email Account Must Be Valid

Since the only way we have to get in touch with pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party 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 plugins@wordpress.org

The following email situations may result in your plugin being closed if we can’t find a way to communicate with you:

Invalid Emails

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.

Auto-Replies

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.

2-Step Verification

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.

Deceased Authors

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.

#email, #reminder, #repository, #security

Sock Puppetry Is Not Welcome

When a single users makes multiple accounts with the sole intention of leaving reviews on their own plugins (or leaving poor reviews on their competitors), this is called being a “Sock Puppet” – https://en.wikipedia.org/wiki/Sockpuppet_(Internet)

This behavior is expressly NOT welcome on the WordPress Forums as it is spamming, and it can result is us removing all your plugins from our repository for abuse.

That’s from an email we send out when we catch you (or your pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party team) making multiple accounts.

There’s a fine line between making multiple accounts for a team and making fake accounts that leave comments and reviews on your plugin, which you (or someone else on the team) then interacts with.

It’s disreputable, it’s an abuse of our good faith in you, it’s spamming, and it’s wasting the time of forum volunteers.

It’s also not permitted.

We’ve shut down many plugins because the authors engage in unwelcome behavior. Please don’t make us shut down yours. Don’t leave reviews on your own plugins, don’t make fake support posts, don’t spam. It doesn’t make your plugin look good and it will result in your plugins being pulled.

#reminder, #warning

Your Plugin Committers Should be Your Developers

After we started pushing back on the auto-reply stuff, a couple pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party devs said that they used their support accounts (like support@example.com) as their committer so that they could get email updates from the forums.

This is a terrible idea. It’s insecure and rather dangerous.

That means the support account is the one with write access to your plugin. And that means anyone with access to your group email (or your support tool) can click on reset password, get the password, change it, and blow up your plugin. Obviously that’s a major security issue. The only people who should have write access to your plugin should be people who know how to code and are responsible and reliable and trustworthy. And remember, people can go nutters in a company of any size and seek out revenge in weird ways. Limiting the damage they can do is your responsibility.

This also means that when we send you an email about your plugin, you may be accidentally sharing privileged information with people who have no business knowing these things. With a support account for a company of four people, it may be okay for everyone to know your plugin was pulled from the repository for a security hole. When you have a company of 300 and you use a system like ZenDesk (not to pick on them, but they are popular), now everyone knows. This may not seem like a big deal, but if one person tweets “OMG! Plugin FOO has a security hole!” then there’s a major risk that you’ve opened up the floodgates of potential hacks. Limiting the risks you put on your users is important.

Only allow your developer account(s) to have commit access to your plugin.

If you want one joint email-alias (wp-plugin-dev@example.com) that forwards to everyone, that’s okay, but not great. Remember, if everyone has their OWN user account, then you can easily track who pushed what change to a system. If you’re only using SVNSVN Short for "SubVersioN", it's the code management system used to maintain the plugins hosted on WordPress.org. It's similar to git. as your version control, it’s a good idea to make sure you know who did what. If you’re using GitGit Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency. Git is easy to learn and has a tiny footprint with lightning fast performance. Most modern plugin and theme development is being done with this version control system. https://git-scm.com/. or Mercurial or your own SVN to track the changes, then make sure that only responsible, reliable, people have access to that dev account. Again, remember that we’re talking about access to push code to (say) a million users.

Remember: Anyone listed as a developer has the ability to remove anyone else as a committer. So you really want to limit those users.

Make a separate account to handle support

Make a separate account (wp-plugin-support@example.com) that does whatever it needs to do. Then you can sign up for email alerts. Go to https://wordpress.org/support/plugin/YOUR-PLUGIN and scroll to the bottom where it says “Subscribe to Emails for this Plugin”:

Click "Subscribe to Emails for this Plugin" when logged in.

Click “Subscribe to Emails for this Plugin” when logged in.

Click the link and baboom, that account gets email alerts. You can do the same for reviews at https://wordpress.org/support/view/plugin-reviews/YOUR-PLUGIN if you want to catch the inevitable ‘this review should have been a support post’ threads.

Remember: If you sign a support account up for getting those emails, you should still disable auto-replies. Otherwise you’ll be generating a lot of unnecessary email every time someone replies to your threads and you may get caught as a spammer.

Add your support accounts as Contributors

Contributors are the people you list under the ‘Authors’ field on your readme. They do not have any commit access to a plugin. They can’t edit the code.

Example: “Automattic” has an account for Jetpack. That account can be a placeholder account. It can be a support account if you want to use it in the forums. It can be marked as a Contributor in the plugin’s readme.txt in order to get special markings in the forums for replies from that account for that plugin.

The other accounts should be individual accounts, belonging to the devs, and preferably using their company email addresses. This way, if the organization changes, an individual leaves, etc, the email address still goes to the company and the plugin can be recovered, if necessary.

Back on Jetpack, there are over 70 people listed as ‘authors.’ They all get that happy plugin author green lozenge in their forum replies and they can officially help people without you worrying they’ll miss a semi-colon and take down 20 thousand users with a bad push of code.

Remember: Anyone listed as an author is going to get that green lozenge. If you don’t want people representing you, credit them in the readme but remove them as an author.

#reminder, #security