WordPress.org

Make WordPress Core

Opened 7 years ago

Last modified 5 months ago

#22772 new enhancement

Introduce HOMEPATH

Reported by: WraithKenny Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.5
Component: Filesystem API Keywords: needs-patch
Focuses: Cc:
PR Number:

Description (last modified by SergeyBiryukov)

I was poking around with get_home_path() and wondering if there's any reason to not set a constant HOMEPATH (like ABSPATH) in the root index.php

I'd seem to be more reliable then get_home_path() and that function could simply return the new constant.

get_home_path has it's origins 8 years ago when the code was very different: [1567]

Attachments (1)

22772.patch (524 bytes) - added by WraithKenny 7 years ago.

Download all attachments as: .zip

Change History (8)

#1 @SergeyBiryukov
7 years ago

  • Description modified (diff)

#2 @WraithKenny
7 years ago

(thanks Sergey)

Alternatively, it could be named WP_HOME_DIR to fit the other constants: http://codex.wordpress.org/Determining_Plugin_and_Content_Directories#Constants even though WP_HOME isn't WP_HOME_URL...

Another alternative is to not set the constant in the root index.php but leave the check in get_home_path so that it can be set instead in the wp-config.php

#3 @nacin
7 years ago

Say you have:

index.php
/wordpress
     index.php

The first one is copied from the second one. The problem is, they both have HOMEPATH. Then what happens when you hit /wordpress/ or /wordpress/index.php directly?

This is probably a good candidate for a constant you can define.

#4 @WraithKenny
7 years ago

Yeah, that patch was terrible. Working on a better one.

@WraithKenny
7 years ago

#5 @WraithKenny
7 years ago

Tested it this time instead of doing it live. It's set just like ABSPATH (define('HOMEPATH', dirname(__FILE__) . '/'); or whatever works for the setup) in wp-config.php and doesn't bother to try and set from the root index (since that isn't loaded by wp-admin, :-/ my brain misfired there). If it's set get_home_path() simply returns it. Not sure how to do a unit test for something like this tho...

#6 @Otto42
7 years ago

Additional note: I was playing around with my Synology Diskstation today, and noticed that they had not upgraded their WordPress package past 3.4.2 yet. So I downloaded it and opened up a copy. They have a change to core to deal with this for their specific case.

Essentially, they modified get_home_path() to have this:

if (defined('SYNOWORDPRESS')){
	return csSYNOWordPressMisc::get_home_path($home, $siteurl);
}

and then they have an extra file loaded in the wp-config which does this:

class csSYNOWordPressMisc {

	static function get_home_path($home, $siteurl) {

		$root_dir = '/var/services/web';
		if ( $home != '' && $home != $siteurl ) {
			$siteDomain = substr($siteurl, 0, -9);
			$home_path = $root_dir . "/" . substr($home, strlen($siteDomain)) . "/";
		} else {
			$home_path = ABSPATH;
		}

		return $home_path;
	}
}

This is because of their system design where the location of the WordPress install doesn't necessarily correspond to the URL as such. It comes with a couple extra plugins to allow them to change the URL of the site without moving around the files through some device-specific stuff.

A constant or something along these lines would probably allow them to use the WordPress package without the core change, meaning they could more easily stay up-to-date.

I didn't spot any other core changes, but I haven't done a full compare yet.

#7 @chriscct7
4 years ago

  • Keywords needs-patch added
Note: See TracTickets for help on using tickets.