There are no cache instructions…

There are no cache instructions on SVGs on the CDN, could you please add some on?

$ curl -I
HTTP/1.1 200 OK
Accept-Ranges: bytes
Content-Type: image/svg+xml
Date: Wed, 20 Jul 2016 05:44:19 GMT
Last-Modified: Mon, 18 Jul 2016 07:14:38 GMT
Server: ECS (syd/EBEC)
X-Cache: HIT
X-Frame-Options: SAMEORIGIN
X-nc: MISS lax 186
Content-Length: 4618

The cache can be set to a long time without causing problems, I’m fine with a month or more.

Also, I’m not sure if it’s possible/desired to compress the data, but I imagine SVGs will compress moderately well.

New table column for

Hi, for an upcoming update of GlotPress I need a new column user_id_last_modified for the translations table.

The query:
ALTER TABLE translate_translations ADD COLUMN user_id_last_modified bigint(20) DEFAULT NULL;
Running this query on my local dump took 9 min 32.67 sec (35207550 rows affected).

@barry: Can you run the query on each server like you did for the index change? Thank you!

502 Bad Gateway errors

The number of reports for 502 Bad Gateway errors is increasing recently.

My first report for 502 errors was for https://* requests on Jan 7th. This was solved by @barry, “some memory corruption probably caused by a bug in pecl-memcache that we are working on fixing“.

Around April 3rd I got a few reports for but couldn’t confirm them.

On April 13th I reported that the https://* issue happens again. This issue is still there, see #dotorg-warnings.

Since this Monday we’re getting reports for 502 Bad Gateway errors on our make sites. For example returns a 502 which prevents adding new comments.


But there are also new reports for (when submitting translations) and for localized sites:

Image 2016-06-07 at 9.56.15 am

The 502 errors do not happen on our sandboxes, only in production. Can someone please look into this? Thank you!

Hi Systems Could the following CDN URLs please…

Hi Systems!

Could the following CDN URLs please be purged?×72/**


#cdn, #emoji

Allowing SMTP

The Community Team is discussing e-mail options for WordCamp organizing teams, and one of the potential solutions is to allow SMTP traffic from outside the network. If that was done, then the teams could send out mail from accounts, rather than having to setup a Gmail account that messages get forwarded to, and sending mail from that.

I don’t know why SMTP is currently blocked, though, so I wanted to find out if allowing that traffic is an option or not.

#email, #smtp, #wordcamp-org

Removing the PHP 5.4 plugin directory linting The…

Removing the PHP 5.4 plugin directory linting

The plugin directory has linting against PHP 5.4 for quite some time now. It used to be a feature to prevent accidental bad commits, but today it’s now regarded by many as a bug.

We need to do one or more of the following:

  1. Upgrade the PHP linting to PHP-latest-stable (7.0)
  2. Upgrade the PHP linting to PHP 5.6 with a plan to move to PHP 7.0 (latest stable) and keep up with future releases
  3. Switch PHP linting to being a warning instead of a block
  4. Remove the linting all together

Simply upgrading the linting to PHP 5.6 only kicks the can down the road, and still blocks people from using PHP 7 syntaxes in plugins (which is totally okay, if the plugin specifies that as a requirement).
Removing the linting seems like a bad idea, as I believe authors should still be notified they’re committing code that may not be compatible (Unfortunately we currently don’t do php fatal error prevention checks on plugin upgrades, so I’d like to retain it to prevent an unexpected WSOD).

So, I personally feel we should leave the linting at PHP 5.4 (which is what the majority of WordPress sites run today) and make it a warning, not a block.

In order to warn instead of outright blocking, the linting needs to be moved from the pre-commit hook to the post-commit hook and the script exiting with a error-level code, STDERR will then be sent to the client after the commit is made.

#plugins-svn, #svn

Hi We’re ready to start converting the second…

Hi! We’re ready to start converting the second batch of WordCamp domains to the correct URL structure. Can we install the certificate and the nginx config on the server please?

  • /home/wordcamp/letsencrypt/output/batch-2.crt
  • /home/wordcamp/letsencrypt/output/batch-2.key
  • /home/wordcamp/letsencrypt/output/batch-2.nginx.conf

The paths in the nginx config might need to be adjusted depending on where you put it. Also @barry mentioned we should probably use maps in the nginx configs for this, so I’ll be reworking the LE script a bit, maybe before the next batch.

Thank you!

#ssl, #wordcamp-org

@netweb noticed that we’re sending the wordpress org…

@netweb noticed that we’re sending the certificate when accessing

Could you please switch it to the certificate, so that the redirect to happens correctly?

Moving the NFS mounts

Per a conversation with @barry, we’re going to move most NFS mounts on .org to a single centralized location. Here’s the checklist, in order:

  • Prepare PHP scripts to use the new locations if things are mounted (r9244-dotorg and a few others).
  • Set up the new location in nginx for X-Accel-Redirect (r5733-deploy).
  • Deploy the wporg-web role and reload nginx, which contains the new location in nginx.
  • Commit and deploy my patch (uploaded to Slack room), which adds new mounts to fstab-nfs and initializes the directories in a migrations script.
  • Run my script included in the patch as a global command to initialize the directories, add the new mounts to fstab, and mount them.

After that:

  • I then need to commit some new Nginx location blocks for the old URLs pointing to the new NFS locations (in some cases, they were directly accessible, such as and some Rosetta stuff).
  • Those Nginx rules will then need to be deployed.
  • Remove and clean up after the old mounts once we verify everything works and nothing is using them. We’ll keep the uploads mount, but we’ll be able to remove everything else, including the BuddyPress and MU dl-archive mounts.

Email & Google Apps

We have a handful of email addresses set up as forwards. For the teams that need an official email address and a supportpress/supportflow setup, we have been doing addresses on (which has mailboxes) or setting up one-off gmail addresses to handle the mailbox, the owner of which might get lost over time. I talked to Barry at the team meetup days at WCSF about this and he said we should put on gmail for email. Matt said this was okay.

I’ve reclaimed the Foundation account for google apps for non-profits (a WC organizer had used the tax id to claim it without asking first, so we had to jump through some hoops). I’ve set up the account and gone through the steps with Ashish Shukla to have it recognize as the domain. The next step would be to modify the MX record to start routing email through the google apps account, but that gets complicated when it comes to ensuring no disruption to existing forwards, which is why Ashish and I were waiting for Barry to be available. When I spoke to Barry today, he said that @nacin is doing something around email too, so now he’s not super comfortable making changes at all lest we inadvertently step on each others’ toes.

@nacin: what is the thing you are doing with email, and does it preclude a shift to having actual mailboxes that are official? Let’s coordinate with whomever else is working on this to make sure everyone’s needs are met. I’m happy to share the google credentials with the appropriate people to get it going. We also get stuff like official hangouts the teams can use, calendar, etc. as part of the google apps account. If there’s a reason *not* to take Barry’s advice about using google apps/gmail for the team emails, I can remove from the google account (if so, please explain).

#email, #gmail