Make WordPress Systems

Updates from August, 2015 Toggle Comment Threads | Keyboard Shortcuts

  • Dominik Schilling (ocean90) 4:24 pm on August 15, 2015 Permalink | | Resolved

      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.

    • Ian Dunn 6:32 pm on March 19, 2015 Permalink | | Resolved

        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.

        • Andrew Nacin 4:07 am on March 21, 2015 Permalink | Log in to Reply

          I’m powerless here. While I can touch nginx there isn’t anything to be done without there being a cert in place first.

        • Ian Dunn 5:00 pm on April 7, 2015 Permalink | Log in to Reply

          @seanosh, I’m was hoping to have the first site setup by May 1st, because there’s a BuddyCamp in June and they’ll need the site to promote it, sell tickets, etc.

          I’m guessing the SSL process can take a few weeks, and I’ll also need some time on my end to set it up, so I think we need to get started soon if it’s going to be ready in time.

          Do you think that’s a reasonable timeline?

        • Barry 3:34 am on April 16, 2015 Permalink | Log in to Reply

          Hi @iandunn – SSL cert obtained and committed. Also updated the nameservers for buddycamp.org and added a DNS entry (might need to change). I think @seanosh can help you with the rest. Also – did you talk to Matt about buying any of the other buddycamp domains? Looks like some are already registered (.com) and others are available for registration (.net). I didn’t really look too much.

          • Ian Dunn 2:49 pm on April 16, 2015 Permalink | Log in to Reply

            Awesome, thanks 🙂

            I hadn’t thought about the other domains, I’ll add that to the list.

            • Ian Dunn 2:50 pm on April 16, 2015 Permalink | Log in to Reply

              Er, I meant, I’ll add that to my task list for the site and look into it once the high priority stuff is done.

        • seanosh 12:58 pm on April 21, 2015 Permalink | Log in to Reply

          Added NGINX configs for buddycamp.org, *.buddycamp.org with SSL support similar to wordcamp.org and *.wordcamp.org. Right now it 302’s to central.wordcamp.org, so it looks like you just need to set this up in WordPress. If anything else is needed on this please unresolve and comment. Thanks!

      • Andrew Nacin 3:43 am on January 22, 2015 Permalink | | Resolved


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

        • Andrew Nacin 8:24 pm on December 13, 2014 Permalink | | Resolved

            Tags: caching, lb,   

            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.

            • Andrew Nacin 5:39 am on December 16, 2014 Permalink | Log in to Reply

              Something like this is dead-simple and should work:

              location /translations/core/1.0/ {
              	proxy_cache ssds;
              	proxy_cache_valid 200 30s;
              	proxy_pass http://_wporg_api_webs;

              While you could specifically block GET with a bit more config, as long as the cache key includes $args (which it does by default), there’s no reason not to just cache GET requests too.

            • stankea 9:21 am on December 16, 2014 Permalink | Log in to Reply

              Looks like http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_cache_methods would still cache GET requests if you only ask for HEAD. Another option would be to have an if check for $request_method, but after talking to @nacin about it it looks like it’s fine to cache GET’s too. Deployed this config.

          • Ian Dunn 8:06 pm on December 11, 2014 Permalink | | Resolved


              @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

            • Jen 9:01 pm on November 18, 2014 Permalink | | Resolved

                Tags: , gmail   

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

                • Andrew Nacin 11:02 pm on November 18, 2014 Permalink | Log in to Reply

                  Hey @jenmylo, I’m trying to figure out the exact use case for doing this. We’ve always done forwards, which works perfectly well for these two situations:

                  • An individual person who needs their mail forwarded to their primary email
                  • A group email that needs to be forwarded to multiple people

                  Google Apps would add overhead to both of these.

                  Then there’s the third use case, which is a “mailbox.” Even if we switched to Google Apps, we wouldn’t actually have people accessing these mailboxes directly. We would pipe emails through a SupportPress or Supportflow install. The only benefit to this setup, thus, would be replacing this procedure: “setting up one-off gmail addresses to handle the mailbox, the owner of which might get lost over time”.

                  Yes, this is indeed our current approach. But it actually works quite well. I know of eight such accounts in use, and all of the passwords are stored in a single configuration location. I’m not sure about the missing owner situation — perhaps it has happened before, but in order for SupportPress/Supportflow to actually connect to these accounts, it needs the password anyway, which ultimately controls everything for these. Even if we moved to Google Apps, we’d still need a similar configuration.

                  I remember talking to Barry about this at WCSF and at the time at least, we both thought this was about WordCamp.org moving to Google Apps. I don’t know what the requirements are there (with regards to organizing teams and how that all works), and I have no opinion either way on which direction WordCamp.org is set up. With WordPress.org, I don’t see the reason for switching.

                  I’ve been dealing with a few email-related things, primarily @chat.wordpress.org. I don’t think what I’m working on would be affected by anything here.

                  • Jen 11:08 pm on November 18, 2014 Permalink | Log in to Reply

                    cc @barry ^^

                  • Ian Dunn 1:26 pm on November 19, 2014 Permalink | Log in to Reply

                    If there isn’t a consensus for setting up real mailboxes, we could work around that for SupportFlow installs by setting up foo@wordpress.org aliases that forward to wordpress-foo@gmail.com, and then connect the Gmail account to SupportFlow.

                    One drawback to that is that replies to the user would be sent from the Gmail account, rather than the WordPress.org account. That’s not a big deal, but it does feel a little janky, and the user will end up with two addresses in their address book for the same entity.

                    • Dion Hulse 4:11 am on November 20, 2014 Permalink | Log in to Reply

                      I don’t have any knowledge of how SupportFlow works, but is there any reason why the email would have to be sent via the mailbox?
                      Couldn’t you just use the WordPress.org outgoing SMTP & BCC the email to the gmail account if required?

                      • Ian Dunn 12:06 pm on November 20, 2014 Permalink | Log in to Reply

                        Sorry, I’m not folllowing. Are you saying it’s possible to setup a foo@wordpress.org alias, and then send mail from it as if it were a regular account? Or that the current @wordpress.org addresses have regular SMTP accounts, but with the mailbox disabled?

                        In my limited experience, the ability to send mail from an address is coupled with having a mailbox, but maybe that’s just an artificial restriction that things like Plesk have added on top of the mail service itself?

                        • Samuel Wood (Otto) 11:32 pm on November 21, 2014 Permalink

                          I’m not entirely certain on all the details, but no, an “account” is not necessarily linked to a sending address.

                          For example, for the themes supportpress (where commercial theme listings are handled), there is a forward to a gmail account. SP retrieves the email from there. But any replies are actually sent back through our own SMTP server at mail.wordpress.org. So, the gmail account never actually sees the replies, we don’t send replies back through it or from it. It’s just a receiving box and holding area (and spam-scanner).

                          I am unfamiliar with Plesk.

                        • Ian Dunn 8:58 pm on November 23, 2014 Permalink

                          Ah, ok. I think that would work for our purposes, then.

              • Samuel Wood (Otto) 10:43 pm on September 20, 2013 Permalink | | Resolved

                  Getting 404s on the download link here:


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

                  • stankea 3:39 pm on September 23, 2013 Permalink | Log in to Reply

                    I’ve run

                    php /home/wporg/public_html/plugins/bb-load.php update amazon-web-services

                    on all prod webs as requested by @nacin to fix this

                    • Samuel Wood (Otto) 3:44 pm on September 23, 2013 Permalink | Log in to Reply

                      Thanks. Are the svn’s still overloaded? That could be the cause of this failing to work normally, along with the theme svn problems that were reported the other day.

                • Ian Dunn 6:20 pm on June 17, 2013 Permalink | | Resolved

                    Tags: https, redirect, ,   

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

                    • Barry 6:38 pm on June 17, 2013 Permalink | Log in to Reply

                      I think @nacin is going to take care of this.

                    • Andrew Nacin 6:48 pm on June 17, 2013 Permalink | Log in to Reply

                      Done in a simpler fashion. Please confirm it works.

                    • Ian Dunn 6:56 pm on June 17, 2013 Permalink | Log in to Reply

                      Looks good to me. HTTPS requests to wp-admin are redirecting to HTTP, but I’m guessing that was intentional.

                      Thanks guys 🙂

                      • Andrew Nacin 7:15 pm on June 17, 2013 Permalink | Log in to Reply

                        The certificate is only good for ^wordcamp.org.

                        • Ian Dunn 7:32 pm on June 17, 2013 Permalink | Log in to Reply

                          Right, I was just thinking it’d be easier to make the rule flexible enough to allow HTTPS now, rather than having to come back and modify it later, since we’ve talked about making SSL work on the 4th-level domains at some point in the future.

                          I know admins will get a warning if they try to view it over HTTPS now, but they’ll only get that if they manually type it in, so it would have a minimal impact and still allow admins to choose to use HTTPS (despite the warning) if they’d prefer to.

                          Regardless, I’m fine with the way it is now.

                          • Barry 12:21 am on June 20, 2013 Permalink | Log in to Reply

                            How do you plan to make SSL work on 4th level domains?

                            • Ian Dunn 2:04 am on June 20, 2013 Permalink

                              We haven’t dug into it too much yet, and probably won’t look at implement anything anytime soon, but the two ideas that Konstantin and I talked about were:

                              1) Setting up 3rd-level domains like 2013-sf.wordcamp.org with domain mapping, so that a normal wildcard cert would cover them.
                              2) Using subject alternate names so the SSL could cover *.*.wordcamp.org [1, 2].

                              I think #2 could possibly be easier to setup and maintain, but would probably also be more fragile, since browser support isn’t 100%. It would only be used by a handful of admins and WordCamp organizers, though, so that may not really be an issue.

                              What are your thoughts on all that?

                  • Jen 7:11 pm on April 9, 2013 Permalink | | Resolved

                      Tags: site setup, wordpress.net,   

                      WP10 Site 

                      Hi all. We need a wp install set up at wp10.wordpress.net for the 10th anniversary parties site. Matt would like it there rather than on .org, but @otto42 doesn’t have access there. Can someone set it up and make me an admin? Thanks.

                      • Andrew Nacin 7:37 pm on April 9, 2013 Permalink | Log in to Reply

                        wordpress.net is where things go to rot, nor is it taken seriously. wp10.wordpress.org makes far more sense. If there’s a concern that it’s an extra subdomain to maintain, I don’t find that to be a problem — it’s one line in an existing nginx file, followed by a new site on the network. Much easier than something new on multipattern. Also, wp10 is unique, it isn’t going to clash with a language or something else in the future. Ten years is a big deal, we shouldn’t hide it on .net.

                        FWIW, wikipedia.org did http://ten.wikipedia.org in 2011 and they surely intend to keep that archive around.

                        • Jen Mylo 7:40 pm on April 9, 2013 Permalink | Log in to Reply

                          If the URL is under discussion, another option I didn’t think of when talking to Matt earlier would be to put it up at meet.wordpress.org/wp10 (or /ten or /10) if we got moving on getting the meet section up there with the feeds from meetup.com. Kind of would make sense?

                      • Barry 11:17 pm on April 10, 2013 Permalink | Log in to Reply

                        Happy to do whatever, we just need to know what URL to use.

                      • Barry 1:57 pm on April 17, 2013 Permalink | Log in to Reply

                        Any updates here?

                    • Nikolay Bachiyski 10:59 am on January 21, 2013 Permalink | | Resolved

                        Tags: ,   

                        Hey, I am trying to login to the Unit Tests Trac, so that I can reply to a ticket there, but /login redirects to https://core.trac.wordpress.org/log/tests.

                        Was this by design? I would prefer to reply to active tickets there until we migrate the conversations to the core trac.

                      compose new post
                      next post/next comment
                      previous post/previous comment
                      show/hide comments
                      go to top
                      go to login
                      show/hide help
                      shift + esc
                      Skip to toolbar