As it turns out, there is a major problem with the art direction plugin. Using it with any caching plugin will result in a crazy epic meltdown of your site. Without too much gory detail, in trying to cache my blog CSS-Tricks, I tried all the major caching plugins (DB Cache, WP Super Cache, W3 Total Cache) and ultimately it would trash my WordPress database and serve up white pages. Very not good. The happy ending is that Frederick Townes from W3 Edge and creator of the W3 Total Cache plugin helped me out by patching the art direction plugin and getting CSS-Tricks cached with W3 Total Cache. I would love to release the updated code, but it’s not my code to release. We managed to get in touch with the original author, who said he planed to eventually update it but didn’t sound too particularly interested in the patch.

SO, with that extensive backstory, what is a poor fellow to do if they want to apply custom CSS to pages TODAY? Couple ideas, read on.

style-XXXX.css

One of my “WordPress Wishes” was that you could drop an appropriately named CSS file into a theme and it would recognize it and apply itself to the proper post. For example, /art-direction/style-XXXX.css, where XXXX is the ID of the post.

Reader Hassan commented with a cool idea for the functions.php file:

function artStyle() {
    global $post;
    if (is_single()) {
        $currentID = $post->ID;
        $serverfilepath = TEMPLATEPATH.'/art-direction/style-'.$currentID.'.css';
        $publicfilepath = get_bloginfo('template_url');
        $publicfilepath .= '/art-direction/style-'.$currentID.'.css';
        if (file_exists($serverfilepath)) {
            echo "<link rel='stylesheet' type='text/css' href='$publicfilepath' media='screen' />"."\n";
        }
    }
}
add_action('wp_head', 'artStyle');

I tested it out and it works great. To use it, simply create a new folder called “art-direction” in your theme. Then to style any particular Post or Page, just drop a file in that folder named style-XXXX.css where XXXX is the ID of the Post or Page. When that Post or Page loads, WordPress will look for a file of that name. If it exists, it will load in in the head section.

Custom Panel

Reader Kerrick Long commented another cool solution. Similar to the Art Direction plugin, this adds an input area below the main content writing area. For the functions.php file:

//Custom CSS Widget
add_action('admin_menu', 'custom_css_hooks');
add_action('save_post', 'save_custom_css');
add_action('wp_head','insert_custom_css');
function custom_css_hooks() {
	add_meta_box('custom_css', 'Custom CSS', 'custom_css_input', 'post', 'normal', 'high');
	add_meta_box('custom_css', 'Custom CSS', 'custom_css_input', 'page', 'normal', 'high');
}
function custom_css_input() {
	global $post;
	echo '<input type="hidden" name="custom_css_noncename" id="custom_css_noncename" value="'.wp_create_nonce('custom-css').'" />';
	echo '<textarea name="custom_css" id="custom_css" rows="5" cols="30" style="width:100%;">'.get_post_meta($post->ID,'_custom_css',true).'</textarea>';
}
function save_custom_css($post_id) {
	if (!wp_verify_nonce($_POST['custom_css_noncename'], 'custom-css')) return $post_id;
	if (defined('DOING_AUTOSAVE') && DOING_AUTOSAVE) return $post_id;
	$custom_css = $_POST['custom_css'];
	update_post_meta($post_id, '_custom_css', $custom_css);
}
function insert_custom_css() {
	if (is_page() || is_single()) {
		if (have_posts()) : while (have_posts()) : the_post();
			echo '<style type="text/css">'.get_post_meta(get_the_ID(), '_custom_css', true).'</style>';
		endwhile; endif;
		rewind_posts();
	}
}

Custom CSS Write Panel

As written, it’s more limiting than the Art Direction plugin as it is for CSS only rather than “anything” (e.g. JavaScript), although that would be a fairly trivial adjustment to what gets echoed out. The Art Direction plugin also allowed the CSS to be applied in other places the post might be output, for example, archives pages, whereas this does not. But to be honest, I never used that anyway.

And so…

