0

I have rewrites working for specific directories, but can't figure out how to get the search results rewrite to work.

If go directly to /blog/?s=coffee, it goes to the correct search results page. However due to the other url rewrites, the search results page is trying to go to /?s=coffee/.

The dynamic content part is throwing me. I've tried many things, but the lates

<rule name="Redirect long query string" stopProcessing="true">
    <match url="^?s=(.*)$" />
    <action type="Rewrite" url="blog/?s=$1" appendQueryString="false" />
</rule>

I have no clue what I'm doing. It's a miracle I got the other rewrites working.

2 Answers2

1

I'm sorry to be the one to bring you the bad news, but your rewrite rule isn't doing anything for you. The regular expression in the <match> tag is invalid. First of all the query string is not part of the URL there and to match a ? in a regular expression you have to use \? as the ? has special meaning in regular expressions.

And also the syntax in your rewritten url is invalid. You can't use $1 for back reference but should use {R:x} (for back references to the URL) or {C:x} (for back references to the conditions) where x is the number of the part of the regular expression you want to reference to.

Unfortunately it's not exactly clear to me what you are trying to accomplish. My guess is that you are trying to rewrite all requests that start with s=<something> in the query string to /blog/?s=<something>. If that's the case, then this rule should do that:

<rule name="Rewrite search queries" stopProcessing="true">
    <match url=".*" />
    <conditions>
        <add input="{QUERY_STRING}" pattern="^s=([^&amp;.]*)&amp;?" />
    </conditions>
    <action type="Rewrite" url="blog/?s={C:1}" appendQueryString="false" />
</rule>

For simplicity, the s=<something> needs to be the first parameter of the query string.

If you want to do something else, please edit your question and give a few more examples of URL's and how they will have to be rewritten.

Update: If you need the search form to use site.com/blog/?s= instead of site.com/?s= why not simply change the HTML of the search form? Just change the action of that form.

To have the above rule work together with WordPress rewrite rules, you have to modify it slightly. First of all you have to remove stopProcessing="true" and to be safe, modify the url of the <action> and add a leading slash. Might not be really necessary, just to be sure.

So the rewrite rule will become:

<rule name="Rewrite search queries">
    <match url=".*" />
    <conditions>
        <add input="{QUERY_STRING}" pattern="^s=([^&amp;.]*)&amp;?" />
    </conditions>
    <action type="Rewrite" url="/blog/?s={C:1}" appendQueryString="false" />
</rule>

And make sure this rule is above the WordPress rewrite rules. The WordPress rules should be the last rules.

Marco Miltenburg
  • 1,121
  • 8
  • 9
  • You are correct in your assumption, however this rule doesn't seem to work. Just to make sure it's clear, on the page `site.com/blog/` there is a search bar that is set to only search blog posts (as opposed to anything in the database). If you search for `coffee`, the url resolves to `site.com/?s=coffee` however I need it to resolve to `site.com/blog/?s=coffee`. Make sense? – kristina childs Nov 26 '12 at 19:54
  • Perhaps I should also add this is for a fairly complex wordpress site. This search is set up to ignore all custom post types and pages, but natively search runs from the root which is why it's trying to resolve to the main index rather than the category base `blog`. – kristina childs Nov 26 '12 at 19:58
  • 1
    I've modified my answer. But I feel there is no need for the rewrite rule at all, simply change the search form. – Marco Miltenburg Nov 27 '12 at 11:46
  • I did that yesterday :) Sometimes the most obvious answers are the ones hardest to see... – kristina childs Nov 27 '12 at 19:30
  • ...but gave you some +1s for helping – kristina childs Dec 04 '12 at 20:33
0

I discovered a much simpler way of accomplishing the same thing (at least for the time being) by using a custom search form in my theme. I am sure this problem will arise at some point in the future, but as long as this is the only search for the website needs it will work. I imagine there is some way to allow for multiple search forms the same way you can have multiple category archive pages (like searchform-[slug].php) so will experiment with that later.

I am still interested to know how something like this would be accomplished through IIS however, >> this solution << solved my problem.