Symlink for new template file on meta.trac

[4621] adds a new template file for meta.trac.wordpress.org which, according to @nacin, needs to be symlinked.

Could someone do that please? Thanks!

#prio3

Kathryn Presner has notified us…

Kathryn Presner has notified us that she is not receiving some emails from Themes Trac. I’ve been investigating this issue and found that the emails do get sent out, but they are sometimes broken – they are sometimes missing the ‘To’ header.
I’ve tried to find the root cause of this, but with no luck. Our trac install has plenty of custom modules, and a few local patches. One of them does modify the notification.py file, but i couldn’t locate any code that could cause this issue.
I’ve looked through the themes mailbox for automattic user, and found around ~1100 emails since 2014 that did not contain the To header (and were from themes trac), which is quite a big number as there’s not that many emails coming from themes trac.

Can somebody who has worked with customising / writing patches for wporg Trac have a look at this issue? I know @nacin did some, not sure who else.

An example comment for which the To header was missing is this one. I can find more if needed.

Example raw content of a broken email:

Return-Path: <noreply@wordpress.org>
X-Original-To: themes@automattic.com
Delivered-To: themes@automattic.com
Received: from localhost (localhost.localdomain [127.0.0.1])
        by smtp1.lax.automattic.com (Postfix) with ESMTP id 4D01C16C605A;
        Tue,  3 Jan 2017 20:25:43 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at wordpress.com
X-Spam-Flag: NO
X-Spam-Score: 0.072
X-Spam-Level:
X-Spam-Status: No, score=0.072 tagged_above=-999 required=5
        tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
        DKIM_VALID_AU=-0.1, MISSING_HEADERS=1.021,
        REPLYTO_WITHOUT_TO_CC=1.552, RP_MATCHES_RCVD=-0.5, SPF_PASS=-0.001]
        autolearn=no
Authentication-Results: smtp1.lax.automattic.com (amavisd-new);
        dkim=pass (1024-bit key) header.d=wordpress.org;
        domainkeys=pass (1024-bit key) header.from=noreply@wordpress.org
        header.d=wordpress.org
Received: from smtp1.lax.automattic.com ([127.0.0.1])
        by localhost (smtp1.lax.automattic.com [127.0.0.1]) (amavisd-new, port 10024)
        with ESMTP id mji5gHMhfkVq; Tue,  3 Jan 2017 20:25:42 +0000 (UTC)
