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

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.

“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.

#directory

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

Guideline Update

The previously proposed changes have been merged into the plugin guidelines.

It’s important to note that I do not think this is a ‘complete’ or ‘finished’ project. The guidelines are imperfect, in part because it’s impossible to create a rule for every single possible variant of a possible conflict, but also because we cannot predict the future.

There are people who are unhappy we didn’t go far enough with certain guidelines — like not saying “you may have 3 links to your own products on your plugin admin pages.” Others are unhappy we’ve gone as far as we did in certain situations — such as the 9th guideline’s prohibition against harassment.

Accepting the imperfection of English, as well as the flaws built in to creating guidelines for such a large audience, many of whom do not speak English natively, has led to situations where we have to settle. These guidelines are not perfect. They are not complete. They will be constantly evolving and adapting as we try to please and protect the majority of developers and users.

I encourage all of you to help us write them better. You can email us at plugins@wordpress.org or make pull requests on the GitHub repository. While we may not accept all requests, I promise we do listen to and read every last one.

#guidelines

Concept: A Developer Dashboard

One of the ideas that came from WCEU was a centralized dashboard for plugin developers. A place they could go to see all their plugins, and the current status on these plugins. What follows is concept art of what that kind of dashboard may look like.

This is something I dreamed up in Nacin’s talk about the government. This idea has no code backing behind it.

So why am I posting it? I’d like to hear people’s thoughts on this. What do you think would work or won’t work? Too much automation or not enough? Do you actually already HAVE this code written and want to share? Here is a zip of the Balsamiq Mockup: WP-Developer-Dashboard.bmpr_.zip – You know the drill. Edits welcome!

Concept Art

Goals

  • Make a centralized location for developers to manage their plugins

That’s really it. Making this public means a question of moving the ‘advanced’ tab to this page, and would it be duplicating data unnecessarily? In a way, it would move the developer page here as well, leaving only that which is controlled by the readme left on the readme. But then again, jumping between urls could be a mess. I don’t know. That’s why it’s a concept.

Also it should be easier for a developer to contact the plugin team when they have issues. And yes, the communication would be public, unless a comment is flagged as ‘security.’ Again, no code at all exists to make this a reality.

What’s Missing

There’s no contact form for a closed plugin. There should be. But this is really just concept art and starting to get an idea of what may work.

There’s also a dearth of data on the main dashboard page. That could lift from plugins like WP Dev Dashboard or WP Developers Homepage to fill in data. That’s the same general concept of what we’d want on the Support page (which you’ll notice is also left missing).

Misc. Thoughts

One of the stated goals we have is to allow everyone to leave a review on a plugin, with regards to the reviews before approval. In doing so, those reviews and all discussions about a plugin would need to be public. This is not necessarily a bad thing, though it will lead to some developers thinking long and hard about how they address issues in public. My concerns are that people who continually make the same error or neglect to fix something will be publicly embarrassed, but also that a free-for-all with reviews would lead to developers not wanting to host code here due to public backlash.

However, it’s been pointed out to me that coddling developers as much as we do may be causing them more harm in the long run. We do spend an inordinate amount of time hand-holding people who don’t want to take the time to read and think through a debugging process. Certainly we don’t mind helping out people who are brand new, or who aren’t native English speakers. But they’re vastly the minority of people who act the goat in our emails. And generally, they’re very respectful and nice.

Right now, my gut feeling is that there should still be a private way to talk about security issues.

But behavioural ones? They can be handled in public. It may stop people from some of the name-calling.

Last Updated On Nov 27/28 Without Updates? Don’t Panic!

This post was corrected at 1901 UTC

In the last 24 hours, a fair amount of plugins were “updated” even though no one pushed any code. At first we thought this to be due to a re-run of the string importer, but as it continued, Otto theorized it was actually due to the checksum generator.

If a plugin shows a ‘recent’ last update, even though no code changed, do not panic.

Nothing ‘bad’ has happened. We’re currently looking into a way to mitigate this and have a more accurate time show up, as SVN is unaffected.

In the last 24 hours, a fair amount of plugins were “updated” because of the strings importer having an issue. Those had to be rerun in order to get the strings pulled in to be translated properly. This had the adverse impact of causing the “Last Updated” value to change.

Which scared people. Sorry about that.

If you’re worried, check your SVN changelog. If nothing was updated, then it was just us 🙂

Of course, if someone you don’t remember giving access to did your last commit, please DO email us at plugins@wordpress.org right away and we’ll help you out.

One At A Time

As of last week, plugin uploads are restricted to one at a time.

That means if you have a plugin in the queue, be it submitted for review, in review, or pending your reply, you may not submit a second plugin. You have to finish your first one (or ask us to reject it) before you can move on.

This is not for the same reason that Themes does it. To whit, you’re not restricted to keep the queue low (ours is usually only a 3 to 7 day backlog anyway). You’re all being restricted because people aren’t finishing reviews, and it’s become a drain on resources.

We have over 700 reviews waiting on the developer to get back to us.

Now some of those are cases where people lost the email, or missed it somehow. Other people get the email and don’t know what to do or decide it’s too much work to fix all the things. And worse, some people decided that they’d get the review and never use the directory. In order to prevent this sort of abuse, and the disrespect to everyone else who actually finishes a review and uses the hosting we provide, everyone’s being restricted.

This should not be onerous. We have a tiny backlog. To the point that some people get rather rude when they don’t get a reply in 36 hours. And yes, that’s exactly as annoying as you think it is.

One review at a time. One plugin at a time. Please give us at least 5 business days to reply to emails.

By the way. If you’ve submitted a plugin within the last 7 days and haven’t gotten a reply, check your spam because I promise, we ended Friday with an empty queue.