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

Reminder: Make Sure Your Email Is Up To Date

I know the 4.7 ‘please test’ email went out a bit late (WordCamp US, blame Wapuu), but we did send it and just like last time, we’ve taken action the replies.

  • If you reply and ask for a plugin to be closed, we close it.
  • If your email auto-replies, we warn you once. If you were warned previously, we close your plugin(s).
  • If your email bounces we close your plugin or, if there are multiple developers involved, remove your account and notify them.

These actions are taken for security. If we have no way of getting in touch with you, or if your email is invalid, it puts your users at risk. Not to mention getting 2500 auto-replies is pretty frustrating.

Remember, it is a requirement that we be able to contact you. We don’t mind if the email is a group mail, but it should never auto-reply to anything from WordPress.org. Just whitelist us (and yes, you can do that with ZenDesk read this ticket for details) and make sure nothing from .org gets a bounce reply. This will also make our servers faster, which I know you’d like.

If you can’t do that, you’ll need to change your email to something else. Do to that, go to https://wordpress.org/support/users/YOURID/edit/ as the user in question and edit the email. Done.

On a happier note, less than 100 people had to be contacted this time around! It only took me 2 hours to sort it out, versus last time which was much higher. The majority of the issues came from new plugin developers, which is understandable, but a few of the long-standing devs had a rude awakening this morning, I’m sure.

Thank you everyone for understanding.

#notice #policy

Reviewer Handbook

Sneaking this in just before WordCamp US, if you’ve seen the redesign of this make site, then you may have seen the link to the handbook.

This is a rough draft – it’s not perfect and it doesn’t cover all contingencies. However, yes, that is indeed our handbook. It’s built to the new directory, which we’re not fully using yet, and it has some information that may surprise you. For example, did you know we could see every IP address you’ve ever used to submit a plugin?

On Contributor Day, I’ll be asking victims– volunteers to help with it, to explain things more clearly, and to make this something that can be used to (eventually) include more reviewers.

Speaking of, before you ask for the status, here it is: Not yet.

Once the new directory is live, and once the existing reviewers have worked out the best flow, then we will bring in some existing developers to join us. But it’s not going to suddenly be a flood gate. We’re trying to avoid hitting a backlog as bad as the theme team has, and I’ve been closely watching how they handle reviews and trying to see what we can do to navigate that kind of a delay. Obviously ‘more reviewers!’ isn’t the only answer, and right now I feel that the right fix for plugins is a more streamlined system. I have a plan. I’m sure it won’t last the first day against the enemy (i.e. plugins).

See you all soon at WordCamp US!

#notice #handbook

When emailing zips please make sure your email…

When emailing zips, please make sure your email client and email service provider allow this.

Increasingly, we have seen people testifying that they emailed us a file with a zip, but we never receive it. In doing some research, we’ve found that mail providers are now silent-killing large emails! While the settings can be overwritten, please keep this in mind when you email people your zips.

If you have the ability to check your mail logs, you may be rudely surprised. I know I was.

#email, #notice

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

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 release 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

There’s a Revamp Coming

We’re overhauling and upgrading the repo. Interested? You can harass @obenland and team about it:

Plugin Directory v3

See you there

#notice, #repository