Reviewing the Guidelines – 2017

I do this regularly, but recently I received a comment that the guidelines were still too vague.

I need to stress that this is by intent. If we make guidelines like “You can only have 3 external links” then people will find ways to exploit that. However I do not think that guidelines are perfect. Which is why I’m proposing a minor update to them to address the following concerns:

  • Overall tense of guidelines made consistent
  • Update introduction for readability and unpack what we mean by keeping email updated
  • Explain the converse of 3
  • Put the important part of 5 on top
  • Add link to forum guidelines to 9
  • Add prohibition against harassment to anyone in WP
  • Clarify self-dismissible alerts are acceptable in 11
  • Changed tense of 12 and 13 to emphasize their importance
  • Grammar fix for title of 15
  • Fix reference to zips in 16 (upload now vs link to)
  • Reword title of 17 to explain that PLUGINS must honor…
  • Guideline 18 has received a full rewrite to clarify what rights we reserve and reiterate our promise to do this as fairly as possible.

You can see all the changes proposed here on GitHub

Please read the guidelines and leave comments or pull requests on Github. The plan is to make these live in January 2018 so please jump in and help! Thanks.

#announcement, #guidelines

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.

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.

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.

Reminder: Research Before You Sell Out

Are you thinking of selling your plugin? Did someone offer you money to put a link to their sites in your readme or wp-admin settings page?

STOP. THINK. BE CAUTIOUS.

I’m sure most of you are aware of the recent bad behaviour that’s gone on with regards to unscrupulous people purchasing plugins and using them to leverage malware, spam, and backdoors. While we would never tell you that it’s wrong to sell the plugins (they’re yours after all), we do want to help you recognize the warning signs of a bad-faith purchase.

Above all, if anything in the process makes you nervous and feel like something is wrong, call the deal off. You can email us at plugins@wordpress.org and we can help vet the buyer for you.

But remember this: The primary reason people want to buy ‘popular’ plugins is to use it to spam.

Signs To Watch Out For

Here are some basic red-flags:

  • You get an unsolicited email that reads like a generic form
  • The offer includes different prices based on how many people use the plugin (i.e. $500 for every 1000 users)
  • The amount offered seems to be rather high ($50,000 USD for a plugin)
  • The offer comes from a company who claims to be purchasing a ‘suite’ or ‘collection’ of plugins
  • They want you to sign an NDA, and not talk about the purchase
  • They don’t offer to show you an improvement of the code right away
  • They have (or plan to have) a special domain and user account just for this plugin
  • They have a brand new (less than a year old) account on WordPress.org with no other plugins
  • They have no visible, active participation in the WordPress community (forums, plugins, themes, WordCamps, etc)

Do Your Homework

When people come to us asking to adopt plugins, we vet them. We look at the code first. If there’s no new version of the code, with fixes, we don’t even consider it. If the prospective buyer of your plugin can’t show you how they’ll update it, don’t do it. Period.

No matter what you must do the work to vet these people. Ask them serious questions. How do they plan to handle support and reviews? How familiar are they with the directory guidelines? Do they already know how to use SVN? How will they take care of your existing users?

Review their code. Sit down and look over every single line of code and make sure it’s safe and well written. If you see base64 and it’s not for images, tell them no. If you see them phoning home, tell them no. If you see them doing things in an insecure way, tell them no.

At the end of the day, what they do is going to reflect on YOU, and your reputation could suffer.

Many times, good developers find their names dragged through the mud when a plugin they own is purchased by people who do horrible things with their code. Make absolutely certain, beyond shadow of a doubt, that they understand what owning the plugin means, and that they must abide by all the plugin and forum guidelines.

Worst Case Scenario

If we find out you sold your plugin to someone who does evil with it, the odds are you won’t get that plugin back. Among other reasons, you sold it. To have you take someone’s money for the access, and then give it back to you, would be tantamount to theft. At the very least, it would be a bad-faith action on our part. Once you sell a plugin, accept the money, and your access is removed, that’s it. You’ve indicated you’re done with it, and we will enforce that.

This means if evil is done and we need to fix the plugin, we’ll roll it back to a safe version, remove everyone’s access, and disable the plugin permanently. That will it will push a final update, but no one new can install it. We feel that once a plugin has been sold and used like that, it’s near impossible to recover any reputation, and it’s better for the community to walk away.

