RewriteRule not processing

rule not being processed at all

[Cipherlad]

I had our site working under a development subdomain, but when we moved it something must have changed. I could never get RewriteRule to work in the root .htaccess file, instead I had to place them in an .htaccess file in the wp-content folder. Now, it won't even work there. I don't get any errors, the page just redirects to the site root.

It's not the RewriteRule syntax. As I've said, it worked before the site migration. Are there plugin conflicts that might be happening? Is there something failed to be set up in cPanel?

[lucy24]

Answers, in no particular order:

Yes.
No.
Maybe.
I don't know.
Prospects look uncertain.
Ask again tomorrow.
Undefined variable.
Mouse error: unexpected end of cheese.

Since you don't show your code and don't give any examples of what you want to have happen, it's pretty hard to arrive at a definitive answer. I could make something up if you like :)

[Cipherlad]

Here is the extent of the offending code in .htaccess:

Options All -Indexes

RewriteEngine On
RewriteRule ^/content/([^/]+)/([^/]+)\.html$ http://www.mydomain.com/content/$1/ [NC,R=301,L]

I want it to take all requests that match the pattern and do a 301 redirect to the result. For instance...

http://www.mydomain.com/content/FluffyKitty/page1.html

to

http://www.mydomain.com/content/fluffykitty/

There's a custom taxonomy for "content" that handles "fluffykitty".

[lucy24]

OK, two immediate problems.

#1

RewriteRule ^/ etc.

will always fail, unless you've got a very forgiving server. In mod_rewrite, that first slash is treated as part of your domain name, so what you've got-- potentially-- is

www.example.com//content/ etc.

([^/]+)/([^/]+)\.html$

Ooh, points for getting this right and not throwing in any .* in the middle ;) Note that since you're not using the last part of the address, you don't need to capture it.

#2

http://www.example.com/content/FluffyKitty/page1.html
to
http://www.example.com/content/fluffykitty/

There's a custom taxonomy for "content" that handles "fluffykitty".

I hope "handles" means "deals with case", because if not, you're in trouble. The flag [NC] will find requests regardless of case, but it won't change case. Apache's dialect of RegEx doesn't include case-changing.

Is "fluffykitty/" a directory, or is there a further rewrite that makes it back into a page name?

In what way does the Rule fail? No effect at all, wrong effect, unpredictable effect, crashes server? That's assuming for the sake of discussion you haven't overlooked anything embarrassing like RewriteEngine On.

[mememax]

What do you want to achieve? REdirect to no case or just eliminate the last html?

If it's the 2nd, remove the bar after the ^ and simplify the code (sorry I'm used to make it another way so I'll post in the way I'm accustomed to)

RewriteRule ^content/(.+)/(.+)\.html$ [mydomain.com...] [NC,R=301,L]

[lucy24]

.+ is very nearly as bad as .* in any non-final position.

The original ([^/]+)/[^/]+\.html$ is exactly right, so don't change it. (I left off the second set of parentheses.) But the case-changing from Fluffy to fluffy worries me. And, of course, what happens after the final slash.

[mememax]

I didn't focus on the "case" issue, as I know this can be done only via php, at least I've never fixed it via htaccess...

I assume that after the final slash we don't have anything, isn't it Cip?

[g1smd]

Case fixing can be done with a RewriteMap but if you value your sanity, a simple rewrite to a special PHP script can be just as efficient and much easier to implement.

Don't use (.+) in the middle of a pattern. It will want to match to the very end then will have to "back off and retry" hundreds of times to find a match.

Using (.+) multiple times increases the pain exponentially.

^content/([^/]+)/([^/.]+)\.html$

Read: c o n t e n t slash "not a slash one or more times" (capture in $1) slash "not a slash or period one or more times" (capture in $2) period h t m l and stop.

^content/(.+)/(.+)\.html$

Read: c o n t e n t slash "everything to the very end" and capture last part in $1.

After that, find a slash: Not found.

Dump contents of $1 and

Back up: Is this "l" a "slash"? No.

Back up: Is this "m" a "slash"? No.

Back up: Is this "t" a "slash"? No.

Back up: Is this "h" a "slash"? No.

Back up: Is this "period" a "slash"? No.

Back up: Is this preceding letter a "slash"? No.

Back up: Is this preceding letter a "slash"? No.

Back up: Is this preceding letter a "slash"? No.

Back up: Is this preceding letter a "slash"? No.

Back up: Is this preceding letter a "slash"? No.

Back up: Is this preceding letter a "slash"? No.

and again and again, working backwards until

Back up: Is this slash a "slash"? Yes.

Capture $1 value.

Read: "everything to the very end" and capture last part in $2.

After that, find a period: Not found.

Dump contents of $2 and

Back up: Is this "l" a "period"? No.

Back up: Is this "m" a "period"? No.

Back up: Is this "t" a "period"? No.

Back up: Is this "h" a "period"? No.

Back up: Is this period a "period"? Yes.

Capture $2 value.

Read: period h t m l

and stop.

Which one do you think parses hundreds of times faster?

[Cipherlad]

Many, many thanks to those who posted. Sorry for the lag time in trying out these suggestions. Just removing the front slash fixed the problem. Seriously, there's been more explanation/debate about the various wildcard methods here than in the last 50 "how to" blog posts I saw prior to posting here.

The case change was being handled by the custom taxonomy plugin. I have no idea why it worked before the migration, but not afterwards.