Two pretty sweet and totally function solutions by Digging Into WordPress readers. Awesome. Huge thanks to Hassan and Kerrick! I would also love to see the Art Direction plugin updated as well, if nothing else, because I’m sure people download that plugin every single day from the plugin repository and have caching going on their blogs and end up in the same sore spot I was.

© 2010 Digging into WordPress | Permalink | 29 comments | Add to del.icio.us | Post tags: CSS, Design, functions, header

Don’t display your WordPress version number publicly
Many WordPress developers often display the WordPress version in the source code. But having this information publicly available makes it easy for attackers to exploit known vulnerabilities on a particular WordPress version.

This sort of thinking is referred to as “security through obscurity,” and may or may not be an effective way to increase the overall security of your site.

By default, WordPress executes the wp_generator() function whenever the wp_head() hook is called. Typically, this hook is located in your theme’s header.php file within the <head> section of the document markup:

The wp_head() hook as seen via the header.php file

Then, after WordPress processes your web page, the wp_generator() function outputs the following code (depending on page view) to your browser:

<link rel="EditURI" type="application/rsd+xml" title="RSD" href="http://digwp.com/xmlrpc.php?rsd" />
<link rel="wlwmanifest" type="application/wlwmanifest+xml" href="http://digwp.com/wp-includes/wlwmanifest.xml" /> 
<link rel='index' title='Digging into WordPress' href='http://digwp.com/' />
<meta name="generator" content="WordPress 2.8.1" />

Notice that last line there? There are many posts on WordPress security that point out how specifying your version number is a security risk. Whether or not this is the case is certainly debatable, but the thinking is that you should avoid revealing this sensitive information in order to prevent attacks targeting specific versions of WordPress.

Now for the fun part. Assuming that sharing your version information is bad, how to go about removing the information? Well, that depends on how savvy you are with WordPress. Here are several methods to prevent WordPress from displaying your version-specific number, ranked in order from the absolute worst way to the absolute right way. That is, until someone shows us how to do it in less than 41 characters ;)

The absolute worst way to remove the WordPress version number

I have seen recent posts where the author actually recommends deleting the wp_head() hook! Here is an example:

Study what things this function outputs for you, and just hardcode them into your theme files since these values will unlikely change.

While there are indeed valid reasons for removing this important WordPress hook, removing the version number from your source code is not one of them.

A pretty good way to remove the WordPress version number

Much better than simply deleting the wp_head() hook, this method serves us well by placing the version-removal function in the theme’s functions.php file, where it belongs. By returning an empty string for the_generator function, this function removes the version information by preventing output of its <meta> tag:

function remove_version_info() {
     return '';
}
add_filter('the_generator', 'remove_version_info');

This method has the added bonus of removing the version information from not only your blog pages, but from your feeds as well.

The right way to remove the WordPress version number

Going a step beyond the previous method, this technique gets the job done quite eloquently, with a mere 41 characters of code:

remove_action('wp_head', 'wp_generator');

Just place that single line into your theme’s functions.php and enjoy a small taste of “security through obscurity”. :)

© 2009 Digging into WordPress | Permalink | 30 comments | Add to del.icio.us | Post tags: functions, header, PHP

It’s all the rage these days (for good reason), to use Google-hosted JavaScript libraries. They even encourage it. If you’d like to hop on the bandwagon, you can do so and still use the proper wp_register_script function.

UPDATE (December 2011)

As of WordPress 3.3, this is the best way to do it, using the proper hook (thanks David Hollander):

//jQuery Insert From Google
if (!is_admin()) add_action("wp_enqueue_scripts", "my_jquery_enqueue", 11);
function my_jquery_enqueue() {
   wp_deregister_script('jquery');
   wp_register_script('jquery', "http" . ($_SERVER['SERVER_PORT'] == 443 ? "s" : "") . "://ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.min.js", false, null);
   wp_enqueue_script('jquery');
}

Just add this code to your functions.php file:

if( !is_admin()){
   wp_deregister_script('jquery'); 
   wp_register_script('jquery', ("http://ajax.googleapis.com/ajax/libs/jquery/1.3.2/jquery.min.js"), false, '1.3.2'); 
   wp_enqueue_script('jquery');
}

