.htaccess Conflicts?

wordpress

#1

I don’t know if I should be posting this here or under “Programming,” but here’s my problem:

I have my site up to block display of indexes when there’s no main index file. However, I want to password-protect a certain directory, but when I set that up, it doesn’t work (it brings up the 404 Error document). If I put the lines from the .htaccess file from that directory to the main .htaccess file in my root dir, I get the password prompt, but it comes up for any access to my site.

I use WordPress on my site, which puts a bunch of Rewrite rules in the main dir (root) .htaccess file. Could that be a problem?

I’d really appreciate any help. Thank you.

Jen
http://www.SassyDevil.com/


#2

Hi, Jen!

We haven’t seen you around these parts in quite a while, so it’s good to see your post (and I think this category is as good as any for your questions). :wink:

You are exactly correct about the .htaccess files in the various directories conflicting with one another. The problem is that .htaccess files effect the directory they are in and all directories below them in the directory tree.

This is what allows the .htacess lines that block the display of indexes when there’s no index file, when placed in an .htaccess file in your main dir (yourdomian.tld or root) directory, to work for all the directories in your site.

The problem is that the WordPress Rewrite rules in the main dir (root) .htaccess file also impact the directories below that directory. The result of this behavior is that your .htaccess file that controls the password protection for a subdirectory (and is placed inside that subirectory) is never going to be read or “triggered” unless your url manages to get past the rewrite rules.

From your description of the problem, I suspect the directory you are trying to protect is beneath the directory that holds your WordPress root, but is not a part of your WordPress installation, so requests for that directory are “intercepted” by the rewrite rules. If it was a part of your WordPress install, the rewrite rules should let the browser through to the directory, where the .htaccess file that contains the authentication directives would be read, and you would be presented with the apache http authentication dialog box.

There are two ways you could address this issue; which one works best for you is largely a matter of personal choice/preference, depending upon what you want to do and how you want to structure your site.

  1. You can modify the WordPress generated rewrite rules in your main web accessible dir (yourdomain.tld) to allow for the “target” subdirectory to be accessed even though it is not a part of your WordPress installation.

There are instructions for doing this in the Dreamhost wiki article on making stats available with .htaccess in WordPress installations and similar discussion regarding the same situation as it relates to other common applications in this more general Dreamhost wiki article on mod-rewrite.

By reviewing these articles, and substituting the directory you are trying to access for the “stats” directory in the examples, you can apply the code examples there to your situation. Making those changes to the “main” dir’s .htaccess rewrite rules will allow browser requests to reach the protected directory, triggering the authentication directives in that directory’s .htaccess files.

  1. The second approach is one that many find simpler, as it does not require “tweaking” the WordPress generated rewrite rules (keeping your WordPress installation “stock”), and avoids the cascading interaction of the .htaccess files. It is very easy to simply use a subdomain for your protected area, which moves the whole private directory and authentication process outside the main domain’s directory tree.

Just go to the Control Panel–>Manage Domains screen and “add a new Domain /sub-domain”. Establishing a “private.yourdomain.tld” subdirectory (my daughter uses “utr.herdomain.com” for “Under the radar” - of course, you can use any name you want for the “private” part of the subdomain as long as it is not one of the “standard” DH reserved names like “webmail”, etc.), keeps everything separate and easy to manage, costs nothing extra at DH, and can still be easily linked from within your WordPress site. Make it “fully hosted” and give it time to be set-up, then use the Control Panel–> Goodies–> htaccess/webdav screen(s) to make that directory (“whateveryouchose.yourdomain.tld”) password protected.

Hopefully, one of those methods will point you in the right direction to get it sorted. If not, post back letting me know what you don’t understand or with any questions you may have, and I’ll try to give some better instructions or explanations. Good Luck! :slight_smile:

–rlparker


#3

Thanks, rlparker! I’ve been cutting down on my Internet activities to try to make time to read and write and get some other things done that will give me a better chance of reaching my dreams. I love chatting and doing stuff online, but it won’t help me accomplish my goals. I hope to peep in here now and then, though. :slight_smile:

I’ll give your suggestions a try and get back to you, to let you know if they worked, or if I need further help. Thank you so much!

Jen
http://www.SassyDevil.com/


#4

Hey! Just popping in to let you know the subdomain thing worked! Thank you so much!

Jen
http://www.SassyDevil.com/


#5

Good deal, Jen! I’m glad you got it set-up the way you want. :slight_smile:

–rlparker


#6

I was having a Wordpress vs. WebDAV upload permissions problem and finally found a solution. Just want to post this here to help anyone else who stumbles on this problem, too.

For Wordpress 2.1, the htaccess rewrite rules in the Dreamhost wiki article do not work. Perhaps another rule might, but I gave up on it and instead downloaded a nice Wordpress plugin called WebDAV Publish Enabler.

I followed the directions for the plugin, added my WebDAV enabled directories to the plugin’s options and ALSO included my web root folder. For all shared-hosting Dreamhosters, this would be the directory named www.yoursite.com.

This was what finally worked for me. Hope this helps anyone else having WebDAV permissions problems.