[wp-hackers] Bad assumption on creation of ABSPATH
Chris
gaarai at gaarai.com
Thu Nov 13 21:08:17 GMT 2008
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\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
>
> _______________________________________________
> 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