[wp-hackers] Bad assumption on creation of ABSPATH

[Mike Schinkel]

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
plugin_basename().

JMTCW.

-Mike Schinkel 
http://mikeschinkel.com/custom-wordpress-plugins/


-----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() functions.
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 unreasonable.
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->_pluginRelativePath;
>>
>>
>> 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. The
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 "
>> http://localhost/wordpress/C:\xampp\htdocs\wordpress\wp-content\plugi
>> ns\my-plugin<http://localhost/wordpress/C:%5Cxampp%5Chtdocs%5Cwordpre
>> 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' ) . '/' .
>> $this->_pluginRelativePath;
>>
>>
>> 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
problems:
>>
>>   * If I rely on the defines, then my code suddenly has dependency
>>     issues and can break depending on what version of WP it is running
on.
>>   * 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
release.
>>
>> - Chris Jean
>> _______________________________________________
>> wp-hackers mailing list
>> wp-hackers at lists.automattic.com
>> http://lists.automattic.com/mailman/listinfo/wp-hackers
>>
>>     
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>
>   
_______________________________________________
wp-hackers mailing list
wp-hackers at lists.automattic.com
http://lists.automattic.com/mailman/listinfo/wp-hackers