#10609 closed defect (bug) (maybelater)
WP writes htaccess file in account root when changing the URL in the admin area
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | Priority: | high | |
Severity: | normal | Version: | 2.8.4 |
Component: | Administration | Keywords: | dev-feedback |
Focuses: | Cc: |
Description
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.
Attachments (2)
Change History (17)
#2
@
16 years ago
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.
#3
@
16 years ago
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.
#4
follow-up:
↓ 5
@
16 years ago
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?
#5
in reply to:
↑ 4
@
16 years ago
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.
#6
@
16 years ago
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)
}
#7
@
16 years ago
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"
#8
@
16 years ago
[ "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..
#9
@
16 years ago
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.
#10
@
16 years ago
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?
#11
@
16 years ago
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?"?
#13
@
14 years ago
- Milestone Awaiting Review deleted
- Resolution set to maybelater
- Status changed from new to closed
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.
From the comments I think this also explains what I saw here with MAMP -
http://josephscott.org/archives/2009/07/mamp-start-page-error/