Hi, can you please setup proxy access for @kimhustad? She’ll be helping out with bookkeeping and will need access to the WordCamp.org budgeting tools.
Her public key is:
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCY5whCd2F7ZDsomK6yFJO4hlGo3iqxVJM/k2MVP31oXlusv2/KVFAtkawNKLaGk6SsSst2UZTTxJF76w4gQJiDSVlGZk54E5p+VR3jIv5api4LqbYwL7ibb12aaaq1a9l1qrW0faMIdJGZNXjpncPnjGSBbGM+gXXpV91s1LC/BzkL2dbog1AzwVW5aoplWJAj473klpSPzTnHK+/KAHYHmLN/v5P3XdRuC7LzdWSphaT7L413pe+BrjHSxlgZWHbFscMyv2VAjNwE6e3XJqwhC6XVz/IOtkmTQK/gqWgxA4W8nIW3FjmVmW4VbSEOH41FRergEJlH6K4SfC3ir2+9 automatticaccounting@Automattics-MacBook-Pro.local
Hello, can someone please change the redirect for *.trac.wordpress.org/logout from
Meta ticket: #2029-meta
I’d like to get some form of network-layer caching of GET requests to
*.wordcamp.org/wp-json/tagregator/*. Cached responses would need to expire after 30 seconds.
This is part of the solution to the problem we ran into at WCUS last year. Is that possible?
I’d also like to run a stress test to make sure we can handle the expected traffic for this year. Are you able to assist with that?
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.