Web app URL redirects / php

[mark rushton94]

Hi all,

I am very new to redirects and seem to have got myself confused having read through various posts:

I'm trying to take a variable and redirect it to another URL (so if I had one web app and wanted the searchstring URL to be changed to another web app)

RedirectMatch ^example1.com/results.php?&searchword=(.*) example2.co.uk/?p=keywordsearch&term=$1

I've tried quite a few rewrite rules as well.

As an example URL example1.com/results.php?&searchword=mark_test should become example2.co.uk/?p=keywordsearch&term=mark_test

Keen to hear your advice/approach to this

[lucy24]

Redirect(Match) is a mod_alias directive. You can't do this in mod_alias, because it doesn't "see" the query string; you'll have to use mod_rewrite with a RewriteCond looking at %{QUERY_STRING}. This, in turn, means that any existing redirects need to be converted to mod_rewrite because it isn't good practice to mix the two.

I've tried quite a few rewrite rules as well.

Good, that's what you need to use. Let's see what you tried, and what the results were. (Not "it didn't work". The exact results!)

[whitespace]

As lucy24 says.

Just a comment on your use of RedirectMatch....

RedirectMatch ^example1.com/results.php?&searchword=(.*) ......

The first argument to Redirect(Match) matches against the URL-path. ie. "/results.php" in your example. This notably excludes the host (ie. "example1.com"). (And the query string, as mentioned above.) When specifying an absolute URL in the substitution you also need the scheme. eg. "http://example2.co.uk/...".

(Similar rules apply when using the RewriteRule directive (mod_rewrite) - no host, no query string.)

[mark rushton94]

Thanks very much for taking the time to help!

My thinking of what the rule should be doing in English would be:

1) Confirm the hostname is the old hostname
2) Look for the old query string (?&searchword=(.*)) and capture the text after the = sign.
3) Rewrite the rule with the new hostname, new query string (p=keywordsearch&term=$1) and place the captured text after the = sign

Options +FollowSymLinks
RewriteEngine on
RewriteCond %{HTTP_HOST} ^SERVER_NAME(.*)
RewriteCond %{QUERY_STRING} ^&searchword=$
ReWriteRule ^results\.php\/\/\?\&searchword=(.*) newservername/level1/level2/\?p=keywordsearch&term=$1 [R=301,L]

Having fun learning this sort of stuff!

[lucy24]

You're getting there, except:

^SERVER_NAME

There exist situations where SERVER_NAME is needed, but this isn't one of them. Just use the regular domain name, example\.com, without anchors (because extraneous stuff like port numbers, and incorrect www, will all be taken care of in the redirect).

%{QUERY_STRING} ^&searchword=$

This formulation will always fail, because ^ means "the very beginning of the test string", and I'm pretty sure your query string never begins with an ampersand (for "next parameter"). Worse, it would only succeed if "searchword=" came at the very end of the query, which normally wouldn't happen.

ReWriteRule ^results\.php\/\/\?\&searchword=(.*)

I hope "ReWrite" was just a typo. Not everything is case sensitive, but why take chances. Slashes in mod_rewrite do not need to be escaped; neither do ampersands. Question marks do-- but as explained above, query strings cannot go in the body (pattern) of the rule. So the rule itself will always fail, even before the conditions are evaluated.

Ordinarily I would say to list conditions in order of "most likely to fail" for efficiency. But here, since you need to capture from the query-string condition, that one has to be last (i.e. you got it right).

If you need to capture the value of a particular parameter, it would be (without anchors)

RewriteCond %{QUERY_STRING} searchword=([^&]*)

This capture then becomes %1 in the target.

The target of an external redirect should begin with the full protocol-plus-domain. Pro tip: If you need to name more than one domain for posting purposes, they can be example.org, example.net, example.co.uk etcetera etcetera; you can even make up a TLD if you like.

[whitespace]

I'm pretty sure your query string never begins with an ampersand

I was wondering this too, but since all the URLs above appear to contain this erroneous ampersand and the target doesn't I was thinking it must be part of the "fix"?

[lucy24]

Hm, maybe so. Unless it's all the same typo ;) But unless he's got overlapping parameter names (like "search=something" vs. "research=something-else"), it shouldn't be an issue.

Someone once posted a question in which they really did have overlapping names-- and values. I wish I'd made a note of it, because their real-life terms were way better than anything I could have made up.

Edit:
Pasting this here so I don't have to go looking for it again:
[webmasterworld.com...]
where the quoted URL includes the element
&id=3&Itemid=36

[mark rushton94]

Hi Lucy24, whitespace

Thanks again! A lot more pennies dropped and have a few further points (apologies if I've misunderstood your advice I have read it a good few times so hopefully covered your tips in the next attempt)

To first clarify the URL string
1) Indeed, the URL was given to me incomplete(!) so the correct example is "example1.com//results.php?search=1&start=0&max=20&searchword=mark_test"
2) Eventually, the DNS for my first server will point to the second server (see point 3) i.e as the old app is no longer required only the url for the new url will be active. e.g example1 will resolve as example2 ip address

