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, so I’m moving the discussion here.)

To summarize the issue, URLs like are being redirected to, when they should instead be redirected to (I think this is because they get caught by the catch-all redirect, even though they’re valid pages.)

r4811-deployDeploy Launching code from a local development environment to the production web server, so that it's available to visitors. added a new rule that redirected all HTTPSHTTPS HTTPS is an acronym for Hyper Text Transfer Protocol Secure. HTTPS is the secure version of HTTP, the protocol over which data is sent between your browser and the website that you are connected to. The 'S' at the end of HTTPS stands for 'Secure'. It means all communications between your browser and the website are encrypted. This is especially helpful for protecting sensitive data like banking information. traffic to HTTPHTTP HTTP is an acronym for Hyper Text Transfer Protocol. HTTP is the underlying protocol used by the World Wide Web and this protocol defines how messages are formatted and transmitted, and what actions Web servers and browsers should take in response to various commands., but that conflicted with a PHPPHP PHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-purpose scripting language that is especially suited for web development and can be embedded into HTML. redirect back to HTTPS, and created a loopLoop The Loop is PHP code used by WordPress to display posts. Using The Loop, WordPress processes each post to be displayed on the current page, and formats it according to how it matches specified criteria within The Loop tags. Any HTML or PHP code in the Loop will be processed on each post.

We’ve removed the PHP redirect for the time being, since the SSLSSL Secure Socket Layer - Encryption from the server to the browser and back. Prevents prying eyes from seeing what you are sending between your browser and the server. 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 *.* 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 (or any subpages under wp-admin) would not be redirected, but a request to will be redirected.

One other thing to keep in mind is that attempts to login to the sites (e.g., redirect to (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