I was reading an article on Sitepoint about custom write panels the other day when I got heavily annoyed. The direct reason for this was one of their code examples and the authors apparent incomplete knowledge of the WordPress API’s most basic functions and constants. In that example, he does the following:
define( 'MY_WORDPRESS_FOLDER', $_SERVER['DOCUMENT_ROOT'] ); define( 'MY_THEME_FOLDER', str_replace("",'/',dirname(__FILE__)) ); define( 'MY_THEME_PATH', '/' . substr( MY_THEME_FOLDER, stripos(MY_THEME_FOLDER,'wp-content') ) );
That annoyed me, quite a bit. Why? Well because if people write articles about stuff like custom write panels, I expect them to know a bit about the basics of the WordPress API. And well, the WordPress API has constants and functions for these things. So let me introduce you to them in the same order as the author of the articles did his defines above:
Not only is their method inconvenient, it’s wrong for a lot of installs. You see, some people install WordPress in a subdirectory, and depending on what you need, there are two different paths you might need.
ABSPATH is a constant that always returns the home of WordPress. So if WordPress is in the
wp/ subdirectory, it would give you something like:
/home/username/public_html/wp/. If WordPress were installed in the root, it would just return
/home/username/public_html/. Now I don’t know how they’re using it, as it’s not used in this particular article, but they’d have to be very cautious with that.
The second two things they’re doing are possibly even weirder. First they define a constant
MY_THEME_FOLDER, which is basically the path to the current theme. WordPress has a very convenient constant for that:
TEMPLATEPATH. Since they’re using it in an include, that’s probably what they need. Would save about 4 lines of code. Note that what they call a “folder” is actually a path.
This is were they really go wrong. You see, they define a constant
MY_THEME_PATH, and then use it as a URL in a call to
wp_enqueue_style(), in other words: to enqueue a style sheet. Now paths and URLs are different animals altogether, and they don’t mix well. Take this example:
- My blog is installed in a subdirectory
- Because of that
MY_THEME_FOLDERhas been defined as follows:
- The code that sets
MY_THEME_PATHturns that into:
- The stylesheet is now included with the following path:
- This causes a 404 (file not found error) because that directory simply doesn’t exist! It should have been:
The proper way of doing the enqueue would thus have been the following:
wp_enqueue_style( 'my_meta_css', get_template_directory_uri(). '/custom/book_panel.css' );
I hope you understand why this annoys me. This is exactly the kind of coding that gives WordPress coders out there a bad name, as 5 – 10% of people out there trying this will not get it to work. If you want to prevent from making such mistakes, there’s plenty of resources to learn about these things, or look them up. Two starting points would be the codex and my own cross reference of the WordPress source along with its very convenient WordPress source search function.