Changing permalinks causes 500 Server Error

To see why you get a 500 error you need to look at the error logs on your server. Depending on your account type these may or may not be available to you, but your hosting company will be able to see what’s happening.

The first thing that I’d suggest is to check to see that your hosting server does actually allow .htaccess files and can process them correctly. Some servers don’t, and some hosting providers do block these in different ways.

perhaps the actual error would help narrow down the cause, try adding that to your post, did you do a google search for the error you received cause sometimes that can help with diagnosing the cause. Have you also tried rebooting your modem? temporarily disabling security software? try the steps in this article

I hope that helps you out, I can totally relate with how frustrating these issues can be especially when the computer doesn’t really tell you why its sick, it just is if you know what I mean

do you have frontpage or frontpage server extensions installed?
this looks like it might be relevant.
Finally, A solution.

There have been a number of threads on this issue in the support forums, and until now, no solution to the problem.

Normally, on a Unix server with the Microsoft FrontPage Server extensions installed WordPress works just fine and you are able to edit and publish pages (with Microsoft FrontPage) — until — you make a change to the permalinks (for example to the date based kind that I like /2005/04/etc). I often suggest that type of URI to folks asking about permalinks etc, as that is the method recommended by the w3c (see http://www.w3.org/Provider/Style/URI ).

Now, the problem is that FrontPage uses the .htaccess file (which the WordPress mod_rewrite rules must access) for its “publishing” and “web authoring” configuration. As soon as the WordPress mod_rewrite code is added to the file, two things happen — the permalinks don’t work and the Frontpage Server extensions become corrupt.

I have tried countless ways to get around this, including trying to use rewrite rules that “ignore” the %{HTTP_USERAGENT)% used by FrontPage, to using a second AccessFilename .wpaccess to the httpd.conf file, and a host of other things, and nothing worked to allow use of FrontPage and management and use of permalinks in WordPress at the same time.

The solution is actually simple, and I figured it out by accident.

If you are using, or wish to use FrontPage (or if your hosting package is pre-configured that way) along with WordPress, you’ll need to take the following simple steps on your server or have your hosting company do them for you.

Microsoft FrontPage creates the following directory
_vti_bin
Nested within that it creates both _vti_adm
and _vti_aut

In addition to in your site (or WordPress) root folder in all of those directories you will find additional .htaccess files.

In all three of these directories AND in the root directory, at the top of ALL of the .htaccess files you simply need to add one line:
Options +FollowSymlinks

There may or may not already be a line in each like
Options None

Edit and save each .htaccess file and you’re done. Now everything works perfectly, including FrontPage, AND the permalinks of your choosing.

As we’ve said all along…

perhaps the actual error would help narrow down the cause

Without knowing the actual error that you’re getting it’s impossible to diagnose what could be wrong. The error will be in your servers error logs. If you can’t find them your hosting company will be able to help.

RewriteEngine not allowed here

It’s a server problem, Apache (or your server software) doesn’t like how the. Soemthing in your .htaccess file isn’t set right, and if there’s no .htaccess file in the site, your server is finding one that’s wrong somewhere – from the error I’d say in the folder F:/WebDev/mysite/v005wp/ so please look there.

For some reason your server believes that there’s a .htaccess file in that folder. I have seen it happen before where it’s been there but hasn’t been visible because the server is set to ignore “hidden” files (hidden files are defined by their file name startign with the full-stop like this). I’ve missed a few of them myself thanks to incorrect settings on file and FTP browsers. All that I can say is that your server does believe that the file exists if it really isn’t there, so you’ll need to figure out why that is. That’s a server problem.

If you think that the file at wp-includes/vars.php is not correct them re-download a new un-touched copy of WordPress and re-install that file. If there is a problem with that I’d suggest doing it with every file.. if one’s been changed somehow then there’s no telling if any others have or have not been affected as well.

I’m sorry that you’re getting frustrated, but there’s really not much else that can be done.

The same error is returned.

Is your server still telling you that there’s an error with the .htaccess file in that directory? As that was the only error message that you’ve given us so far it’s really hard to see any other issue. If the file isn’t there, then your server has a problem and thinks that it’s there. I’m not sure what could be done about that as there’s no way for anyone here to see what’s happening on the server.

I do admit that it is very strange that it’s happening both locally and on the live server. Unless they are exactly the same setups normally one or the other will be a problem, but not both. Again, without access to the server, that’s very hard to try and diagnose because we just don’t have any way of seeing what’s going on under the covers there.

There is a good chance that the documentation is out of date. The codes pages are all run the same way that the forums are, by volunteers, so things can get out of date and need to be updated by people that see this. From what I’ve seen here, yes that code is out-dated, but the basis of it all is still there, and it’s only commenting out one line and adding in a line to force $is_apache to be true. That’s all pretty easy to do.