That last line there gets the script queued up for you so you don’t need to do it again in the header. Assuming you have the proper wp_head(); call in your header, you’ll be all set! Note that we have wrapped this in a conditional tag to prevent that action on Admin pages. Because this Google-hosted version of jQuery is not in noConflict mode, it interferes with the rich text editor in the admin. This prevents that.

Remember, the reason for all this is to ensure that other WordPress stuff (plugins…) are aware that the script is already loaded so don’t go around loading another copy. Loading two copies of a JS library is just bad news.

Also, I always use jQuery as an example but of course this would work with any popular JavaScript library. For example, the MooTools path at Google is:

http://ajax.googleapis.com/ajax/libs/mootools/1.2.2/mootools-yui-compressed.js

Google’s AJAX Developer’s API Guide is here.

ALSO… there are a crapload of scripts all ready to be queued up for your use in WordPress. See the full list here.

David wrote in to tell us that he was working in an HTTPS environment, and he used this alteration to ensure the URL for the Google-hosted version of jQuery was properly served from HTTPS when needed:

if (!is_admin()) {
   wp_deregister_script('jquery'); 
   wp_register_script('jquery', ("http".($_SERVER['SERVER_PORT'] == 443 ? "s" : "")."://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js"), false, '1.4.2');
   wp_enqueue_script('jquery');
}

© 2009 Digging into WordPress | Permalink | 22 comments | Add to del.icio.us | Post tags: functions, header, jquery

<link rel="EditURI" type="application/rsd+xml" title="RSD" href="http://digwp.com/xmlrpc.php?rsd" />
<link rel="wlwmanifest" type="application/wlwmanifest+xml" href="http://digwp.com/wp-includes/wlwmanifest.xml" /> 
<link rel='index' title='Digging into WordPress' href='http://digwp.com/' />
<meta name="generator" content="WordPress 2.8" />

As you can see, lots of stuff is added, including feed links, XML-RPC and WLW links, and a couple of other items. While there is plenty to discuss with all of these inclusions, here we are concerned primarily with the link to the xmlrpc.php file. WordPress includes this link for its XML-RPC interface, which enables remote software applications to communicate and interact with WordPress.

What does the xmlrpc.php file do? Do I need it?

While documentation on WordPress’ XML-RPC is fairly thin, we can glean a partial understanding of how the xmlrpc.php works by stepping through the code in the file itself. Don’t worry, we’re not going to bore you with that here, but suffice it to say that the xmlrpc.php is required for the following types of activity:

• Posting directly to your blog using TextMate, Flock, and other weblog clients
• Posting directly to your blog using Eudora, Thunderbird, and other email apps
• Receiving pingbacks and trackbacks to your site from other blogs

Not everyone uses the remote-posting functionality available to them in WordPress, but I think that many blogs are definitely using the XML-RPC protocol for the pingback and trackback functionality.

Does the xmlrpc.php file pose a security risk?

Some of you may remember the security risk associated with the xmlrpc.php script back in the good ‘ol days of WordPress 2.1.2, whereby:

WordPress could allow a remote authenticated attacker to bypass security restrictions, caused by improper validation by the xmlrpc.php script. A remote attacker with contributor permissions could exploit this vulnerability to publish posts to the Web site.

This vulnerability was promptly eliminated in version 2.1.3, but shortly thereafter (in version 2.3.1) another security issue was discovered when the XML-RPC implementation was found to leak information. Although this was fixed in version 2.3.2, the security concerns associated with the XML-RPC protocol eventually led the WordPress devs to disable remote access by default in version 2.6 ³. The xmlrpc.php file is still included in the document <head> (presumably for the sake of pingbacks and trackbacks), but the remote-access functionality is non-operational until explicitly enabled ³.

Security tips for your site’s xmlrpc.php file

At the time of this writing, there are no known vulnerabilities associated with WordPress’ XML-RPC protocol. Even so, there have been security issues with the xmlrpc.php script in the past, and there could certainly exist new problems both now and in the future. Just to be on the safe side, here are a few different strategies and tips to help ensure maximum security for your blog.

