First, let me tell you how I’m currently doing it. I have this function. It’s purpose is to take the the string of a file system path (/root/web/dir/some/path/to/file) and return the equivalent URL (http://mydomain.com/some/path/to/file). In order for this function to work properly, it needs to know where the root web directory (RWD) is on the system. It does this by assuming $_SERVER[‘DOCUMENT_ROOT’] as the RWD.
function path_to_url($path)
{
$path = str_replace('', '/', $path);
$doc_root = str_replace('', '/', $_SERVER['DOCUMENT_ROOT']);
return 'http://'.$_SERVER['HTTP_HOST'].'/'.str_replace(' ', '%20', str_replace($doc_root, '', $path));
}
Please learn this function and know
what it does in order to understand
what I’m talking about in this post.
With this function, all I would need to know in order to include a script/stylesheet on my page is it’s path. I would be writing code that looks something like:
wp_enqueue_script('myscript', path_to_url(dirname(__FILE__).'/script.js'));
This worked fine, in fact, it worked so well that I started to use path_to_url in a lot of places in my theme.
There’s one reason why this solution doesn’t work in some circumstances. Some shared hosting sites (bluehost) don’t have $_SERVER[‘DOCUMENT_ROOT’] set to the RWD as I expected and assumed it to be. Bluehost seems to always have it set to “/usr/local/apache/htdocs” which does not correlate with the paths I use within PHP — “/home1/demo/public_html/wp-content/themes/…”. So I must either give a work around to those most unfortunate to have $_SERVER[‘DOCUMENT_ROOT’] set to something as incorrect (at least to my knowledge of it seeming to be incorrect) as the above, or I should figure out another means of doing what I want/need to do.
The solution would be to somehow correct $_SERVER[‘DOCUMENT_ROOT’]. But this doesn’t seem like a valid solution for my customers. They would need to submit a support ticket notifying me that my theme isn’t working. Then I would need to reply with a message on how they can fix the issue. But before I could simply reply to them with a solution, I will need to know their RWD somehow. This would be a very cumbersome solution and would require more time and effort then seems practical.
So I’m left with the second solution — figure out another means of doing what I need to do. While writing this I figured that I could go with the hard-coded approach, and maybe that’s the only way to go about this problem.
wp_enqueue_script('script', get_bloginfo('template_url').'/lib/framework/panel/script.js');
After all my explanation, this seems like a no-brainer. But the only quarrel I have with this is how rigid it is. For example, if I decide to move my script.js file around, I’ll need to edit this code, no matter what. What I like about the above path_to_url solution, is that if I moved the script.js and the php template file, nothing breaks; so long as the script.js file stays in the same folder as the php template file. In fact, what I was doing with the path_to_url solution is making things relative again, relative to the php template file!
Unfortunately though, I realize that it is not practical to expect there’s one formula for converting all file system paths on all systems to URLs. This is due to the fact that there are different server configurations that make it impossible for one formula to know the RWD in a path. For example, one server could have a setup where wordpress is installed under http://example.com/~demo/ and the RWD would be /home1/demo/public_html/. Thus there’s no way I can get the RWD our of __FILE__ with this kind of setup. How could I?
I hope you found this post/question interesting. I’ll leave you with this question: How can I make wp_enqueue_script('script', get_bloginfo('template_url') . '/lib/framework/panel/script.js');
more relative and less rigid?
Thanks guys. Peace!
Do this at the head of your functions.php:
define('PATH_TO_URL', get_bloginfo('template_url') . [path to your libraries, etc.]);
Then, just call
wp_enqueue_script('script', PATH_TO_URL . 'myscript.js');
or similar anywhere you want. If you change the location, just change the define() and it’ll update everywhere.Easy peasy.