WordPress.org

Make WordPress Core

Opened 17 months ago

Last modified 14 months ago

#22772 new enhancement

Introduce HOMEPATH

Reported by: WraithKenny Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version: 3.5
Component: Filesystem API Keywords:
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 17 months ago.

Download all attachments as: .zip

Change History (7)

comment:1 SergeyBiryukov17 months ago

  • Description modified (diff)

comment:2 WraithKenny17 months 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

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

comment:4 WraithKenny17 months ago

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

WraithKenny17 months ago

comment:5 WraithKenny17 months 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...

comment:6 Otto4214 months 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.

Note: See TracTickets for help on using tickets.