Make WordPress Core

Opened 11 years ago

Last modified 5 years ago

#22772 new enhancement

Introduce HOMEPATH

Reported by: wraithkenny's profile WraithKenny Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.5
Component: Filesystem API Keywords: needs-patch
Focuses: Cc:

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 11 years ago.

Download all attachments as: .zip

Change History (8)

#1 @SergeyBiryukov
11 years ago

  • Description modified (diff)

#2 @WraithKenny
11 years ago

(thanks Sergey)

Alternatively, it could be named WP_HOME_DIR to fit the other 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
11 years ago

Say you have:


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
11 years ago

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

11 years ago

#5 @WraithKenny
11 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
11 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
9 years ago

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