[wp-hackers] Bad assumption on creation of ABSPATH

Mike Schinkel 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
me.

-Mike


-----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 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
it fixes.

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 
> 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\plug
>>> i 
>>> ns\my-plugin<http://localhost/wordpress/C:%5Cxampp%5Chtdocs%5Cwordpr
>>> 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' ) . '/' .
>>> $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
>
> _______________________________________________
> 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

More information about the wp-hackers mailing list