Reminder: Google Hates Widget Links

In a blog post last year, Google reminded users that widgets are cool, but widget links are the suxxor.

Widgets can help website owners enrich the experience of their site and engage users. However, some widgets add links to a site that a webmaster did not editorially place and contain anchor text that the webmaster does not control. Because these links are not naturally placed, they’re considered a violation of Google Webmaster Guidelines.

If you look at the examples, they highlight things that many plugin (and theme) developers would consider acceptable links.

What does this mean for you? It means your powered-by link may adversely impact your users. Be smart. Make your links no-follow.

Also as a reminder: Any and all powered-by links and credits must be opt-in. That is a site owner must make the conscious and informed decision to display your credits. You cannot have them show by default, you cannot have them be opt-out, and you cannot hide them in display:none code or any other way that embeds a clickable link. Code comments like <!-- Powered by WordPress --> is fine.

Submitted a Plugin? Please Check Your Emails!

Currently ~30% of all new plugins are approved within 7 days of submission.

Why so low? People don’t reply to their emails. We have over 100 plugins waiting on replies from developers. At this precise moment (10:30 am US Pacific Time, Sunday April 16) there are ZERO plugins pending review. That means everyone who submitted a plugin between April 1 and today has been emailed.

If you didn’t get the email, please go check your spam. Free email clients like Hotmail, Yahoo, and Google tend to file us as ‘automated’ emails, which is not true, but whatever. Put plugins@wordpress.org in your whitelist (actually put @wordpress.org in a filter to have it never treated as spam and always important) because if you’re not getting emails from WP and you’ve submitted a plugin or a theme, you’re going to have a bad time.

Again. Everyone’s been emailed. I promise. Check your emails. Drop us a line if you can’t find it. Remember to whitelist us.

#reminder

Plugin Submissions Open

It took a little longer than expected or desired, due to a couple serious issues. Not everything is perfect yet, but submissions are open.

Some things are different. Most are the same.

Zips are required (not links)

Instead of a link, you will now upload your zip directly. In doing so, the plugin slug will be assigned for you. If your zip isn’t valid, if your plugin headers aren’t valid, you’ll get an error message. Read it carefully. If you get a message that says your plugin URL and Author URL can’t be the same, that’s exactly what it means.

* Plugin URI: https://example.com/plugin
* Author URI: https://example.com/

Those have to be different.

Slugs are determined from plugin headers

That’s right, the name you get is based on your Plugin Headers. That means this:

* Plugin Name: My Cool Plugin

That will give you a plugin slug of my-cool-plugin and that will get you an email from us telling you not to use “Plugin” in your URL, and is “my-cool” okay? Please do read the emails and reply properly. If it’s a simple typo, we’ll just fix it for you. If we’re not sure what’s best, we’ll email.

No more 7-day rejections

Since the new and pending queues are now split, we won’t be rejecting plugins after seven days. If you don’t reply to the email, your plugin just sits there and waits for you. But the good news here is that you can’t resubmit. You’ll get a warning message that the plugin already exists.

Release and iterate

All of this is going to be iterated on and improved. We have goals to make the add page list everything you have pending, for example, and we’ll be implementing a limit of how many plugins you can upload at once to prevent things like one person submitting ten at once. Since our queue is rarely more than a week, that’s no hardship.

I’m primarily concentrating on making the back-end of the directory work better and documenting the process so we can get down to the business of expanding the team. Divide and conquer as they say.

What about new reviewers?

Soon! This year! Hopefully by summer. My modest goals are as follows:

  1. Get all the current reviewers up to speed
  2. Invite a couple select people to join as guinea pigs
  3. Train them up good and work out the kinks in that
  4. Post an open call for new members
  5. Accept some and train them
  6. Go back to step 4

By limiting how many new members we take at a time, we can release and iterate our training methods and documentation faster.

As always, remember to whitelist the plugins@wordpress.org email address and follow this blog for updates.

Thank you for your patience!

Reminder: How SVN on WordPress.org Works

Now that the new directory is out, it’s time for a couple quick reminders on how the SVN repositories work on WordPress. We have documentation on how SVN works here, but the information can be overwhelming.

Use readme.txt (not .MD)

A readme.md file is not the same as our readme.txt format. If you try to use one and expect everything to work right, you’ll have a bad day.

Your Stable Tag matters

This has always been the case, but it’s now more important than ever. If you say that your plugin’s stable tag is 1.2.3 but you do not have a /tags/1.2.3/ folder, your plugin will absolutely not behave as expected. If you’re not using tags folders, your stable tag should be trunk and that’s it. (But we would rather you use tags.)

Don’t use a folder for your MAIN files

Do not put your main plugin file in a subfolder of trunk, like /trunk/my-plugin/my-plugin.php as that will break downloads. You may use subfolders for included files.

The Assets folder is special

