[wp-hackers] Bad assumption on creation of ABSPATH
mikeschinkel at gmail.com
Thu Nov 13 21:15:27 GMT 2008
n/p. I know all too well what it is like to be highly frustrated by a prior
(arbitrary?) decision made in software and then the need to vent my
frustration somewhere that people who might be able to change it can here
From: wp-hackers-bounces at lists.automattic.com
[mailto:wp-hackers-bounces at lists.automattic.com] On Behalf Of Chris
Sent: Thursday, November 13, 2008 4:08 PM
To: wp-hackers at lists.automattic.com
Subject: Re: [wp-hackers] Bad assumption on creation of ABSPATH
Right after I sent the second message, I came to much the same conclusion. I
realized that changing something so established creates more problems than
Thank you to both Otto and Mike for getting me back on the right track.
- Chris Jean
Mike Schinkel wrote:
> With 20+ years of programming experience I've learned many times over
> that the direct reference of constants or global varibles causes
> exactly these and many other kinds of problems. Changing ABSPATH now
> after it has established itself would cause far more problems than
> leaving it as is and documenting the concern. It's (almost) always
> better to use functions for this kind of thing because the code in the
> function can adjust in ways that a global constant cannot.
> IMO using ABSPATH and other global constants should be deprecated as a
> best practice in favor of using functions like plugins_url() and
> -Mike Schinkel
> -----Original Message-----
> From: wp-hackers-bounces at lists.automattic.com
> [mailto:wp-hackers-bounces at lists.automattic.com] On Behalf Of Chris
> Sent: Thursday, November 13, 2008 2:38 PM
> To: wp-hackers at lists.automattic.com
> Subject: Re: [wp-hackers] Bad assumption on creation of ABSPATH
> That's good to know about the plugins_url() and plugin_basename()
> I still think that requiring the use of obscure functions (I would
> have never guessed that such functions existed) and defines that have
> been shown in the past to change, get deprecated, or be created is a
> really roundabout way of avoiding a fix that could open up an easy way
> to access the same data.
> Maybe ABSPATH wasn't intended to be used in the manner in which I'm
> trying to use it, but the way that I'm trying to use it isn't wholly
> Given the potential for change in paths starting with 2.6, I don't
> think that my desired way to use ABSPATH is without reason either.
> - Chris Jean
> Otto wrote:
>> Use this instead:
>> $this->_pluginURL = plugins_url(dirname(plugin_basename(__FILE__)));
>> I don't have a particular problem with ABSPATH, as it's not meant to
>> be used to determine a URL in any sense, only actual local paths to
>> files. You should use other defined constants or functions to do that.
>> WP_PLUGIN_URL, for example.
>> On Thu, Nov 13, 2008 at 11:32 AM, Chris <gaarai at gaarai.com> wrote:
>>> If you look at any of the high-level files of WordPress that handle
>>> setting up the environment for WP, you'll find the following:
>>> define( 'ABSPATH', dirname(__FILE__) . '/' );
>>> Does it bother anyone else that all the ABSPATH defines presume to
>>> always add a '/' as the directory delimiter?
>>> It took me a while to realize that this simple thing was the source
>>> of so many of my woes. For example, consider the following code:
>>> $this->_pluginPath = dirname( __FILE__ ); $this->_pluginRelativePath
>>> = str_replace( ABSPATH, '', $this->_pluginPath ); $this->_pluginURL
>>> = get_option( 'home' ) . '/' .
>>> This code should be a simple and straight-forward way for me to
>>> always have access to the paths and URL bases that I need when
>>> developing plugins, but it will fail horribly when run on Windows.
> source? This portion:
>>> str_replace( ABSPATH, '', $this->_pluginPath );
>>> Imagine this running on Windows:
>>> str_replace( "C:\xampp\htdocs\wordpress/", '',
>>> "C:\xampp\htdocs\wordpress\wp-content\plugins\my-plugin" );
>>> Now I have a URL base of "
>>> e ss%5Cwp-content%5Cplugins%5Cmy-plugin>",
>>> which is not at all what I was wanting.
>>> The fix that I've been employing is as follows:
>>> $this->_pluginRelativePath = ltrim( str_replace( rtrim( ABSPATH,
>>> '\\\/' ), '', $this->_pluginPath ), '\\\/' ); $this->_pluginURL =
>>> get_option( 'home' ) . '/' .
>>> Quite frankly, I find this to be unacceptable. Not only does it
>>> leave me with a sloppy relative path by having a forward slash in
>>> the middle of a backslash delimited path, but it also requires way
>>> too much
> work to derive.
>>> I think most people would agree that my original code is much more
>>> understandable and solid.
>>> Basically, I find a number of issues created by simply placing a
>>> forward slash at the end of the ABSPATH:
>>> * Makes being compatible with Windows hosts that much harder.
>>> * Puts unnecessary burden on plugin and theme developers. I'm sure
>>> that we can all agree that making things easier for theme and
>>> plugin developers is good for everyone.
>>> People may argue that I can simply use the numerous defines to
>>> construct my needed paths and url bases, but that would have its own
>>> * If I rely on the defines, then my code suddenly has dependency
>>> issues and can break depending on what version of WP it is
>>> * The beauty of my original code is that it is highly adaptable. No
>>> matter what type of folder structure, file migration, or
>>> file/directory renaming they do, the code will always know where
>>> it is and what URL will point to it. If I use defines and my
>>> plugin's name for generating a path and the user renames my plugin
>>> or puts it in a different folder, my code breaks. Sure, I can
>>> insulate against that by doing a lot of logic code, but that is a
>>> lot of work to do just to make sure that I have the right path.
>>> Sorry for my verbosity, I just wanted to make it clear that a
>>> seemingly simple thing can create a large array of issues.
>>> I really should have brought this up before as a fix may have been
>>> put in place for 2.7. Oh well... Here's hoping for a fix in the next
>>> - Chris Jean
>>> wp-hackers mailing list
>>> wp-hackers at lists.automattic.com
>> wp-hackers mailing list
>> wp-hackers at lists.automattic.com
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
wp-hackers mailing list
wp-hackers at lists.automattic.com
More information about the wp-hackers