Wordpress 403/404 Errors: You don't have permi

问题:

Some background:

I setup six blogs this week, all using Wordpress 2.92, installed with Fantastico on a baby croc plan with Hostgator.

I used the same theme (heatmap 2.5.4) and plugins for each blog.

They were all up and running, no issues at all.

I go to create a new blog this morning, using the same setup, and when I try to change the theme settings, I get the following error:

Forbidden

You don't have permission to access /wp-admin/themes.php on this server.

Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request.

Apache/2.2.15 (Unix) mod_ssl/2.2.15 OpenSSL/0.9.8n DAV/2 mod_fcgid/2.3.5 mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635 Server at http://www.mydomain.com Port 80

I tried uninstalling WP and doing a clean install, still the same issue with a clean installation.

So I went back and checked the six other blogs that I had setup over the last week or so, and they are also now giving me 403 or 404 errors when trying to change theme settings, and everytime there's an error it points to either themes.php or functions.php

At this point I'm at my wits end trying to figure out what the problem is. Hostgator support looked at it and thought maybe it was a permissions issue but they reset those and I'm still having the problem.

At first I thought the problem might have been related to a plugin I recently installed on the previous six blogs that morning (ByREV Fix Missed Shedule Plugin) to deal with a missed schedule bug with WP 2.92, and that maybe that had mucked things up. But then I checked a blog I built months ago, also using the same theme and plugins, and now it too is also encountering the same problem.

Any ideas? I tried deleting my htaccess, uploading a blank one, uploading one with this snippet I found on the hostgator forum:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

# END WordPress

Nothing has worked. I still get 403 or 404 errors everytime. Everything was working perfectly yesterday so I know this setup DOES WORK, I've just mucked something up somewhere and I'm clueless what it is.

I read a related thread here and tried chmoding the wp-content folder to 0755 and still having the issue.

Any thoughts? Thanks!

回答1:

The first error you're getting - permissions - is the most indicative. Bump wp-content and wp-admin to 777 and try it, and if it works, then change them both back to 755 and see if it still works. What are you using to change folder permissions? An FTP client?

回答2:

A few years late, but I have a solution for the most recent version of WordPress, which has this same issue (WordPress-generated .htaccess files break sites, reuslting in 403 Forbidden error messages). Here's that it looks like when WordPress creates it:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

# END WordPress

The problem is that the conditional doesn't work. It doesn't work because the module it's looking for isn't .c, it's .so. I think this is a platform-specific, or configuration-specific issue, where Mac OS and Lunix Apache installations are set up for .so AKA 'shared-object' modules. Looking for a .c module shouldn't break the conditional, I think that's a bug, but it's the issue.

Simply change the mod_rewrite.c to mod_rewrite.so and you're all set to go!

# BEGIN WordPress
<IfModule mod_rewrite.so>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

# END WordPress

回答3:

We found the asnwer of at techieshelp..its the htaccess thats the issue...

http://www.techieshelp.com/you-don%E2%80%99t-have-permission-to-access-wp-adminpost-php-on-this-server/

回答4:

Just to follow up, problem solved! I mentioned mod_sec settings for my server as being the possible culprit as suggested and they were able to fix this issue. Here's what the tech agent said to tell them when you go to support:

Just let them know you need the rule 340163 whitelisted for domain.com as its hitting a mod_sec rule.

Apparently you will need to do this for each domain that is having the issue, but it works. Thanks for all the suggestions everyone!

回答5:

You're in luck bud...I had the same issue but had more tech knowledge on the matter and was able to determine that it was a mod_sec issue that hostgator has to fix/whitelist on their own. You cannot do it yourself. Simply ask the hostgator tech to check mod_sec settings on your server.

Enjoy your fixed issue ;D

回答6:

Did you try:

<Directory /path/to/your/wp-admin>
Order allow,deny
Allow from all
</Directory>

回答7:

Hopefully people will find this answer as there are many, many posts about this on the web. Many people suggested it was an .htaccess problem, and for me it was. However, I had been looking in the .htaccess in the root, not in the .htaccess in the wp-admin folder. Normally, I work on this site in particular through terminal services, so when it booted me and I couldn't log back in, I was trying to access it from my home computer (and it's IP).

Silly me forgot the IP restriction I had placed in the wp-admin .htaccess file.

AuthName "Protected"
AuthType Basic
<Limit GET POST>
order deny,allow
deny from all
allow from 11.11.11.11
</Limit> 

If you have something like this in your wp-admin .htaccess files, that would easily explain why all the sites you work on ceased to function at the same time. Internet providers occasionally rotate IPs so that nobody is running a server from home without paying for it.

回答8:

I had the same problem, but nothing above worked...try a really simple solution...

Back up your .htaccess file. Delete it from your root directory. Then try accessing those directories. Its likely that whatever rewrite conditions you had in your file were causing those access issues. The index page should be picked up automatically on most hosts. :P