Wordpress Problem with my htaccess file

[mkingsle]

Hello Everyone:

Seems like nothing works for me the first go around, and Wordpress is my latest hiccup in my quest to learn web design.

I'll try to summarize what I've done thus far:

1.) I installed wordpress in a sub-directory to use as a blog for the site.

2.) At first, I was not able to log in at all ( It would just refresh the page.)

3.) Discovered it was conflicting with my htaccess file somehow. ( I know this because when I removed it from the server I was able to log in just fine. )

4.) Using the process of elimination, I was able to discover the code that is giving the problem:

# Redirect direct client requests to remove .php extensions
RewriteCond %{THE_REQUEST} ^[A-Z]+\ /[^?#\ ]+\.php([?#][^\ ]*)?\ HTTP/
RewriteRule ^(.+)\.php$ [http://www.mywebsite.com/$1] [R=301,L]

This is where I get stumped. The rule works just fine for my website, which I've had running for over a year, but does not interact well with wordpress. I don't get why?

JDMorgan was nice enough to help me by providing the above solution, which strips the php extension, which is what I want.

I've researched this on Google, and it seems no one is having this problem, so maybe I need to rewrite the rule somehow or...is it possible that I could put another htaccess file in the subdirectory and somehow turn off the rewrite engine?

Any help is greatly appreciated.

Michael

[jdMorgan]

I would guess that your WordPress configuration is set to link to "/index.php" instead of "/", and the resulting requests are triggering the "remove .php" redirect. This later causes problems inside the WP script(s) that examine the client-requested URL-path, expecting "/index.php" but seeing only "/".

The best solution would be to change the WP configuration to to link to and expect only "/" in requested URLs.

The less-desirable and more problematic solution would be to exclude requests containing the path to the WP subdirectory (if you have one) from all of your rewriterules.

This could also be a problem with rule scope or rule order. Make sure you've ordered your rules properly (see the recent thread in our Apache Forum Library), and be sure that your RewriteRule patterns are as specific as possible without being too selective.

The "remove .php" rule will only be invoked if the client requests a URL ending in .php. So either one or more of your other rules or one of the WP scripts is publishing a link to "<something>.php" or is redirecting to "<something>.php". In either case, this is incorrect: Your site must always link to the 'final' and 'correct' URL, and you cannot rely on a redirect to "fix this." Such a redirect is only good for "fixing" incorrect/obsolete links coming from *other* Web sites by speeding up their replacement in search engine results listings, and by helping to prevent other Webmasters/bloggers/forum-posters from linking to the incorrect URLs with .php on the end.

Jim

[mkingsle]

I had trouble understanding your post. Way over my head.

My solution was to add an .htaccess file in the same directory as wordpress, and with the following:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine Off

</IfModule>

# END WordPress

Works for me.

[mkingsle]

Ahhh... works until i want to change the permalink structure. Nag dabit!

Any help would be appreciated.

[jdMorgan]

You really need to identify the specific problem first, before "trying" a bunch of fixes. Otherwise, this is like pouring more oil into the top of the engine instead of fixing the leak that's causing the oil to run out every day.

By disabling mod_rewrite in the WP subdirectory, you have disabled all of the rules in the main .htaccess file. And note that I just said *all* of the rules. And this appears to "fix" most of your problems. The question is, "Why?"

Knowing the answer to that will lead you to a more correct and likely a more elegant solution.

The rule that you posted about invokes a redirect to remove the .php file extension from URL-paths which are requested directly by clients (only). It will not be invoked as a result of any internal rewrites. So this is evidence that your WP code is publishing links to URLs ending in .php (which is also incorrect), and further, that it requires those links to end in .php and won't work without them. It also implies that the rule which rewrites requests to the WP script may have a flaw, but that rule is not posted here, so I cannot comment further.

Jim