If you don’t need it, delete it
Perhaps the safest way to eliminate potential security vulnerabilities is to simply remove the script in question. If you have no need for remote-posting, pingbacks or trackbacks, it may be easiest to simply remove the xmlrpc.php file from your server. Instead of actually deleting it, you may just want to rename it something unguessable. Either way, if the script isn’t available to an attacker, it makes it hard to exploit.

Update: If you remove (or rename) the xmlrpc.php file from your WordPress installation, you should also implement the function described in the next section to avoid an avalanche of 404 errors (see this comment for further explanation).

Remove the links to xmlrpc.php and wlwmanifest.xml
Alternately, if you aren’t needing any remote-access or pingback functionality, you may prefer to simply remove the associated header links rather than deleting any core files from your server. This is easily accomplished with the following function placed in your active theme’s functions.php file:

function removeHeadLinks() {
	remove_action('wp_head', 'rsd_link');
	remove_action('wp_head', 'wlwmanifest_link');
}
add_action('init', 'removeHeadLinks');

This will prevent these two files from being linked to in the header, but the files themselves will remain available on your server. Definitely make sure that the default disabling of remote publishing in effect if you implement this method.

Disable the remote-publishing functionality
If you don’t remote-publish, but you still want to receive pingbacks and trackbacks, take WordPress’ advice and just leave the remote-access functionality disabled by default. This step alone seems like a tremendous way to help tighten down your blog’s security. The file will still be available on your server, but attackers will be able to do much less with it.

Prevent malicious xmlrpc.php directory scanning
For those of you who wisely keep an eye on your server access and error logs, you have likely seen a recent surge in the amount of malicious xmlrpc.php directory scanning. For whatever reason, the bad guys are suddenly very interested in xmlrpc.php files, and are scanning every directory they can get their bots on trying to locate them. I have seen tons of this kind of activity lately:

http://domain.tld/2009/xmlrpc.php
http://domain.tld/2009/06/xmlrpc.php
http://domain.tld/2009/06/01/xmlrpc.php
http://domain.tld/2009/06/01/permalink/xmlrpc.php
http://domain.tld/2009/06/02/permalink/xmlrpc.php
http://domain.tld/2009/06/03/permalink/xmlrpc.php
.
.
.

Whether the attackers locate their target or not, this kind of behavior drains system resources, hogs bandwidth, and prevents your site from operating at maximum capacity. Thus, to prevent this malicious behavior from damaging your site, I have devised the following HTAccess solution:

<IfModule mod_alias.c>
RedirectMatch 301 /(.*)/xmlrpc\.php$ http://domain.tld/xmlrpc.php
</IfModule>

When placed in the web-accessible root HTAccess file for your site, this simple directive will redirect all requests for your blog’s xmlrpc.php file to the actual file. I have been using this method for several weeks now at Perishable Press and have eliminated thousands of misdirected requests because of it.

Leave the xmlrpc.php file but prevent access to it
Last but not least is a simple method enabling you to leave the file in place on your server but prevent access to it. Perfect if you don’t need the script and want to be as lazy as possible about keeping it secure (think no maintenance). Simply paste the following code into your root HTAccess file and be done with it:

<IfModule mod_alias.c>
RedirectMatch 403 /(.*)/xmlrpc\.php$
</IfModule>

¹ Or anywhere the wp_head() hook is located.
² Working with WordPress version 2.8 at the time of this writing.
³ To enable this feature, go to “Settings > Writing > Remote Publishing” in the WP Admin

© 2009 Digging into WordPress | Permalink | 17 comments | Add to del.icio.us | Post tags: header, Security, tips

Random post-display functionality with lightbox-style popup image and title post link

The key to setting this up involves creating a set of custom fields for each post and then displaying the information randomly before the main post loop. Let’s begin with the custom fields.

Setting up the custom fields

If you have already been taking advantage of WordPress custom fields, then you already understand the basic idea here. For each post that you would like to have appear randomly in the header of your theme, create the following custom fields:

