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
Date: Wed, 20 Jul 2016 05:44:19 GMT
Last-Modified: Mon, 18 Jul 2016 07:14:38 GMT
Server: ECS (syd/EBEC)
X-nc: MISS lax 186
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.
Hi, for an upcoming update of GlotPress I need a new column
user_id_last_modified for the translations table.
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!
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:
The 502 errors do not happen on our sandboxes, only in production. Can someone please look into this? Thank you!
Could the following CDN URLs please be purged?
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 email@example.com 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.
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:
- Upgrade the PHP linting to PHP-latest-stable (7.0)
- 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
- Switch PHP linting to being a warning instead of a block
- 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.
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?
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.
@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?
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:
We have a handful of @wordpress.org 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 wordcamp.org (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 wordpress.org 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 wordpress.org 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 wordpress.org from the google account (if so, please explain).