Received: from mail.wordpress.org (lb2.lax.wordpress.org [66.155.40.19])
        (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
        (No client certificate requested)
        by smtp1.lax.automattic.com (Postfix) with ESMTPS id D818016C6094
        for <themes@automattic.com>; Tue,  3 Jan 2017 20:25:42 +0000 (UTC)
Received: from mail.wordpress.org (localhost.localdomain [127.0.0.1])
        by mail.wordpress.org (Postfix) with ESMTP id BA70D214159;
        Tue,  3 Jan 2017 20:25:42 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=wordpress.org; h=
        mime-version:content-type:content-transfer-encoding:from:date
        :reply-to:subject:message-id:references:in-reply-to; s=wp1; bh=4
        RMdfkSspyf94FiOiv44TS+QOpY=; b=fsqVz4XlXzJl4vkCdss1hxBmnUmhe1PDr
        nUq22LBvQ06Wf8P7hg410wP3lj9lAseMa408lEIapTpr/RV2MeQu9FC5JPtrXQNV
        qtR0j6ziwKPBAKEO4T3ELRL0p5N6DuOv0Fi2XaJjhOh/1ZP8BuNyQURQ317wu1bB
        G+vuLirP18=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=wordpress.org; h=
        mime-version:content-type:content-transfer-encoding:from:date
        :reply-to:subject:message-id:references:in-reply-to; q=dns; s=
        wp1; b=aAJpRBd8dOO1D4a/Gj1/kPKkmz+VU71wx8qkx2xwxg6f10x4MjKgVStOF
        vUJvK4AYXWnOWJypHIFOsSCdLsOhllcocSZR0kvCvjlHod8mgppfIWM8qexOh2xV
        EW5qlb/Y66t51MCNSzPol8AjY1XCoYsSkczkk1zd6ScTR/DT9U=
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
From: "WordPress Themes" <noreply@wordpress.org>
X-Trac-Version: 1.0.1
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 1.0.1, by Edgewall Software
X-Trac-Project: WordPress Themes
Date: Tue, 03 Jan 2017 20:25:13 -0000
Reply-To: theme-reviewers@lists.wordpress.org
X-URL: https://themes.trac.wordpress.org/
Subject: =?utf-8?b?UmU6IFtXb3JkUHJlc3MgVGhlbWVzXSAjMzQ0NzY6IFRIRU1FOiBS?=
 =?utf-8?b?ZWJhbGFuY2Ug4oCTIDEuMS4y?=
X-Trac-Ticket-URL: https://themes.trac.wordpress.org/ticket/34476#comment:7
Message-ID: <071.a6e2191aa2ba7a4f4c3caee661ef5a26@wordpress.org>
References: <056.00d47f9a37a313e887ad08a208d6a56a@wordpress.org>
X-Trac-Ticket-ID: 34476
In-Reply-To: <056.00d47f9a37a313e887ad08a208d6a56a@wordpress.org>

IzM0NDc2OiBUSEVNRTogUmViYWxhbmNlIOKAkyAxLjEuMgotLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpSZXBvcnRlcjogIGF1dG9tYXR0aWMgICAg
ICAgfCAgICAgICBPd25lcjogIGFjb3NtaW4KICAgIFR5cGU6ICB0aGVtZSAgICAgICAgICAgIHwg
ICAgICBTdGF0dXM6ICByZXZpZXdpbmcKUHJpb3JpdHk6ICBuZXcgdGhlbWUgICAgICAgIHwgIFJl
c29sdXRpb246CktleXdvcmRzOiAgdGhlbWUtcmViYWxhbmNlICB8Ci0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCgpDb21tZW50IChieSBncmFwcGxl
cnVscmljaCk6CgogQGthcm1hdG9zZWQgQ2FuIHlvdSBjaGVjayB0aGF0IGFuIHVwZGF0ZSBpcyB1
cGxvYWRlZCBub3cgdGhhdCBob2xpZGF5cyBhcmUKIG92ZXI/IFRoZXJlIGFyZSB0d28gb3RoZXIg
dGhlbWVzIHRoYXQgbmVlZCB1cGRhdGVzIHRvby4KCi0tClRpY2tldCBVUkw6IDxodHRwczovL3Ro
ZW1lcy50cmFjLndvcmRwcmVzcy5vcmcvdGlja2V0LzM0NDc2I2NvbW1lbnQ6Nz4KV29yZFByZXNz
IFRoZW1lcyA8aHR0cHM6Ly90aGVtZXMudHJhYy53b3JkcHJlc3Mub3JnLz4KV29yZFByZXNzLm9y
ZyBUaGVtZSBEaXJlY3RvcnkgUmV2aWV3cwo=

HTTPS Redirect for International Sites

Originally reported in #meta-1132.

There is currently no auto-redirect to HTTPS for our local sites like https://de.wordpress.org/. It had worked for a short time because of a change in WP (#27954) to redirect_canonical() but it got reverted later (#29708). In a chat with @nacin he proposed that this should be handled on our LBs.

We currently have ~145 local sites. Adding all subdomains to a redirect rule isn’t something we want I think. Can we force all subdomains to be HTTPS? AFAIK only api.w.org and planet.w.org would be an exception.

BuddyCamp.org DNS and nginx aliases, wildcard certificate

@camikaos and I would like to start creating sites for BuddyCamps on the WordCamp.org multisite installation, but using the buddycamp.org domain. The domain is already in MarkMonitor and Matt gave the ok to use it.

Could someone from systems/@nacin please setup aliases in DNS and nginx?

We’ll also need a wildcard cert for buddycamp.org, since we’re ready to FORCE_SSL_ADMIN across all WordCamp.org sites.

Can johnbillion please be given a sandbox I…

Can johnbillion please be given a sandbox? I can set up commit access and such.

#sandbox

We’re going to be doing a HEAD request…

We’re going to be doing a HEAD request to https://api.wordpress.org/translations/core/1.0/?version=4.1 on the 4.1 about page, in JavaScript. While the heavy operations performed there are cached in memcache for 15 minutes, I think it may be prudent for us to (temporarily?) cache it at the load balancers to avoid being CPU-bound.

Suggestion: cache OPTIONS and HEAD requests to https://api.wordpress.org/translations/core/1.0/ for a period of time. A minute or 15 minutes is fine, but so is an hour.

#caching, #lb, #request

@nacin the new Training team would like to…

@nacin, the new Training team would like to use training@ in conjunction with SupportFlow. Could you please setup the address for them? Once it’s active I can setup SupportFlow.

xref https://make.wordpress.org/systems/2014/11/18/email-google-apps/
cc @liljimmi

#email

Email & Google Apps

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).

#email, #gmail

Getting 404s on the download link here http…

Getting 404s on the download link here:
https://wordpress.org/plugins/amazon-web-services/

https://downloads.wordpress.org/plugin/amazon-web-services.0.1.zip

Not sure why. I see nothing wrong with the plugin in svn itself.

This is a followup to what I posted…

(This is a followup to what I posted on a8c’s sysreq last Thursday, which @762e5e74 was working on. That request should have gone here in the first place, because it’s related to WordCamp.org, so I’m moving the discussion here.)

To summarize the issue, URLs like https://2013.sf.wordcamp.org/tickets are being redirected to http://central.wordcamp.org/tickets, when they should instead be redirected to http://2013.sf.wordcamp.org/tickets. (I think this is because they get caught by the catch-all redirect, even though they’re valid pages.)

r4811-deploy added a new rule that redirected all HTTPS traffic to HTTP, but that conflicted with a PHP redirect back to HTTPS, and created a loop.

We’ve removed the PHP redirect for the time being, since the SSL cert doesn’t work on 4th-level domains. We should be able to re-apply r4811-deploy at this point, but I’d like to make a minor modification to it, so that it’s future-proof for when we do support HTTPS on the 4th-level domains (via 3rd-level aliases and domain mapping, or a wildcard with *.*.wordcamp.org SANs, or some other solution).

The modification would be to ignore HTTPS requests to wp-admin URLs. So, the logic would be:

if https
    if URL doesn't contain wp-admin
        redirect to http version of the URL

That way a request to https://2013.sf.wordcamp.org/wp-admin (or any subpages under wp-admin) would not be redirected, but a request to https://2013.sf.wordcamp.org/tickets will be redirected.

One other thing to keep in mind is that attempts to login to the year.city sites (e.g., http://2013.sf.wordcamp.org/wp-login.php) redirect to http://wordcamp.org/wp-login.php (so they can use the valid SSL), though, and we don’t want that to be affected by any new rules. I don’t think it will be, but thought I’d mention it just in case.

#https, #redirect, #ssl, #wordcamp-org