Custom-field data associated with each randomly displayed post

Notice that we are using relative file paths for the images. This trick ensures maximum flexibility and portability for our custom-field data. Also note the two different images we are using for each post: a full-size image that will be displayed in the lightbox popup, and a cropped or resized version of that same image for display in the random header.

Once you have associated these custom fields with a few of your posts, it is time for a little get_posts() action to display the random content in your active theme.

Editing your WordPress theme files

One of the great things about WordPress custom fields is that they enable you to display your content in just about any way imaginable. In this tutorial, we are going to display our custom-field data in the header area for every page on the site. Thus, we open our theme’s header.php file and add the following code:

<?php $random = get_posts('showposts=1&orderby=rand'); foreach($random as $post) : setup_postdata($post); ?>

<p>
	<a href="http://domain.tld<?php echo get_post_meta($post->ID, 'randomImage', true); ?>" title="<?php echo get_post_meta($post->ID, 'randomCaption', true); ?>" class="thickbox">
		<img src="http://domain.tld<?php echo get_post_meta($post->ID, 'randomBanner', true); ?>" alt="" />
	</a>
	<small><a href="http://domain.tld<?php echo get_post_meta($post->ID, 'randomLink', true); ?>"><?php echo get_post_meta($post->ID, 'randomTitle', true); ?></a></small>
</p>

<?php endforeach; ?>

As mentioned, this code goes before the normal WordPress loop and calls data from each of the five custom fields that have been added to your posts. Instead of using the more powerful query_posts() for this random post display, we use the simpler get_posts() function instead. It does everything we need while eliminating unnecessary variables and potential complications.

A few other points of interest for this WordPress snippet; notice we are setting the randomness and limiting the post display to one ( 1 ) via two parameters in the get_posts() function. Once the query has been setup, we are using the get_post_meta() tag to populate the following markup with their respective custom-field values:

<p>
	<a href="[randomImage]" title="[randomCaption]" class="thickbox">
		<img src="[randomBanner]" alt="" />
	</a>
	<small><a href="[randomLink]">[randomTitle]</a></small>
<p>

This demonstrates the incredible design flexibility enabled by WordPress custom fields. Once this code is in place, it is time to wrap things up by implementing the JavaScript-powered lightbox functionality.

Adding the JavaScript

To finish things off, let’s make that random-banner image really “pop” by implementing some JavaScript-powered lightbox functionality. As you probably know, there are many lightbox clones from which to choose, but for this tutorial we turn to Cody Lindley’s excellent Thickbox script:

ThickBox is a webpage UI dialog widget written in JavaScript on top of the jQuery library. Its function is to show a single image, multiple images, inline content, iframed content, or content served through AJAX in a hybrid modal.

Using Thickbox is so easy, it almost feels like I’m just being lazy for using it. In fact, we have already setup our WordPress code for use with Thickbox by simply adding the class="thickbox" attribute to the random-banner anchor element. The only other thing that really needs to be done is to upload the Thickbox script and accompanying CSS file to your server and link to them from the <head> section of your header.php file:

<link rel="stylesheet" href="http://domain.tld/wp-content/css/thickbox.css" type="text/css" media="screen" />
<script type="text/javascript" src="http://domain.tld/wp-content/javascript/thickbox-compressed.js"></script>

Putting it all together

Once everything is in place, your random-post gallery should be working great. To see a working example of this technique, check out the header area of Thane Champie’s Graphics Portfolio site. That particular implementation of this method features a few more bells and whistles, but the basic functionality is the same.

© 2009 Digging into WordPress | Permalink | 15 comments | Add to del.icio.us | Post tags: custom-fields, header, JavaScript, layout, lightbox, loop

Another thing is that WordPress already includes a copy of jQuery. Here is how you can load up jQuery in your theme the smart (and intended) way. Put the following code in your header.php file in the <head> section:

<?php wp_enqueue_script("jquery"); ?>

<?php wp_head(); ?>

Your theme probably already has the wp_head function, so just make sure you call the wp_enqueue_script function BEFORE that. Now you are all set to call your own jQuery JavaScript file, AFTER the wp_head function.

