WP 4.9.6, Privacy, Hooks, and You

WordPress 4.9.6 has been released. This was a focused release, a little different than other minor releases, in that it adds a system for a privacy policy to WordPress. While the only change to plugins has been our requirement that you not claim (or imply) 100% compliance in anything, the changes to privacy awareness are far reaching.

The tl;dr of the whole post is “You’re going to need to consider the impact of data collection in your plugins, even if you don’t collect anything.” So yes, I know it’s long, but please read the whole thing.

NOTE: We are not lawyers. We cannot tell you if what your plugin is doing is going to break a law. Please don’t ask us to try and figure that out for you. The purpose of this post is to make you aware of what’s going on, and give you a place to start with making your plugins better.

Does This Impact You?

Yes. This impacts everyone. Plugins are used internationally which means you actually do have to be aware of the world, Net Neutrality shenanigans aside. Your plugin could, in fact, cause someone to get in legal trouble. While that is technically their responsibility, you should be as aware as possible of the implications of your code and how it’s used.

Ask yourself this: Does your plugin…

  • … write any private data of users (registered or visitors) to the database?
  • … send any data to remote servers (i.e. act as a service or embed content)?
  • … edit the comments form in any way?

If yes, then this absolutely, without a doubt, impacts your plugins.

If no, then this may still impact you, so please keep reading, because people are going to ask you about this.

Privacy Means Disclosure

If you’re a service, like you pull a library from a remote server, then you have to tell people that you pull data remotely. This has always been a policy, so if you’re not disclosing this now, please go fix it right away.  But you also need to tell people the obvious things, like embedding content via your plugin means the site administrator is consenting to the embed terms of that service.

An example for you. Let’s say you have a plugin that embeds YouTube playlists. Your plugin should be clear “This plugin embeds YouTube Playlists.” We also recommend you include a link to YouTube’s privacy doc. It’s alright to say “By using the embed features in this plugin, you will be agreeing to YouTube’s Terms of Use.”

The same holds true now for data stored locally. If your plugin stores browser data of visitors, then yes, you need to document and disclose this. You can’t force site admins to publicize this in turn, but by making sure they know, you’re helping them determine what their own reasonable disclosure should be.

Some Code To Help

WordPress has gone the extra step to make it easier to make a privacy page and hook into it, both for users and developers. The moving parts you need to be aware of are the tool for users to request an export of all the stored data associated with them on the site. There’s also a tool for users to request erasure of that same data. Both tools include admin workflows to fulfill those requests. And there’s one to suggest what kind of text should be on someone’s site.

The handbooks have been updated to help you out here:

Also, while this is a little more aimed at theme developers, if your plugin happens to mess around with comments, please read the changes that affect themes, as there is going to be a new checkbox for comments.

Update Your Plugins

The tl;dr of all this is that plugins should…

  • … disclose what user/visitor information it saves in the readme;
  • … hook into the privacy page creator to inform people there too;
  • … provide a way to export said information;

We aren’t (currently) changing any policy to require all this. At the same time, I strongly recommend at the bare minimum everyone put a privacy policy in your readme. Even if you don’t save any data and you don’t send anything, make a Privacy Policy anyway and tell people that.

Why? At the very least, it may stop people from asking you “Is this plugin collecting any data?” which saves you time. But more importantly, this is to protect yourself. After all, if people come through with a 1-star review that you caused them to become non-compliant because you didn’t disclose local data collection, well, that would be a very justified review.

#core, #guidelines, #privacy

Closing Unused Plugins

When you submit a new plugin, we get to see every single plugin you’ve ever submitted. This means we also see how many plugins we approve that people never use. At this moment, there are over 9100 plugins approved and unused.

Edit: Unused means LITERALLY unused. No one uploaded code. Ever.

Because of that, we’re going through and closing unused plugins if it’s been 6+ months since the plugin was approved. In addition, if we notice a pattern of behaviour, where you are submitting multiple plugins and not using the provided hosting, we will pend any new submissions until you actually use the directory.

The good news about this is once we close it, people can request to take over the slug and use it for a new plugin.

Remember: Every time you submit a plugin, a human being downloads and reviews your code. If you’re submitting with out a plan to actually use the hosting, you are abusing the finite resources, and taking away from everyone else who is using the directory. Worse, we’ve found out some people like to get a review as a ‘free’ security review instead of hiring people for that work.

Most of you, this won’t impact in the slightest. After all, you use the hosting 😀

And of course, if you have a plugin you don’t want to host anymore, you can always ask us to close it (though please read the FAQ on Closing Plugins first).

#directory

https://make.wordpress.org/core/2018/05/01/javascript-internationalization-the-missing-pieces/

JavaScript Internationalization: The Missing Pieces

Legal Compliance Added to Guidelines

Guideline 9 (Developers and their plugins must not do anything illegal, dishonest, or morally offensive.) has been amended to include the following new prohibition:

  • implying that a plugin can create, provide, automate, or guarantee legal compliance

While the vast majority of plugins will never run into this issue, we want to explain why this change is necessary.

Over the years, by accident or intent, some developers have claimed their plugins can provide legal compliance, sometimes automatically, across various aspects of site administration. These areas have included security (e.g. FIOS, PCI/DSS), cookies and tracking (i.e. the “EU Cookie Law”), online shopping (VAT), privacy (GDPR), accessibility (ADA), copyright, and more.

