Description of problem: Things that may have previously gotten directed to pipermail are now being eaten by the redirect. Example: http://www.gluster.org/pipermail/gluster-users/2015-March/020995.html What they actually wanted: http://lists.gluster.org/pipermail/gluster-users/2015-March/020995.html Expected results: We'll need to figure out the proper regex to redirect the lists domain again.
Looking at the WP UI for this, the source URL supports regexp but I'm not sure how the target URL gets the matching string fed in. So the source regexp could be (at least to try): *gluster.org/pipermail.* This way if www or no sub-domain is used, it matches. For "Position", aiui Top means run this rule first, Bottom means run this rule after all others. I'd say Bottom is safest to try first so it doesn't steal blog posts & redirect. i.e., the risk is if there is ever a page or post that is www.gluster.org/pipermail it will get redirected/rewritten. Looks like this is the plugin being used: https://wordpress.org/plugins/redirection/
One fix for the source URL: .*gluster.org/pipermail.* (Reading through https://wpengine.com/support/regex/ )
Created attachment 1324980 [details] WPEngine UI screenshot
The WPEngine how to recommends this pattern: Name: Redirect catch all Domain: www.domain.com Source: ^/thisiswhere/myfileswere/(.+) Destination: /thisiswhere/myfilesmovedto/$1 Redirect type: 301 Permanent Our UI is a bit different (ref attached PNG), we need to fill out: Source URL: Regex [./] Title: Match: [URL only] <== anything else interesting under that menu? When matched: [Redirect to URL] w/ 301 <== seems like a good choice Target URL: Group: [Modified Posts] <== anything else interesting under that menu? Position: Bottom might be safest so we're not overwriting WP rules So I think "Source URL" would be a regex of: .*gluster.org/pipermail(.+) Target URL: lists.gluster.org/pipermail/$1 This should grab whatever follows /pipermail/ at any subdomain (or no subdomain so plain gluster.org/pipermail/) and redirect that follow stuff to lists.gluster.org/pipermail/.
This doesn't pick up any hits, not sure why. I'm using "https://www.gluster.org/pipermail/gluster-devel/2017-August/thread.html" as a test URL, so let's keep poking at it.
New ideas since #c4 didn't work: Source URL: .*gluster.org/pipermail/(.+) Target URL: lists.gluster.org/pipermail/$1 ... or ... Source URL: .*gluster.org/pipermail/(.*) Target URL: lists.gluster.org/pipermail/$1
Alright, so this is now even more broken than we had it before. I'll go ahead and remove the redirects that were put in place, and will await further instruction on this. Timeline for fix: sometime this week if possible? I'm not sure how this worked in the first place, and it may be that the WP install is trying to eat all the things.
I'll bring the discussion back to Michael, we'll figure out a plan & timeline, and return with those to this ticket. Once we have a plan in place here, we'll reassign to you for ACK on the plan and reassignment back to complete to close.
One more point -- we should also make sure that www/mailman(.*) also redirects to lists.gluster.org/mailman$1.
You shouldn't place the domain in source URL, since the domain is not part of the URL. Name: Redirect catch all Domain: www.gluster.org Source: ^/pipermail/(.*) Destination: http://lists.gluster.org/pipermail/$1 Redirect type: 301 Permanent That's the equivalent of the existing setup on Apache side: https://github.com/gluster/gluster.org_ansible_configuration/blob/master/roles/httpd_www/templates/redirect_lists.conf
OK, that helped a lot -- I didn't prepend the rule with ^ and that fixed this case so the rewrite/redirect is now working for hardlinked mailing list links.
Next question is, what is the best/proper way to handle these rewrites? * DNS * Apache via wordpress instance? * WPengine's redirect interface?
We can't do DNS for that. Apache via wordpress mean on the wordpress level, it would work but that's consuming ressources. I would go WPengine redirect interface, that's done on nginx so faster, so better latency and less risk of breakage.
Here's what I'll do: It seems to be working at the moment, so let me see if it continues to work, and what it does to our traffic to have the redirect through the direct WordPress install. I'll give it until EOD today and compare against what we had previously and see if it makes a big difference. If it does, I'll move it to the nginx interface through WPEngine.
WPEngine gave me a note on the internal portal that we were likely to go over our traffic, so I've moved this to their nginx redirect rules as of 8:50am Pacific time.