Problem setting up a redirect for old blog posts

  • I recently switched an old blog over to WordPress. The old url format was like this:

    
www.blog.com/post.php?s=the-blog-post-title

    Now that I’ve switched to WordPress the format has changed to this:

    www.blog.com/the-blog-post-title

    I’ve tried a few different things to set up a redirect that will remove the post.php?s= from the url and take the visitor to the correct page, but nothing has worked. I have tried adding a redirect in the .htaccess file:

    RewriteCond %{HTTP_HOST} ^blog.com [NC]
RewriteRule ^/post\.php\?s=(.*)$ https://www.blog.com/$1 [R=301,L]

    and

    RewriteRule ^/post.php?s=(.*) /$1 [QSA]

    I’ve also tried using the redirection plugin:

    Source: ^/post.php?s=(.*)
Target: https://blog.com/?redir=$1

    Since I am not very familiar with regular expressions I am not sure if I am entering incorrect code or if I am just placing it in the wrong place for WordPress.

    Any help would be GREATLY appreciated.

Viewing 4 replies - 1 through 4 (of 4 total)
  • Moderator Steven Stern (sterndata)

    (@sterndata)

    Volunteer Forum Moderator

    ?s= is reserved for the WordPress search so I don’t think you can redirect it. On the other hand, at least someone coming to that link will probably find what they’re looking for at the top of the search results.

    Thread Starter robopenguin

    (@robopenguin)

    Thanks for responding. Currently they just get a 404 page that has no search results. Is there something I can do to get WP to show results on a 404 page?

    Moderator bcworkz

    (@bcworkz)

    I’m afraid Mr. Stern is a bit off from his normally excellent advice. The WP search query string is not a factor for .htaccess rules applied before the WP rule set. If you can rewrite the request before WP “sees” it, it will no longer be a search request.

    Part of the problem is query strings are usually stripped before applying any regexp comparisons, so we need to explicitly check against the query string only. The match here can be back referenced in the rewrite rule with %1. For some reason, rewriting to a permalink doesn’t work, but creating a WP compatible query string is OK.

    Also, checking the host name shouldn’t be necessary unless the site uses several aliases and you only want a redirect for one of them. If you do do such a request, you need to account for a possible www by dropping the ^ or adding (www)?\. after it. Anyway, we end up with this:

    RewriteCond %{QUERY_STRING} s=(.*) [NC]
RewriteRule . /index.php/?name=%1? [QSD,R=301]

    The final ? in the rewritten request is supposed to drop the query string – the one place a query string is used but where we don’t want it! For Apache 2.4+ the QSD flag should do the same thing. The problem is, this does not work! It should, but it doesn’t.

    The proper syntax for adding a query string is actually example.com/post.php/?s=post-slug (a slash before the ?) Everyone ignores this, and it normally is not an issue, except for this rule set. If you used the proper syntax, this rule set would work fine. Since everyone neglects that slash, we need to add it with the following first:

    RewriteCond %{REQUEST_URI} /post.php$ [NC]
RewriteRule . /post.php/

    The initially suggested rule set would actually interfere with a normal WP search query, but since we need to add this other rule, it has the nice side effect of not influencing the WP search query.

    The complete rule set, added to .htaccess before the WP rule set:

    <IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_URI} /post.php$ [NC]
RewriteRule . /post.php/
RewriteCond %{QUERY_STRING} s=(.*) [NC]
RewriteRule . /index.php/?name=%1? [QSD,R=301]
</IfModule>

    Despite all this, at least on my server, a request without that terminal slash with this rule set still fails to strip the original query string. Arrrgh! Fortunately, WP correctly rewrites the name parameter as a permalink. As long as the permalink resolves to an actual post, the errant query string, despite being a valid search query, is ignored. If the original request did happen to have the terminal slash, everything works perfectly.

    I haven’t throughly tested this, there may still be particular requests that don’t work right.

    Thread Starter robopenguin

    (@robopenguin)

    Thank you both for your help! Since I was unable to get it to work with a catch-all regular expression I ended up installing the Redirection plugin. then after creating a few redirects, I went into the plugin db and inserted the list of 1350 old links and their new locations.

Viewing 4 replies - 1 through 4 (of 4 total)
  • The topic ‘Problem setting up a redirect for old blog posts’ is closed to new replies.