Should You Sell Your Plugins?

The directory was never intended to be a sales marketplace, and it’s unlikely it will ever be one. If your deepest wish is to make a super popular plugin and sell it for gobs of money, this is probably not the place for you. Selling your plugin is a chancy business, and it’s hard to make money legitimately on a free plugin. After all, they can legally just fork it and make a new one.

You certainly can sell your plugins, but sell it smartly. At the end of the day, it may be better to retire a plugin than sell it or give it away to someone you’re not sure will do good.

#notice, #warning

Is your filter going to break the layout?

If you’re not clear about the difference between WordPress actions and filters, you may end up breaking the page layout of WordPress – maybe days, months, or even years after you’ve written and implemented a new filter hook.

The difference can be difficult for new developers to grasp – after all, hooking an action or filter runs your code, either way, right? Well, yes, it does, but filters can be executed several times, in different locations as the webpage is being built (header, body, footer, etc.), and even in the admin back-end. More importantly, filters do not send anything to the webpage! Filter hooks receive their data / text as an argument, and then “return” the modified (or original) data / text at the end. They do not use “echo”, “print”, “printf”, etc. – they should not send anything to the webpage. If you need to output something directly to the webpage, use an action – that’s what they’re for.

Continue reading

#action, #doingitwrong, #filter, #hook, #output

SWFUpload To Be Removed From Core

Removing SWFUpload

If your plugin is using SWFUpload, please remove it and switch to Plupload. If you’re a security plugin scanning for it, you’re fine. If your plugin is using it, or including your own, it’s time to upgrade.

#announcement

Plugin Support Reps

Some of the larger plugin shops have a support team to help out on the forums. It would be useful to be able to give those people a special “support rep” role on the forums so they could be recognized as such.

Support representatives can mark forum topics as resolved or sticky (same as plugin authors and contributors), but don’t have commit access to the plugin.

The UI for managing plugin support reps can be found in Advanced View on the plugin page, next to managing committers:

Screenshot of the UI for managing support reps

Once someone is added as a support rep, they will get a Plugin Support badge when replying to the plugin support topics or reviews:

Screenshot of Plugin Support badge on the forums

Hello everyone, some of you…

Hello everyone, some of you will have the following email in your inbox:

Your password on WordPress.org has been deactivated, and you need to reset it to log in again.

We recently discovered your login credentials in a list of compromised emails and passwords published by a group of security researchers. This list was not generated as the result of any exploit on WordPress.org, but rather someone gaining access to the email & password combination you also used on another service.

To reset your password and get access to your account, please follow these steps:
1. Go to login.wordpress.org
2. Click on the link “Lost your password?”
3. Enter your WordPress.org username:
4. Click the “Get New Password” button

It is very important that your password be unique. Using the same password on different web sites increases the risk of your account being hacked.

If you have any further questions or trouble resetting your password, please reply to this message to get help from our support team. We will never ask you to supply your account password via email.

At this point we don’t have a reason to believe any accounts have been compromised, but out of an abundance of caution passwords are proactively disabled just to make sure.

If you have any questions don’t hesitate to post them in the comments.

[EDIT]: Updated the list typo to now go in order.

[EDIT]: Comments are closed. Reply to the email folks.

Minimum PHP Version Requirement

Not all plugins can work on PHP 5.2, like WordPress core currently does. Not all plugin developers want to support PHP 5.2, like core does. As a project, WordPress would like to move forward and encourage people to use more recent PHP versions.

As one of the first steps to reach that goal, plugin authors can now specify a minimum required PHP version for their plugin in readme.txt file with a new Requires PHP header:


=== Plugin Name ===
Contributors: (this should be a list of wordpress.org userid's)
Donate link: http://example.com/
Tags: comments, spam
Requires at least: 4.6
Tested up to: 4.8
Requires PHP: 5.6
Stable tag: 4.3
License: GPLv2 or later
License URI: https://www.gnu.org/licenses/gpl-2.0.html

Users will see this displayed in the plugin directory, like this:

Screenshot of the Requires PHP Version line on plugin page

As a next step, the WordPress core team is going look into showing users a notice that they cannot install a certain plugin or theme because their install does not meet the required criteria, with some user-oriented and host-specific instructions on how to switch their site to a newer PHP version.

If you have any feedback on the subject, please leave a comment or join the next PHP meeting in #core-php channel on Slack.