With your pointers in mind I thought the redirect would be similar( but still flakey on what i'm writing here) to:

Options +FollowSymLinks
RewriteEngine on
RewriteCond %{HTTP_HOST} example1.com
RewriteCond %{QUERY_STRING} ^search=1&start=0&max=20&searchword=$
RewriteRule ^results\.php example2.com/level1/level2/\?p=keywordsearch&term=$1 [R=301,L]

# My use of $ signs are probably wrong here but what I am trying to do is capture the searchword term and place that into the new url parameter (keywordsearch&term=). I don't need to consider the previous parameters

3) When testing this in the browser it comes back with can't find results.php.... which I've looked into quite a bit and again, confused myself. The results.php file won't exist when the DNS names are switched to the new server - so - my confusion is (if I can get the rule right first) presumably it will just match my rule and not look for the physical file and transform the URL. Forgive me if I have set knowledge alarm bells off :)

[lucy24]

The $ has two entirely different and unrelated meanings. In a pattern-- that is, the left side of a Rule or the right side of a Condition-- it means "the very end of the test string". In a target-- that is, the right side of a rule-- it has to be followed by a number 1-9 and means "suchandsuch capture from the Rule". In your quoted rule-plus-condition I don't see any captures at all, so the $1 in the target doesn't refer to anything. It should come through as the empty string, not as a 500-class error.

Since the rule is set up as an external redirect, it should be easy to tell if it's doing what you intended, because your browser's address bar will change. What do you see? In many newer browsers you may have to copy-and-paste the address-- or at least highlight it-- or it won't show you anything but the hostname. From your quoted error page it sounds as if the redirect isn't happening at all.

On a quick eyeballing, the most likely problem is that the RewriteCond referring to the query string is too heavily anchored.

I hope your target doesn't really begin with the bare domain name, because that will lead you to a spectacularly wrong place. The exact form of the wrongness depends on (a) whether you've got a RewriteBase line and (b) your server's directory structure, but you will always end up on the old domain, not the new one.

[mark rushton94]

Options +FollowSymLinks
RewriteEngine on

# Capture the term after searchword as %1
RewriteCond %{QUERY_STRING} ^search=1&start=0&max=20&searchword=([^&]*)

#Here I want every piece of the original URL to be forgotten and simply the %1 pasted at the end of the 'target url'
RewriteRule ^results\.php example2.com/level1/level2/\?p=keywordsearch&term=%1 [R=301,L]

This still errors out saying /results.php was not found on this server?

Thanks

[lucy24]

#1 What does your browser's address bar say?

#2 What is the actual target in the rule? Copy and paste your actual rule, replacing the hostname with "example" but leaving everything else the way it really is.

[mark rushton94]

test

[mark rushton94]

#1 http://example.com/results.php?search=1&start=0&max=20&searchword=mark_test
--This does not change when the rule is in place

#2 The current rule that I believe is my closest attempt is in .htaccess file under /var/www/html

Options +FollowSymLinks
RewriteEngine on
RewriteCond %{QUERY_STRING} ^search=1&start=0&max=20&searchword=([^&]*)
RewriteRule ^results\.php example.com/level1/level2/\?p=keywordsearch&term=%1 [R=301,L]

#3 The browser should now display
http://example.com//level1/level2/?p=keywordsearch&term=mark_test

[lucy24]

No, I wasn't ignoring you for a day and a half. My internet was down.

#3 The browser should now display

Actually, it shouldn't-- at least not on all servers. I experimented on my test site because I'd never seen an external redirect whose target was expressed in exactly that way. With the target as shown, not beginning in either a protocol or a / slash, AND with no RewriteBase directive, the target would instead be

http://www.example.com/var/www/example.com/level1/level2/\?p=keywordsearch&term=blahblah

(using the physical filepath up to "example.com"). It's not what I expected, since there's supposed to be a default RewriteBase; go figure. But even if the RewriteBase did kick in as intended, the target would then be

http://www.example.com/example.com/level1/level2/\?p=keywordsearch&term=blahblah

with two consecutive "example.com" because the server has no way of knowing that the one in the target is supposed to be a hostname. It thinks it's just another directory.

I'm also not sure how the \? would be treated but that's a minor issue. If you're lucky, escape \ slashes are simply ignored, so it's just unnecessary, not outright harmful.

Now then! If the address bar doesn't change, it means the rule isn't executing. You can confirm this by looking at your access logs, where the original request immediately gets a 404 instead of a 301. (If it's your own server you can also look at the RewriteLog, but it really isn't necessary.) The likeliest explanation is that the query string does not, in fact, match

^search=1&start=0&max=20&searchword=([^&]*) 

... which is odd, since the quoted URL

http://example.com/results.php?search=1&start=0&max=20&searchword=mark_test

would seem to be an exact match. See what happens if you cut the condition back to

searchword=([^&]*)

with no anchor at the front. Look only at the one parameter, ignoring the rest for now.