WordPress.org

Ready to get started?Download WordPress

Make WordPress Systems

Updates from December, 2014 Toggle Comment Threads | Keyboard Shortcuts

  • Andrew Nacin 8:24 pm on December 13, 2014 Permalink |
    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.

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

    @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 |
    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 |  

    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.

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

      I’ve run [code]php /home/wporg/public_html/plugins/bb-load.php update amazon-web-services[/code] 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 |
    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 |
    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 |
    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.

     
  • John James Jacoby 3:07 pm on October 10, 2012 Permalink |
    Tags:   

    Last night I updated bbPress.org’s pinned bbPress external to trunk, and now none of bbPress’s custom rewrite rules are working.

    Back during the initial 1.1 to 2.x conversion, @stankea had to do some rule tweaks in nginx. Does this need to be updated too, or is this an issue on my end?

     
  • Dion Hulse 1:10 pm on October 4, 2012 Permalink |  

    FYI, I’ve had a few reports that SSL on the codex is broken in Chrome, for example:
    http://awesomescreenshot.com/0e2i3rx52

    It appears that Chrome is refusing to load insecure content on https codex pages

     
    • Barry 3:56 pm on October 4, 2012 Permalink | Log in to Reply

      Nacin and I talked about this on Monday….I thought he was going to fix it. @nacin ping :)

    • Andrew Nacin 4:21 pm on October 4, 2012 Permalink | Log in to Reply

      Three options:

      1. Move to protocol-relative URLs on WP.org, essentially abandoning the widespread use of s.wordpress.org. Any bandwidth or performance considerations here?
      2. Add https support to s.wordpress.org. Cost consideration.
      3. Get MediaWiki to make its full-page caching protocol-dependent.

      I think the easiest and lightest way forward for now would be to just move to protocol-relative URLs for the Codex only, directly from the global header and footer files.

    • Andrew Nacin 4:29 pm on October 4, 2012 Permalink | Log in to Reply

      For now, I made it so the Codex gets a header with protocol-relative URLs. @barry will be flushing MW’s cache shortly to push it live.

  • Andrew Nacin 1:24 pm on June 30, 2012 Permalink |
    Tags: , ,   

    We are starting a new code sprint today to re-do our existing unit-tests framework. In order for this to be successful we need to raise the visibility of the unit tests commits, which we’d like to do by pushing them over the same wire as core commits.

    1. Can I get a deploy on deploy repo revision 3744, which switches Trac notification emails from wp-unit-tests@lists.wordpress.org to wp-trac@lists.automattic.com?

    2. Can svn notify commit emails for unit-tests.svn.wordpress.org be re-routed from wp-unit-tests@lists.wordpress.org to wp-svn@lists.automattic.com? (There is no need to continue to send to both lists.) Can the -P subject prefix argument for svn notify please be set to -P [Tests]?

     
    • Andrew Nacin 4:03 pm on June 30, 2012 Permalink | Log in to Reply

      Revision 3747 adds tracrpc.* = enabled to trac.ini, to enable XML-RPC. This is already done for core trac.

    • Nikolay Bachiyski 6:27 am on July 2, 2012 Permalink | Log in to Reply

      @nacin, I think it would be a good idea to send it to both lists. I’m sure there are people, who’d like to follow the unit-tests list differently than the core one.

      • Andrew Nacin 6:56 am on July 2, 2012 Permalink | Log in to Reply

        Probably few people, but you are right. I’ve been thinking about this all weekend. Merging them is good, but not also sending things to wp-unit-tests could scare away some people who don’t want the full firehose but might be really excited about unit tests.

        Perhaps systems has an idea for how to implement this.

    • stankea 2:42 pm on July 2, 2012 Permalink | Log in to Reply

      I’ve did the first part of the request and the -P [Tests]
      I’m not sure what to suggest for the notify. I would prefer to have different list for each so that i can control the flow of emails, but i am not sure what is the best for the developers.

    • Andrew Nacin 2:04 pm on July 12, 2012 Permalink | Log in to Reply

      The rest of this has been sorted out:

      • unit-tests.trac now sends to both wp-trac and wp-unit-tests, as CCs on the same email
      • unit-tests.svn now sends to both wp-svn and wp-unit-tests, in a single command

      If you are subscribed to all three lists, you won’t get duplicate threads (assuming your mail client isn’t stupid).

      Thanks, @stankea.

c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
l
go to login
h
show/hide help
shift + esc
cancel