Hello, can someone please change…

Hello, can someone please change the redirect for *.trac.wordpress.org/logout from https://wordpress.org/support/bb-login.php?action=logout to https://login.wordpress.org/logout? Thanks!

Meta ticket: #2029-meta

#prio3 #trac

There are no cache instructions…

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

$ curl -I https://s.w.org/images/core/emoji/2/svg/1f937.svg
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 translate.wordpress.org

Hi, for an upcoming update of GlotPress I need a new column user_id_last_modified for the translations table.
Background: https://github.com/GlotPress/GlotPress-WP/issues/293

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://*.wordpress.org/?fetch-custom-header=/plugins/ 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 translate.wordpress.org but couldn’t confirm them.

On April 13th I reported that the https://*.wordpress.org/?fetch-custom-header=/plugins/ 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  https://make.wordpress.org/polyglots/feed/p2.ajax returns a 502 which prevents adding new comments.


But there are also new reports for translate.wordpress.org (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?



#cdn, #emoji

Allowing WordCamp.org 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 city@wordcamp.org 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 WordCamp.org 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 wordpress.org certificate when accessing https://w.org.

Could you please switch it to the w.org certificate, so that the redirect to wordpress.org 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 wordpress.org/nightly-builds 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.