WordPress.org

Make WordPress Core

Opened 5 years ago

Closed 3 years ago

Last modified 21 months ago

#10609 closed defect (bug) (maybelater)

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

Reported by: pyxis630 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)

VARDUMP (1.8 KB) - added by pyxis630 5 years ago.
var_dump data when settings page is used
function_and_output.txt (1.5 KB) - added by pyxis630 5 years ago.

Download all attachments as: .zip

Change History (17)

comment:1 josephscott5 years ago

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

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

comment:2 pyxis6305 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.

comment:3 dd325 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.

comment:4 follow-up: dd325 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?

comment:5 in reply to: ↑ 4 pyxis6305 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.

comment:6 pyxis6305 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)

}

comment:7 pyxis6305 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"


pyxis6305 years ago

var_dump data when settings page is used

comment:8 dd325 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..

comment:9 pyxis6305 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.

comment:10 dd325 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?

comment:11 pyxis6305 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?"?

pyxis6305 years ago

comment:12 scribu5 years ago

  • Keywords dev-feedback added

comment:13 westi3 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.

comment:14 orionrush21 months ago

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

Last edited 21 months ago by orionrush (previous) (diff)
Note: See TracTickets for help on using tickets.