[wp-hackers] Bad assumption on creation of ABSPATH

Otto otto at ottodestruct.com
Thu Nov 13 18:20:28 GMT 2008


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
>


More information about the wp-hackers mailing list