Remove cookie-stripping behaviour from Trac Ticket caching

As per previous discussions, can we please remove the Trac Caching that strips the Set-Cookie headers from Trac ticket pages?

As mentioned, this causes failures to comment on tickets – https://meta.trac.wordpress.org/ticket/4360

As discussed, you’ll find a hacky Trac plugin that attempts to avoid setting useless Trac cookies in https://wordpress.slack.com/archives/G02QCEMRY/p1554790742034300?thread_ts=1554340318.022800&cid=G02QCEMRY but it’s mostly untested and may not work as needed.

The Latest trac plugin is in https://gist.github.com/dd32/e1a6e434cb9b5721cc086e51751f8c44 and has been tested well on a standalone trac installation.
The plugin does several things:
– Prevents Cookies being sent on anonymous pageviews
– Prevents anonymous sessions being saved to the DB (as there’s no such thing anymore)
– Blocks access to /prefs for anonymous users
– Expires all trac_* cookies after the user is no longer authenticated, such as to remove the trac_form_token cookie.

#trac #prio1

Hi! As per a discussion…

Hi! As per a discussion with @andreamiddleton can myself and @tellyworth please have the WordCamp role applied to our sandboxes?

This is to aid in support for WordCamp Europe this year if any unexpected things come up, and ongoing work we do that crosses over into that area.

#prio1

Change plugins.svn linting to PHP 7.current please

As a follow up to https://make.wordpress.org/systems/2018/03/12/change-all-svn-php-linting-to-php7/ and https://meta.trac.wordpress.org/ticket/3791 can we please switch the PHP linting for plugins.svn to 7.2 and keep it up-to-date with newer PHP branches as they’re deployed for WordPress.org?

Although this is specifically for plugins.svn, the same should be applicable to all SVNs now, as any which require an older PHP version will be enforced through Travis and other tools.

Having the linter exclude newer syntax is becoming a limitation for plugin developers and with the work being done around plugins specifying minimum PHP versions, and increasing the WordPress minimum versions, is going to result in more plugins requiring PHP 7.1/7.2/etc.

#prio1

Hi! Can we please add…

Hi! Can we please add the ms-files.php rewrite required for uploaded media on wordpress.org/support/?

The following rule should fit into the existing location /support/ block:
rewrite ^/support/files/(.+) /wp-includes/ms-files.php?file=$1 last;

Example URI which should work after the rule is added: https://wordpress.org/support/files/2018/10/WordPress-logotype-wmark-3.png

#prio1

Could you please grant @ocean90…

Could you please grant @ocean90 access to release packaging? He already has MC access.
The change was okay’d by @matt.

#prio1

Analytics access

Hi there, could @dd32 (in case he doesn’t have it), @tellyworth, and I be granted Google Analytics access to the wordpress.org group again? It’s currently blocking us from testing #1017-meta and moving forward with SEO work for the growth council. Thanks!

#prio1

#1017-meta

Upgrade Node/NPM on Build Server

Could Node please be upgraded to the latest LTS version (8.11.2), and NPM upgrade to 6.1.0?

#prio1

Transferring wp-cli.org DNS to WordPress.org

I’d like to shut down the CloudFlare account I created for wp-cli.org. Can we have WordPress.org host DNS instead?

Notably, before the switch is made, these redirect rules would need to be replicated in some way:

#prio1

Please install `make` & required dependancies on sandboxes

It seems that some node modules need to compile various things, particularly libsass.

To reproduce:
cd wp-content/themes/pub/wporg
npm install

If you need the raw log output, you’ll find those in ~/.npm/_logs on my sandbox.

At least pub/wporg, pub/wporg-main, and pub/wporg-plugins currently have the same issue.

#prio1

WordCamp Let’s Encrypt Script Broken

We received warnings from Let’s Encrypt that many of the WordCamp.org certs have not been renewed, and will invalidate on March 25th.

I’m guessing there are some necessary things that didn’t get transfered from LAX to ORD.

There may be some details in the letsencrypt-update.log, but I don’t have access to that on production anymore.

I tried setting up a test environment on my sandbox, but couldn’t because pip isn’t available. That may be the problem on production as well, but I can’t test any further until it’s on our sandboxes.

@barry, can you please take a look as soon as you have time? Let me know if there’s anything I can do on my end.

#prio1