Today I noticed a strange WordPress behavior. Not on this instance but on a client site that was about to be pushed live.

The client site is hosted on a webserver where PHP is used in FastCGI mode. This means the PHP scripts run with user rights, which seems to contribute to the problem described below. I could not repeat the same behavior with a Linux setup where PHP runs as an Apache module. In this case PHP scripts run under the apache user which is an unprivileged user that simply cannot write files into the account root.

In order to get the client’s site ready for prime time I changed the URL settings in the ‘General Settings’ section. I hit submit and Bang! 500 error. Nothing worked. Not WordPress, not non WordPress parts of the site.

It turned out that WordPress wrote the .htaccess file into the account root and not the website root. I could repeat this behavior on the same setup and also on a test setup on my work PC. On this Windows machine I have a XAMPP setup and WordPress wrote the .htaccess file directly into c:\.

I do not really understand why WordPress rewrites the .htaccess over and over in the first place. But I’m sure there is a good reason for this. I just didn’t find it yet.

I filed a bug report at core.trac.wordpress.org. The ticket number is 10609. It looks like other folks have experienced similar issues.

If you experienced something similar, head over to Trac and add your comment. This is something that needs to be fixed.

Update:

I was doing some tests and the problem seems to be in the function get_home_path() in wp-admin/includes/file.php

In line 73: $pos = strpos($_SERVER [ "SCRIPT_FILENAME" ], $wp_path_rel_to_home);

the code tries to get the position of a string in a filename. On a Windows XAMPP system this looks like:

$pos = strpos(“C:/websites/SITE/wp-admin/options.php”,”http://SITE.com”);

$pos will be empty in that case. The resulting $home_path will be empty also, resulting in $home_path = ‘/’;  (code: $home_path = trailingslashit( $home_path );)

Now WordPress will write the .htaccess file into the account root, if it has permission to do so. On a Windows system this is very likely C:\

On a Linux system only the root user can write into the root directory, so the server, no matter if it runs PHP as the apache user or the account owner, will in most cases not be able to write anything into root. On some VPS  like setups however, the user can write into his/her own account root, and here WordPress can, if PHP runs in CGI mode, write the file into the account root.

Now I wonder why the WordPress developers don’t just use $_SERVER[ "SCRIPT_NAME" ] instead of $wp_path_rel_to_home?

The result would look like this:
$pos = strpos(“C:/websites/SITE/wp-admin/options.php”,”/wp-admin/options.php”);

and would actually return a $pos that could be used to generate the correct path for WordPress.