WP writes htaccess file in account root when changing the URL in the admin area

[pyxis630]

When I changed the URL settings in the General Settings area from a temp value to the final one WordPress re-wrote the .htaccess file into the account root instead of the website root. I could repeat this successfully. Subsequently the website didn't work (500 error).

I also could repeat this behavior on a XAMPP setup on my Windows PC. The WP setup I used for testing this wrote the .htaccess file directly into c:\

The website account is a VPS like setup where PHP (5.2.9) runs in cgi mode (Linux server).

Looks like this bug happens when the system runs in CGI mode. I could not repeat this on a test setup on a Linux server that uses php_mod instead.

[josephscott]

From the comments I think this also explains what I saw here with MAMP -

​http://josephscott.org/archives/2009/07/mamp-start-page-error/

[pyxis630]

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 = '/'; ($home_path = trailingslashit( $home_path );)

Now WordPress writes, if it has permission, the htaccess file in the root of the account. On this Windows setup this is C:\

Can $_SERVER[ "SCRIPT_NAME" ] be used instead of $wp_path_rel_to_home?

It would look like this:
$pos = strpos("C:/websites/SITE/wp-admin/options.php","/wp-admin/options.php");
and return a position for $home_path.

[dd32]

Can you post a var_dump() of $_SERVER ?

I don't have a CGI setup i can test on, so would like to cheat and simulate it.

[dd32]

Actually.. looking at it:

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

should never happen, as there shouldnt be a http:// in that last part...

Whats your Site URL and Home URL set to? Is one SSL'd and the other different? Or is homeurl not contained within siteurl?

[pyxis630]

Replying to dd32:

Actually.. looking at it:

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

should never happen, as there shouldnt be a http:// in that last part...

Whats your Site URL and Home URL set to? Is one SSL'd and the other different? Or is homeurl not contained within siteurl?

Site URL and Home URL are both the same. This is the case for my test system which is a Windows XAMPP setup as well as on the clients site which is a Linux server that uses a VPS like setup. Just regular HTTP no SSL.

[pyxis630]

Here is a var_dump from a similar system (Red Hat, PHP in CGI mode, same setup as client site). I don't have access to the other 2 right now. Same thing here, WP writes the htaccess file in the account root when the .

array(33) {

HTTP_HOST?=>
string(26) "www.domain.com"
HTTP_USER_AGENT?=>
string(95) "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.2) Gecko/20090730 SUSE/3.5.2-1.1 Firefox/3.5.2"
HTTP_ACCEPT?=>
string(63) "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8"
HTTP_ACCEPT_LANGUAGE?=>
string(14) "en-us,en;q=0.5"
HTTP_ACCEPT_ENCODING?=>
string(12) "gzip,deflate"
HTTP_ACCEPT_CHARSET?=>
string(7) "UTF-8,*"
HTTP_KEEP_ALIVE?=>
string(3) "300"
HTTP_CONNECTION?=>
string(10) "keep-alive"
HTTP_REFERER?=>
string(62) "​http://www.domain.com/wp-admin/options-general.php"
HTTP_COOKIE?=>
string(383) "wordpress_xxxxxxx"
CONTENT_TYPE?=>
string(33) "application/x-www-form-urlencoded"
CONTENT_LENGTH?=>
string(3) "499"
PATH?=>
string(44) "/sbin:/usr/sbin:/bin:/usr/bin:/usr/X11R6/bin"
SERVER_SIGNATURE?=>
string(88) "

Apache/2.0.52 (Red Hat) Server at www.domain.com Port 80

"

SERVER_SOFTWARE?=>
string(23) "Apache/2.0.52 (Red Hat)"
SERVER_NAME?=>
string(26) "www.domain.com"
SERVER_ADDR?=>
string(13) "xx.xx.xx.xx"
SERVER_PORT?=>
string(2) "80"
REMOTE_ADDR?=>
string(14) "yy.yy.yy.yy"
DOCUMENT_ROOT?=>
string(27) "/var/www/domain"
SERVER_ADMIN?=>
string(29) "email@…"
SCRIPT_FILENAME?=>
string(48) "/var/www/domain/wp-admin/options.php"
REMOTE_PORT?=>
string(5) "34157"
GATEWAY_INTERFACE?=>
string(7) "CGI/1.1"
SERVER_PROTOCOL?=>
string(8) "HTTP/1.1"
REQUEST_METHOD?=>
string(4) "POST"
QUERY_STRING?=>
string(0) ""
REQUEST_URI?=>
string(21) "/wp-admin/options.php"
SCRIPT_NAME?=>
string(21) "/wp-admin/options.php"
PHP_SELF?=>
string(21) "/wp-admin/options.php"
REQUEST_TIME?=>
int(1250457172)
argv?=>
array(0) {
}
argc?=>
int(0)

}