<script type="text/javascript"
   src="<?php bloginfo("template_url"); ?>/js/yourScript.js"></script>

You are ready to rock, but there are still some considerations. For example, safeguarding yourself from the future possibility of conflict with other libraries. You really shouldn’t be using multiple JS libraries to begin with, but… better safe than sorry.

To be super-safe, you can put jQuery into “no conflict” mode and use a different shortcut for jQuery. In this case “$j” instead of the default “$”. The standard “$”, for example, can conflict with Prototype. Here is an example of a safe bit of jQuery JavaScript:

var $j = jQuery.noConflict();

$j(function(){

    $j("#sidebar li a").hover(function(){
    	$j(this).stop().animate({
    		paddingLeft: "20px&"
    	}, 400);
    }, function() {
    	$j(this).stop().animate({
    		paddingLeft: 0
    	}, 400);
    });

});

Can you recognize this bit of code? We use it right here on Modern WordPress to do the cool “link nudging” in the sidebar!

Translations

• Belorussian translation

© 2009 Digging into WordPress | Permalink | 59 comments | Add to del.icio.us | Post tags: header, jquery

• sep – a string value indicating the separator displayed before the title
• echo – a boolean value determining whether or not the title is displayed
• seplocation – specifies the position of sep string, either left or right of the title

Here is the basic format for this tag:

<?php wp_title('sep', 'echo', 'seplocation'); ?>

..which is typically combined with the bloginfo('name') tag and used in the header.php file as follows:

<head>
<title><?php wp_title(' | ', 'echo', 'right'); ?><?php bloginfo('name'); ?>
</head>

This would produce the following output for each of the following page types:

• The Home page – outputs the name of the site
• Individual pages – page title | name of site
• Single post views – post title | name of site
• Archived post views – outputs the name of the site
• Date-based archives – year and/or month | name of site
• Category archives – category title | name of site
• Author archives – public username | name of site
• 404 error pages – outputs the name of the site
• Search results – outputs the name of the site
• Tag archives – tag name | name of site

For the average blog, this works fine; most pages include the title as well as the blog name, while those without specific page names simply output the name of the site instead. To go above and beyond, however, a little more preparation is needed. For example, rather than output only the blog name for search and tag pages, why not specify the exact tag or search term being displayed? And what about archive pages? We can customize those as well using the following code:

<title>
<?php
if (is_category()) {
	echo 'Category: '; wp_title(''); echo ' - ';

} elseif (function_exists('is_tag') && is_tag()) {
	single_tag_title('Tag Archive for &quot;'); echo '&quot; - ';

} elseif (is_archive()) {
	wp_title(''); echo ' Archive - ';

} elseif (is_page()) {
	echo wp_title(''); echo ' - ';

} elseif (is_search()) {
	echo 'Search for &quot;'.wp_specialchars($s).'&quot; - ';

} elseif (!(is_404()) && (is_single()) || (is_page())) {
	wp_title(''); echo ' - ';

} elseif (is_404()) {
	echo 'Not Found - ';

} bloginfo('name');
?>
</title>

When used in place of the default WordPress wp_title() tag, this code will produce clear, informative page titles for tag, search, date, author and other archive views, as well as for the dreaded 404 page. Further, this code may be modified to elaborate the various page titles however you wish, and also may be enhanced further, as explained in our book, Digging into WordPress.

© 2009 Digging into WordPress | Permalink | 3 comments | Add to del.icio.us | Post tags: header, tags, title

h3 { color: blue; }
body#about h3 { color: red; }

But how do you get that ID on the About page, but not on any other page? If you have your permalinks set up to show the page name, like http://yoursite.com/about/, you can use PHP to extract the “about” part of that URL.

Here is the magic:

<?php
	$url = explode('/',$_SERVER['REQUEST_URI']);
	$dir = $url[1] ? $url[1] : 'home';
?>

<body id="<?php echo $dir ?>">

© 2009 Digging into WordPress | Permalink | 5 comments | Add to del.icio.us | Post tags: body, CSS, header, permalink