We have a dedicated folder for your plugin screenshots and banners. Want a faster, smaller, plugin? Put your assets in /assets/ and not /trunk/assets/ please. Your users will thank you. Screenshots and banner images go in that folder. It’s special. Use it wisely.

SVN is a release repository

One of the guidelines is that frequent commits to your plugin should be avoided.

Unlike Git, our SVN repository is a release repository, not a development one.  Every single commit triggers a regeneration of the zip files associated with the plugin. All the zips. That can be pretty brutal on the system. No one likes it when a plugin download breaks because the server’s down. Please be nice to our servers.

It’s okay to update your readme within reason

That said, if you need to update your readme to fix a critical public typo, do it. And if you want to update the readme to bump the version of WordPress you’ve tested up to, that’s fine too. Just keep it to the major releases. A plugin that is tested on 4.7 will show as tested up to 4.7.2 as well, after all.

 

Plugin Submissions ETA Reopening Early Next Week

really want to say “We’ll reopen on Monday!” but right now we’re aiming for Monday.

What’s going on?

We found some bugs that didn’t happen in testing.

For example, when we did the final import of all the pending plugins, they were in a maybe-wrong state. That meant we had to go through all our emails and logs to make sure we’d emailed everyone about their plugin status or not. That took us until Friday afternoon.

At the same time, we found some process flow bugs that were just going to make things worse all around and had to address those. It doesn’t do you any good to submit a plugin if we can’t review it, or if approvals don’t generate your SVN folder, for example! We had to document all of those to make sure things would get fixed in the right order (some of them we can live with, obviously).

The good news is that we did clean out the queue, so everyone who had a submission pending has now been emailed. Some of you twice. Sorry about that. If you didn’t get one and you think your plugin is pending, email us at plugins@wordpress.org and we can look.

Thank You Systems/Meta

Systems and Meta have been wonderful, plowing through the tickets raised. Right now, we’re prioritizing “Fix what’s broken” so the only tickets you see in the Plugin Directory v 3.0 milestone are items we feel must be fixed as soon as possible. If I’ve moved your ticket out, it’s simply because it’s not deemed mission critical at this moment, and not that it will never be addressed. It’s triage, and we were just as brutal about it on ourselves.

Thank You Too

I really do appreciate everyones patience and understanding.

Obviously things didn’t go perfectly, but considering the magnitude of this change, it’s gone smoother than I predicted (I may owe people dinner now). If you want to help us out, right now please spread the word to your fellow developers. Remember, if you can get everyone to read this blog first before they email/dm/ping for status, you make reviews go faster!

#directory, #repository

The New Directory Is (Mostly) Live

Sorry about the post-facto notice, there were a lot of moving parts and we got some things out of order when communicating between the multiple teams.

Current Status

  • Pending plugins are imported
  • Approved (but not yet committed) plugins are being imported
  • Rejected plugins have not yet been imported (though they will be … all 23k of them)

Known Issues

Beside everything listed on Meta Trac, we are aware of the following issues:

  • Header images are pixelated
  • Plugin submissions are disabled

Plugin Submissions are Currently Closed

THERE ARE NO PLUGIN APPROVALS GOING ON AT THIS TIME

You can’t submit a new one for approval, and we won’t be approving anything until possibly tomorrow at the earliest.

I will post here (make/plugins) as soon as we reopen and start things moving along, but please don’t ask for a status update. If it’s not posted here, we don’t have one, and you’ll just make everything take longer.

Plugins Will No Longer Be Rejected After Seven Days

Before you panic, we’re not going to reject plugins after 7 days anymore. The queue will be handled differently so having old plugins with no replies is less of a problem. Also? We’ll be able to rename your plugin slug before approval, so that will take care of most things like `google-analytics-by-faro` 😁 and other obvious typos.

However. This means the onus is now even more on you to make sure you whitelist emails from `wordpress.org` in your email servers. A high volume of people never see the first email (the ‘please fix’) and only see the followup of 7-days, so now you won’t be getting that anymore.

#announcement

Clarification of Guideline 8 – Executable Code and Installs

Since Jetpack announced it installs themes, a number of people have asked if this is a violation of the 8th guideline:

The plugin may not send executable code via third-party systems.

And in specific, these two items:

  • Serving updates or otherwise installing plugins, themes, or add-ons from servers other than WordPress.org’s
  • Installing premium versions of the same plugin

The short answer is no, it’s not, and yes, you could do this too.

The longer answer involves understanding the intent of this guideline, which initially was to prevent nefarious developers from using your installs as a botnet. In addition, it’s used to disallow plugins that exist only to install products from other locations, without actually being of use themselves (ie. marketplace only plugins). Finally it’s there to prevent someone silly from making a plugin that installs a collection of ‘cool plugins’ they found from GitHub and want to make easier to install. Which actually did happen once.

Plugins are expected to do ‘something’ to your site. A plugin that exists only to check a license and install a product, while incredibly useful, is not something we currently allow as a standalone product. This is why we allow plugins to have the in-situ code for updates that is used by their add-on plugins. The plugin we host has to use WordPress.org to update itself.

