http://security.wordpress.org is just a redirect to https://make.wordpress.org/core/handbook/testing/reporting-security-vulnerabilities/, but loading https://security.wordpress.org fails to redirect because of an invalid certificate.
Right now I’m blind to any errors that occur with messages sent from the WordCamp.org web server. This week there was a Core bug that resulted in many (most?) messages being rejected by the receiving MTA, but I didn’t know for several days, until the reports started coming in from users and the Core bug was discovered.
I think two things would help resolve this, but I’m open to whatever suggestions you have.
1) Set the Envelope-FROM to email@example.com instead of firstname.lastname@example.org. I’ve already setup the address.
2) Grant read access to mail.* in the logs directory
There are no cache instructions on mp4s on the CDN, could you please add some on?
curl -I https://s.w.org/images/core/4.6/streamlined-updates.mp4 HTTP/1.1 200 OK Accept-Ranges: bytes Content-Type: video/mp4 Date: Tue, 16 Aug 2016 13:13:27 GMT Last-Modified: Tue, 16 Aug 2016 12:58:26 GMT Server: nginx X-Frame-Options: SAMEORIGIN X-nc: MISS lax 186 Content-Length: 225101
Looks like webm has them:
curl -I https://s.w.org/images/core/4.6/streamlined-updates.webm HTTP/1.1 200 OK Accept-Ranges: bytes Cache-Control: max-age=315360000 Content-Type: video/webm Date: Tue, 16 Aug 2016 13:14:11 GMT Expires: Thu, 31 Dec 2037 23:55:55 GMT Last-Modified: Tue, 16 Aug 2016 12:58:26 GMT Server: nginx X-Frame-Options: SAMEORIGIN X-nc: HIT lax 186 Content-Length: 449672
For 4.6 we don’t use ogv but 4.3 had one:
curl -I https://s.w.org/images/core/4.3/formatting.ogv HTTP/1.1 200 OK Accept-Ranges: bytes Content-Type: application/octet-stream Date: Tue, 16 Aug 2016 13:09:55 GMT Last-Modified: Wed, 29 Jul 2015 16:49:59 GMT Server: nginx X-Frame-Options: SAMEORIGIN X-nc: MISS lax 186 Content-Length: 1939540
The content type should probably be
Just a heads up that we’re planning to release a new major release today, August 16th at 19:00 UTC.
Hello, is it possible to svn up the
/home/wporg/public_html/ directory on all sandboxes?
There was a change in core to
WP_Site which got reverted later. A sandbox which still has the old
WP_Site will pollute the cache with a broken object which ends in a site_id = 0 entry in the database and making the site inaccessible.
See https://wordpress.slack.com/archives/core-multisite/p1467394608000460 for background.
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.
Hello! @adityakane is a new super deputy for the community team and he needs proxy access. His public key is:
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDJRKfcLQ4RmBTyw+z0gpVGkd6TEISbVoFYgBW//olFw78eyt1JjfmNQJBUmn2xpxzIjUjSOEHxSwXbqT4no1Rj+15ahEpfqeBwhobVAjXoVpuS8XY+prCno5mVI5cEJNF5uwUotLUi8W0ma7LX8Nnev7kKBvNEHJwWP+EPaanJezVjoIgmuK8dOwiejuHXdicF/Z/8tUqH3x+xo7Ljpj5etlVn9zN+yigL55eLv+RXPOH73EAb+jcBAKLLbUroWxqH/ak76fwfwN0Wm9RxWP1OqO2YjxOKDmbxLpoCBsfWFa0zc9Rl9Qce3fBYqapn1SNv6j3BdKx2hnNKb4FehSzV Aditya@Adityas-MacBook-Air.local
Please create a sandbox for @gibrown and give him commit to the meta repository. He will be assisting with Elasticsearch in the plugin directory. You can re-use his Automattic SSH key.
Since switching plugins.svn.wordpress.org linting to PHP7 it looks like the fatal error outputs are not including the actual error, only the fact an error occured. This causes a bit of confusion as some things are being blocked (correctly) with no obvious cause.
Sending plugin.php Transmitting file data .svn: E165001: Commit failed (details follow): svn: E165001: Commit blocked by pre-commit hook (exit code 1) with output: *********************************** PHP error in: test-plugin-3/trunk/plugin.php: Errors parsing test-plugin-3/trunk/plugin.php *********************************** svn: E165001: Your commit message was left in a temporary file: svn: E165001: '/home/www/tmp/sdf/svn-commit.tmp'
In that case, it should’ve included a message of
Fatal error: 'continue' not in the 'loop' or 'switch' context in plugin.php on line 20 (Note: This is one of the new PHP7 parse fatal errors)
This can be tested by attempting to commit to a plugin with a
continue; statement in global scope (for example, a file as
I can’t see the issue in the pre-commit script, but i assume the error is probably going to STDOUT rather than STDERR.