Sadly, no plugin in and of itself can provide legal compliance. While a plugin can certainly assist in automating the steps on a compliance journey, or allow you to develop a workflow to solve the situation, they cannot protect a site administrator from mistakes or lack of compliance, nor can they protect site users from incorrect or incomplete legal compliance on the part of the web site.

In short, plugins are helpful tools along the legal compliance journey, but should never be presented as a solution, nor should they give users a false sense of security.

Because of that, going forward we will be attempting to prevent these types of claims in all plugins. These issues will be handled in the same way we try to make sure that people don’t use ‘official plugin’ without actually being official.

Plugins that are are currently at odds with this change, either by accident or intent, will be notified shortly and required to change their titles, descriptions, and/or readmes.

ETA: I made the FAQ public early to hopefully help you with any questions!

#guidelines, #notice

Plugin SVN Migrated

EDIT: Plugins trac is up and running again. Everything should be good now. -Otto

As with all those things we migrated, SVN had to move too. It’s on shiny new servers, which hopefully will resolve the issues where a plugin was approved and didn’t generate SVN folders properly.

Currently everything’s up and running except for plugins trac. As Otto put it, “with 1.8 million commits, that takes a while” …

Systems is keeping tabs on it, and will fix anything weird with trac. Don’t panic if it goes off line or things aren’t updating properly. Be patient with us if we’re reviewing your changes (we have to do it manually now). We’ll update when there’s something to say other than “Yup, it’s syncing.”

#services #trac

X-post: WordPress Community Code of Conduct Survey Draft

X-comment from +make.wordpress.org/community: Comment on WordPress Community Code of Conduct Survey Draft

Understanding Readme.txt

At it’s heart, the Readme.txt file is pretty basic. You put in the information, it generates a WordPress page. Of course, it’s not all simple magic, and there are some weird things to be aware of.

To help people better understand how it works, the Plugin Directory documentation has been updated, but here’s a quick primer:

If you use Tags, so will the directory

If you put the stable version of 1.2.3 in your readme, the rest of the content will be pulled from /tags/1.2.3 and not the trunk folder.

Readmes use Markdown (mostly)

Most Markdown calls work as expected. Tables do not. But this means don’t put JS or CSS in your readme. It will break things.

Videos

A YouTube or Vimeo link on a line by itself will be auto-embedded. It’s also possible to embed videos hosted on VideoPress using the wpvideo shortcode.

(File) Size Matters

If your Readme is over 10k, weird parsing things happen. Some tips to keep it small:

  1. Move your previous versions’ changelogs to their own file – changelog.txt
  2. Self-host seriously intensive documentation
  3. Make your readme a ‘how to’ and ‘why this is awesome’ but not a sales pitch for your pro version
  4. Don’t keyword stuff (someone dropped their readme by 4k when they cleaned it up)

Well written readmes get more users

Want to rank higher? Write a good readme. It’s actually much less about keyword stuffing than it is keeping users. After all, we’ve all seen a plugin with 20k downloads but only 10+ active users. That means you’re getting people’s attention and not delivering. So write a good readme that sells what you do, and sells it well. Don’t embellish, like saying you’re the ‘best’ contact form plugin. Ditch the hyperbole and just write good. If you can’t, hire a copy writer. It’ll pay off.

Reminder: Paying for reviews is a guideline violation

Normally this comes up because we have to explain that paying a single person for a review is bribery.

This isn’t that.

I’m talking about when company or consultant on those websites like Fourrer (not it’s real name) offers to, for $50 or $450, leave 5 star reviews on your plugin. That’s a practice known as ‘salting’ (go look up ‘salting mines’ if you’re interested in why) and it is prohibited behaviour.

Reviews of your plugins should be made by users who actually use the plugin. When you pay people, either individually or en masse, to review your product, you get disingenuous reviews that are inclined to be of a higher nature. When you pay a company to get a series of 5-star reviews, you’re outright lying to people. You’re making them believe other users have reviewed when they have not.

If we catch you paying for reviews, you will lose ALL reviews made during the time period. Sadly, this is because we do not have a way to quickly or easily verify each and every review and user account. It’s an inefficient use of our resources to do so manually. In addition, we cannot accept a developers ‘word’ about which are and are not the purchased reviews, as many have lied about that in the past, and few have incentives to be fully honest. Finally, the fate of ‘valid’ reviews caught up in the removals are considered ‘fruit of the poisoned tree’ and cannot be restored.

And if that’s not bad enough, if you do it again, you lose your plugins.

Don’t pay off people for reviews.

X-post: Dealing with Angry Users – Workshop on March 16, 2018

X-comment from +make.wordpress.org/support: Comment on Dealing with Angry Users – Workshop on March 16, 2018

Keyword Stuffing is Spamming

In January 2017 we clarified what was meant by not spamming in the directory.

Since then, the language has been tweaked slightly, but the crux of the matter remains as follows: Public facing pages on WordPress.org (readmes) must not spam

To whit:

Public facing pages, including readmes and translation files, may not be used to spam. Spammy behavior includes (but is not limited to) unnecessary affiliate links, tags to competitors plugins, use of over 12 tags total, blackhat SEO, and keyword stuffing.

If you have a keyword or phrase repeated over 30 times in your plugin, you’re probably spamming. There are exceptions, especially when a term is a common word or you’re listing your shortcodes. However please be reasonable. If we see you using the same word 50 or more times in the readme, you’ll likely be receiving a warning.

Please take these warnings seriously. If you get asked to fix one plugin, we expect you (and ask you) to take care of any plugins we didn’t list as well. Be mature humans.

#guidelines