[pyxis630]

And here some of the _REQUEST data when I changed the Blog address to something other than the WP URL. When I change the Blog URL back to be similar to the WP URL nothing happens, it happens only when the WP and Blog URL are different (first part of the if...else). I changed IP addresses, emails and domain names for privacy reasons.

[ "option_page" ]=> string(7) "general"

[ "action" ]=> string(6) "update"

[ "_wpnonce" ]=> string(10) "2a4f67c06a"

[ "_wp_http_referer" ]=> string(29) "/wp-admin/options-general.php"

[ "blogname" ]=> string(21) "Blog Name Here"

[ "blogdescription" ]=> string(29) "Just another WordPress weblog"

[ "siteurl" ]=> string(33) "​http://www.domain.com"

[ "home" ]=> string(38) "​http://www.domain.com/test"

[pyxis630]

var_dump data when settings page is used

[dd32]

[ "siteurl" ]=> string(33) " http://www.domain.com" 
[ "home" ]=> string(38) " http://www.domain.com/test"

That is what is causing your issues.

The Site URL and Home url are supposed to be used for when the WordPress files exist in a subdirectory of where you want the home url to be.

Ie:

siteurl => http://dd32.id.au/wordpress/
home => http://dd32.id.au/

That'll cause the exact issue you're seeing I think..

[pyxis630]

Yes, when I change the siteurl to be something different than the blog url the error happens. When I change home back to be the same as the siteurl things are OK.

However, the first time I noticed this was when I changed both values from IP addresses to URLs. Both values have been identical each time (siteurl == home).

My guess is, although I didn't test it specifically, that the same thing happens when PHP runs as an apache module, but in this case the script simply has not enough rights to write anything into the account root.

[dd32]

Yes, when I change the siteurl to be something different than the blog url the error happens. When I change home back to be the same as the siteurl things are OK.

This was refering to this line of yours above:

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

That line is impossible, and the ​http://site.com is there due to a incorrect setting.

If home/siteurl are set differently, Then Siteurl should always be a subdirectory of home, NEVER the other way around.

back to the problem at hand, Can you test it while it has home === siteurl?

[pyxis630]

So WordPress address (URL) and Blog address (URL) should be the other way around you are saying? This is a bit confusing then but this is not what I tried to do in the first place. I just found this when testing.

The original issue was that the WordPress address (URL) and Blog address (URL) have been set during build out of the site to a temporary address (both the same value). In this case it was the IP address. Before the A record of the domain was switched to point to the new location I changed WordPress address (URL) and Blog address (URL) to the final URL in the format ​http://site.com. Again, both had the exact same value. In this case this error should not have happened. Is that correct?

I recreated the scenario, set my test blog to use an IP address (127.0.0.5) and then changed it to the URL (​http://site.com). In this case it looks like it is running both portions of the function, the if and the else. See the attached file function_and_output.txt I added some code to print out the variables at different times when this function is used. The result shows what happens when the URL was changed from the IP address to the URL, both at the same time.

Does the above cover your request "Can you test it while it has home === siteurl?"?

[westi]

Reading through this ticket it sounds like the underlying issue was a misconfiguration of the two url fields setting them up so they were the wrong was round.

This is unlikely to be a common issue and while it would be nice to improve the situation I don't think it is something which needs addressing in core at this point.

[orionrush]

I would like to bump this. Custom core file locations are a great development strategy, and unfortunately this issue prevents users of some themes such as 'Roots' from taking advantage of it.

​https://github.com/retlehs/roots/issues/152

[SergeyBiryukov]

Related: #10970