: Temporarily redirect WordPress url with query string from root directory to new url This post seems to have my answer: How can I redirect old WordPress URL (with a query string) to new URL

@Ogunnowo487

The way I solved this was by using the WordPress plugin Quick Page/Post Redirect Plugin. The url parts that I did the redirect on was: /?post_type=email to /email/fall-2017/.

I could not do the regex or formatting correctly to get this to work in the .htaccess file


The required code/regex is very similar (but even simpler) than what you posted initially, but just needs to go before the WordPress front-controller (as @AlexisWilke suggests).

For example:

# Special redirects
RewriteCond %{QUERY_STRING} ^post_type=email$
RewriteRule ^$ /email/fall-2017/? [R=302,L]

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress


No need for the <IfModule> wrapper or additional RewriteEngine directive. And no need for the RewriteCond directive that checks against the REQUEST_URI server variable - this check is best done in the RewriteRule pattern ie. ^$ (empty URL-path).

Vote Up Vote Down

@Cofer257

Alexis Wilke really found out the issues. Along with the fact that the #038 ; in the url is the html code for &. It just got auto converted in the email and thus went to the wrong url.

The way I solved this was by using the WordPress plugin Quick Page/Post Redirect Plugin. The url parts that I did the redirect on was:/?post_type=email to /email/fall-2017/.

I could not do the regex or formatting correctly to get this to work in the .htaccess file and I think the plugin knows how to code that query string more accurately. Until I get better at regex, I'll stick with using the plugin for redirects.

Vote Up Vote Down

@Nickens628

I think you have two problems.

One, the rewrite are checked in order and you put the more constraining one after the least constraining one (i.e. the redirect with your query string should be first.)

Second, we have another problem concerning the query string. It includes an anchor. That is never sent to the server (anything after #... is client side only.)

So the rewrite cannot take that hash in account, it won't make it to the server and therefore cannot be checked. However, it looks like it has important information, so I don't think you can do it right unless you know how it gets converted before it gets sent to the server. One possibility would be that it is written as %23.

Now, for you to have a good idea you'd have to look into the logs and see what you get there when that page gets hit.

Here I have an example what what you may see.


smsfromme.com:443 173.14.79.185 - - [14/Sep/2017:01:38:36 +0000] "GET /api/1/message/next HTTP/1.1" 404 141 "smsfromme.com" "-" "Dalvik/1.6.0 (Linux; U; Android 4.4.2; SM-G386T Build/KOT49H)" TLSv1 ECDHE-RSA-AES128-SHA


The query string appears after the path, so you should see a GET followed by something like:

"GET /?post_type=email#038;p=14207" ...


Or as I suspect give the information you gave us, this:

"GET /?post_type=email" ...


And if your redirect works, the code after the path will be 302.

It is very likely that you have a JavaScript that takes the anchor (data after the #) and converts that in a GET for the data of the page (i.e. usually called an AJAX request.) It's a cool trick to avoid reloading the entire page each time. But it makes it harder to "tweak" with an .htaccess file.

Vote Up Vote Down