[wp-hackers] Bad assumption on creation of ABSPATH

[Chris]

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\plugins\my-plugin<http://localhost/wordpress/C:%5Cxampp%5Chtdocs%5Cwordpress%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
>
>