wp-content in Code is a Tell for Common WordPress Coding Mistakes

Regularly while reviewing themes and plugins, I’ll see URLs or paths that include ‘wp-content’. This is a often a hint of a WordPress coding mistake.

Consider this simple example:
<link rel="stylesheet" href="http://example.com/wp-content/themes/default/style-ie.css" type="text/css" media="screen" />

If as part of a migration or server change, WordPress ends up in a sub-directory this will break.

For file system based access, if I see ABSPATH . '/wp-content/¹ … things are likely OK, though if WP_CONTENT_DIR or similar are changed, this will also break.

I’m tempted to use the constant STYLESHEETPATH or is it TEMPLATEPATH?² But, those are static variables initialized early in the WordPress run.

I’ve been meaning to write this article for a while. Serendipitously, when I went to write a first draft of it, Mark Jaquith‘s had just published “Force CSS changes to “go live” immediately“.

In the comments, demetris suggests using STYLESHEETPATH, but Will Norris quickly points out “sure, but you still have the same problem of bypassing any plugins that may be using the ’stylesheet_directory’ hook to pull the stylesheet from some place else entirely.”

Mark’s solution beautiful illustrates how to get the the URL location of the theme’s files and also directly the URL for the main stylesheet style.css:

<link rel="stylesheet" href="<?php bloginfo('stylesheet_url'); echo '?' . filemtime( get_stylesheet_directory() . '/style.css'); ?>" type="text/css" media="screen, projection" />

What Will describes is exactly what WordPress.com depends on. We have a similar, but much more complex solution to deal with the CSS in the content delivery network (CDN) going stale on updates, and also some web browser’s with their funky caches not keeping up. Our solution is both for WordPress’s front end and dashboard (also dealing with the various ways CSS can be called or @imported).³

I do have one niggle about Mark’s solution, and it’s the same with most WordPress code out there, the use of bloginfo(). Strings within strings within strings within strings give me headache, so to ease readability and make it more verbose replace:

bloginfo('stylesheet_url'); with
echo get_stylesheet_uri();

bloginfo('stylesheet_directory'); with
echo get_stylesheet_directory_uri();

If you look up in the codex get_stylesheet_directory() you’ll see that would be the file system path, which is confusing given the behavior of bloginfo('stylesheet_directory'); returning the URL. This presents another reason why I favor the consistency of always using the specific getter function calls. Also, when I’m using bloginfo() calls, I have a tendency to get in a mind set where I think I’m directly retrieving the option in the database (accessing directly the info shown in wp-admin/options.php). By using the specific getter function, I remember that there are hooks (actions, filters) that might be triggered.

Some of the other areas, I see wp-content is in CSS style sheets themselves. Relative paths are almost always the correct solution.

Far more painful for me are the plugins that assume where plugins are, because this can take quite a bit of debugging to unwind the assumptions.

That is a topic for me to postulate on another day. Will has written the very relevant “WordPress Plugin Pet Peeve #2: Direct Calls to Plugin Files“. Duane Storey has taken a crack at a “WordPress Plugin Checker“  for these and other common problems (which I’m certain he would enjoy feedback on).

1. Recent in my PHP education is the desire (style) to always use absolute paths for PHP files because from the command line everything is relative to the current directory [↩]
2. Style sheet and it’s path are your current active theme, therefore template path must be the same, or the base theme if your theme is a child theme. [↩]
3. If anyone does publish a plugin based on the suggested solution in Mark’s post, let me know if you want a copy of the WordPress.com code (so you can generalize Michael Adams‘s [mdawaffe] code). [↩]