In addition, we do permit valid services to perform actions of installations onto sites, and have for a very long time. ManageWP, for example, has had this ability for quite a while. It provides a valid service, letting you manage multiple sites from their dashboard, and yes, install and update plugins. Going back to the example of a plugin that hosts the update code for it’s addons, the ‘service’ is the license you bought for the add-on plugin.

The trick here, and this is what is about to sound like hair splitting, is that it’s not the plugin UI on your site that does the install. In order for Manage WP and Jetpack to work, you have to go to your panel on their sites and install the items. If you wanted to make, say, my.servicename.com and let people log in, authenticate their sites, and from that interface use a JSON API to trigger an install, you absolutely, 100%, totally can.

To hit the major talking points:

  • Is Jetpack allowed to do this? Yes.
  • Are you allowed to do this? Yes.
  • Can you have your plugin install things? No.
  • Can your service install things onto a connected site? Yes.
  • Are you allowed to have a marketplace plugin? Not at this time.

I know this is frustrating to a lot of people. The reason it never came up before is no one asked us, and it isn’t our place to run your business or invent all the cool things. The guidelines are guidelines, and not laws or rules, to allow people to interpret them, and you’re always welcome to ask us if something’s okay or not. Or warn us if you’re about to do something you think might get the masses up in a dander.

#guidelines

Beware Your Zips!

Its not you, it’s Google.

A lot of people have been mentioning that Gmail won’t send emails if they have zips. Other people have no problem. And reading the list of filetypes that are blocked, it took me a while to figure out what was going on. Not only does Gmail block bad attachments, they also check in your zips to see what files are there:

Certain file types (listed below), including their compressed form (like .gz or .bz2 files) or when found within archives (like .zip or .tgz files)

And guess what filetype Gmail just added on as a banned attachment? `.js` files. Explains perfectly why some of you had no problem and others have massive ones, right? Right.

My advice is, and has been for quite a while now, to use GitHub or Gitlab or Bitbucket or some sort of true development version control system. They all generate their own zips and you can just link us to them. Plus if it’s really complicated to explain what’s wrong, we can highlight the code for you.

I strongly recommend you NOT use free download sources like mega file and all those other ones, especially if they offer faster downloads for money. The majority come with scam popups, viruses, and x-rated ads. Of which I have seen enough. Dropbox is free and has public links. Plus you all have your own websites and can upload a zip there if needed.

#notice

Plugin Guideline Change

With the advent of the new directory being on the horizon, which allows us to easily hard-limit the number of plugin tags displayed, we have taken the time to change the guidelines.

While minor updates to the guidelines (with regard to spelling, grammar, etc) are common, major changes are rare and we are striving to be more transparent about them. Hence this post 🙂

Guideline 12 (readme links) clarified to cover spam and tags.

The guideline now reads as follows:

12. Public facing pages on WordPress.org (readmes) may not spam.

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.

Links to directly required products, such as themes or other plugins required for the plugin’s use, are permitted within moderation. Similarly, related products may be used in tags but not competitors. If a plugin is a WooCommerce extension, it may use the tag ‘woocommerce.’ However if the plugin is an alternative to Akismet, it may not use that term as a tag. Repetitive use of a tag or specific term is considered to be keyword stuffing, and is not permitted.

Write your readmes for people, not bots.

In all cases, affiliate links must be disclosed and must directly link to the affiliate service, not a redirect or cloaked URL.

The previous version had the title of “… may not contain “sponsored” or “affiliate” links or third party advertisements” which was too specific and yet not direct enough as to what the intent was. We sincerely mean “Do not use your readme to spam.” Tag abuse, keyword stuffing, and blackhat SEO practices are all spamming.

While we still ask you to use no more than 12 tags, once we move to the new directory, we will simply not display the overage. You should clean that up now. The code is such that there will not be a way to grant exceptions. This is by intent. You don’t need 30 tags, folks.

Guideline 13 (formerly number of tags) now references using included libraries

Since we no longer needed a separate guideline for tags, we have completely changed this guideline to address an issue of security.

13. The plugin should make use of WordPress’ default libraries.

WordPress includes a number of useful libraries, such as jQuery, Atom Lib, SimplePie, PHPMailer, PHPass, and more. For security and stability reasons, plugins may not include those libraries in their own code, but instead must use the versions of those libraries packaged with WordPress.

For a list of all javascript libraries included in WordPress, please review Default Scripts Included and Registered by WordPress.

This issue has become incredibly important when you consider that roughly 90 plugins had to be contacted and closed regarding the use of PHPMailer. They had included the entire library and not kept it updated. I’m aware that we use a forked version of that specific library and I have raised core trac ticket #39714 to address this issue.

While we do not (yet) have a public page to list all 3rd party libraries, I’ve raised meta trac ticket #2431 to hopefully get this sanely documented.

#guidelines

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