SVN Status: Seems to be Okay

I know Dion mentioned it in a comment, but here’s the official… We think it’s okay now post (I delayed to be more sure).

The SVN sync stuff SEEMS to be okay. The main issues appear to be sorted out, so 🤞🏾

We’re keeping a close eye on it, but please do remember to be nice to our poor system 🙂

#announcement

SVN Syncing Issues Continued

tl;dr – Yes we know, yes we’re working on it, no you don’t need to email.

I’m really sorry about this issue, but right now literally all I know is that the tool we use to automagically schedule everything that happens after you use SVN to bump your plugins is acting like a truculent child. It’s slow, it’s dragging it’s feet, and it’s taking WAY more than six hours (which is usually the outside norm for this stuff) to finish, if it does at all. It took 36 hours for one plugin, and even then some people got weird results.

And no, we don’t really know why yet.

It’s possible this is related to the new directory. It’s possible it’s from the entire .org slowdown last week or maybe it’s because we released the Beta and everything is slow from that. We literally don’t know.

I apologize for a series of very curt emails, but with the volume of people complaining, we had to resort to an auto-reply of, basically, we know, please be patient. If I have anything else to tell you, I will post, but right now we don’t know why and we can’t magically tell you what we don’t know, so please be patient with us.

Also no, there’s not a ticket because this is actually outside the meta repository. That means it’s not open source, the part that’s busted. The people with the access are aware and yes, I’ve pushed to escalate this. But it’s the weekend and it’s Mothers’ Day in the US, so you’re just going to have to be a little extra patient.

Repository Syncing Issues (Updated)

Update from Otto: “The brunt of the plugin-delay problem has been solved now, so plugins should be nice and speedy again. There may be a few stragglers that got rescheduled for later due to the overload, they will clear themselves up in the next couple hours.”

Due to a network issue in the wee hours of May 11, updates to SVN are taking longer than normal to show up on the directory. The issue created a 2 hour backlog, which normally would work itself out pretty quickly. It’s currently being exacerbated by everyone who sees their code NOT showing up right away and pushing it again.

As Otto says:

In short, when it’s being slow, then it’s being slow and nothing you can do will speed it up, so just relax, go outside, walk around, and wait for it.

Do we want to make the process faster? Of course. And if you’re interested in helping that, please check out Meta ticket #1578 to understand how it was all written for the new directory.

To remind you:

  • Changes can take a couple hours to display even on the good days. While it is generally much shorter, 6-12 hours is about when you should start wondering if something’s up, not before.
  • Multiple commits to SVN means multiple builds of your code. The more times you commit, the more builds, and the slower it goes for everyone. Commit once, then go make a sandwich.
  • Zips are built for for every tag’d release in your repository. Fewer tags, faster builds. We advocate removing older builds as they’re generally not necessary for use.
  • Patience, patience, patience. With over 60k plugins (counting the closed ones), this is a HUGE database of things.

#announcement

Server Load Woes

If you got an error like this when using SVN today, it’s not just you:

Committing transaction...:   Error: Commit failed (details follow):  Error: Error running context: The server unexpectedly closed the connection.  Completed!:

Or

Committing transaction...:   Error: Commit failed (details follow):  Error: Failed to start '/home/svn/repos/wp-plugins/hooks/pre-commit' hook  

There was a high server load on WordPress.org on Monday May 8th, which caused the system to have those errors. When it happens to you, just go make a coffee or bake a pie and come back in a bit.

#downtime, #server-load

2016 in Review

It’s May. I forgot to post this. Go on and laugh 🙂

Anyway. At the end of last year, I looked at all the posts on Make/Updates and manually crafted out a spreadsheet that listed all the plugins submissions, rejections, approvals and closures. And here’s how the year looked:

image

If you don’t want to calculate it all yourself, I’ve made my Google sheet sharable. I didn’t go back and do 2015, and while I do plan to do one for 2017, we will have a big gap in numbers as I don’t have a way to calculate closed plugins at the moment.

By the way, there was a higher number of closed plugins in 2016 than ever before. That’s because more people than ever have asked us to close plugins, but also because we closed plugins without a committer with a valid email address. And that was a lot of people.

#announcement

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