Digging into WordPress » tags

Rounded Font-Sizes (with Colors!) for Tag Clouds

Chris Coyier — Wed, 27 Jan 2010 15:09:11 +0000

Tag clouds accomplish their varied font sizes by applying inline styling to each tag. The resulting font sizes can be really weird like style='font-size:29.3947354754px;'. There is nothing inherently wrong about that, but it feels a bit unsettling and less controllable. Mike Summers sent in a solution he uses on his own site. Let’s check it out.


  
     8,          // font size for the least used tag
        'largest'    => 40,         // font size for the most used tag
        'unit'       => 'px',       // font sizing choice (pt, em, px, etc)
        'number'     => 200,        // maximum number of tags to show
        'format'     => 'array',    // flat, list, or array. flat = spaces between; list = in li tags; array = does not echo results, returns array
        'separator'  => '',         //
        'orderby'    => 'name',     // name = alphabetical by name; count = by popularity
        'order'      => 'RAND',     // starting from A, or starting from highest count
        'exclude'    => '',         // ID's of tags to exclude, displays all except these
        'include'    => '',         // ID's of tags to include, displays none except these
        'link'       => 'view',     // view = links to tag view; edit = link to edit tag
        'taxonomy'   => 'post_tag', // post_tag, link_category, category - create tag clouds of any of these things
        'echo'       => true        // set to false to return an array, not echo it
      ));
      foreach ($arr as $value) {
        $ptr1 = strpos($value,'font-size:');
        $ptr2 = strpos($value,'px');
        $px = round(substr($value,$ptr1+10,$ptr2-$ptr1-10));
        $value = substr($value, 0, $ptr1+10) . $px . substr($value, $ptr2);
        $ptr1 = strpos($value, "class=");
        $value = substr($value, 0, $ptr1+7) . 'color-' . $px . ' ' . substr($value, $ptr1+7);
        echo '' . $value . ' ';
      }
    ?>

The result turns this:

Tag Name

into this:

Tag Name

Class names for colors

Notice in the above output that the link has a class name of “color-29″ now that it didn’t before. Now you have a hook to colorize tag names based on their size.

.color-29 {
   color: red;
}

The Difference Between is_singular() and is_single()

Jeff Starr — Mon, 26 Oct 2009 06:56:58 +0000

You know that you can target single-view pages with the conditional tag, is_single():

This is a great way to conditionally apply styles, scripts, and markup to single-view pages.

But did you know about the conditional tag, is_singular()? The is_singular() tag enables you to target single-view pages, regular page pages, and attachment pages all in one fell swoop.

So, instead of writing something like this:

We can write this instead:

The is_singular() tag is what’s known as a “boolean” function, meaning that it returns one of two values, either TRUE or FALSE. No parameters are associated with this tag.

Now you know :)

Definitive Guide to WordPress Page Navigation

Jeff Starr — Mon, 24 Aug 2009 05:03:47 +0000

There are many ways to navigate a WordPress-powered site. There are archive links, category links, page links, internal post links, single post links, admin comment links, tag links, and many other types of navigational links. When it comes to navigating sequentially through your site’s chronological archive pages, category archives, and other types of archive pages, WordPress provides several useful template tags designed to dynamically link the pages together. Likewise, for single permalink post-views, WordPress provides a set of template tags that connects the pages together in chronologically sequential fashion.

When used properly, these page-navigation template tags enable your visitors to browse your site quickly and easily. Unfortunately, these different template tags have similar names, parameters, and functionality, thereby leaving many WordPress designers dazed and confused.

In this DiW article, we’ll dig into each of these different navigational tags and explain each of them in-depth, with plenty of juicy examples to help you take advantage of their full functionality.

Here are the three sets of template tags we’ll be exploring (click on a tag name to jump to that section):

Index and archive navigation: posts_nav_link()
Index and archive navigation: previous_posts_link() and next_posts_link()
Single-view posts navigation: previous_post_link() and next_post_link()

posts_nav_link() — paired links for index, category, and archive pages

[ ↑ ] The posts_nav_link() template tag provides a combined pair of “next” and “previous” navigational links for any type of paged archive view. Basically, this tag creates paired navigational links for anything other than single-post views. This includes index, category, archive, tag, and search pages. Best results when used either before or after the loop. Here is an example of the tag showing its three accepted parameters:

Default usage

Here is the default usage of this template tag, followed by its corresponding output:

« Previous Page — Next Page »

Parameters

Values for each of the following parameters are strings that may be specified in alphanumeric characters or (X)HTML markup:

sep — text/markup that is displayed between the links
prelabel — text/markup that is used as the link text for the previous page
nxtlabel — text/markup that is used as the link text for the next page

Caution: it’s all backward

Keep in mind that the default implementation of the posts_nav_link() template tag generates links that are essentially backward in order: the “Previous Page” navigation link points to newer posts, while the “Next Page” navigation link points to older posts. Exactly the opposite of what you would expect. Normally, previous posts are older and next posts are newer. To fix this backward behavior, we could simply customize the link text of either navigation link like so:

This would then generate the following links on your archive pages:

« Go forward in time • Go back in time »

This reflects reality to a greater degree, however the links still seem to appear out of order. It just seems counter-intuitive to have the “Go forward” link on the left side of the page and the “Go back” link on the right side of the page. It seems more intuitive and natural to assume the reverse, link left to go back and link right to go forward. Just like reading a book.

Fortunately, there are two ways to get the links to appear in the reverse (i.e., correct) order. Both methods require us to separate the navigational links so that they may be repositioned with the “Go back” link on the left side of the page and the “Go forward” link on the right. How we go about separating the links depends on the template tag that is used. There is a workaround the posts_nav_link() tag, but it is far easier to simply use the previous_posts_link() and next_posts_link() tags instead. We’ll get to the easy way in the next section; for now, let’s look at the workaround for the posts_nav_link() tag.

To separate the navigational links created by the posts_nav_link() tag, we use two instances of it on the page. In the first instance, we kill the “Go forward” link, and in the second instance we kill the “Go back” link. The result is the following code, which provides us with two properly identified navigation links that may be situated in the correct order:

•

Perhaps the best way to understand this technique is to sequentially test each of the following navigation templates. Along the way, keep an eye on where the links are appearing on the page and where the links are pointing:

•

“And that’s all I have to say about that,” as the man once said. Let’s break out of this nightmare and move on to some fresh examples.

Examples

Here are some examples to demonstrate the use and flexibility of the posts_nav_link() template tag:

Your basic navigation

Out of the box, the posts_nav_link() template tag displays your navigation links in reverse order, but you can still customize the text to make things a little clearer for your readers. One of the benefits of sticking with the default busted configuration is that you will never have to deal with empty markup elements that may appear when there are no newer or older posts to display. If squeaky-clean source code tickles your fancy, customize the default tag as needed and enjoy the results:

Keep ‘em separated

What if you want to display your “Previous” link on the left side of the page and the ”Next” link on the right side of the page? We can acheive this effect by using two instances of the posts_nav_link() template tag (note that this configuration also resolves the “backward-navigation” issue discussed above):

Keep ‘em separated with images

Continuing with the previous example, let’s keep the navigation links separate, but use images instead of text:

Remember, you can use any text or markup you need in this template tag, so knock yourself out and conjure up something fresh.

previous_posts_link() and next_posts_link() — separate links for index, category, and archive pages

[ ↑ ] The previous_posts_link() and next_posts_link() template tags provide separate “next” and “previous” navigational links for any type of paged archive view. Basically, this tag creates individual navigational links for anything other than single-post views. This includes index, category, archive, tag, and search pages. Best results when used either before or after the loop. Here is an example of these tags showing their two accepted parameters:

Default usage

Here is the default usage of these template tags, followed by their corresponding output (bullet added for clarity):

•

« Previous Page • Next Page »

Parameters

Here are the accepted parameters for each of these template tags:

label — alphanumeric string and/or markup used for the link text
max_pages — an integer that limits the number of pages on which the link is displayed. The default value is “0” for all pages.

These are backward too

Like the posts_nav_link() tag, the previous_posts_link() and next_posts_link() create links that do the opposite of what you expect them to do. The previous_posts_link() tag links to newer posts and the next_posts_link() tag links to older posts. Again, exactly the opposite of what you would expect.

Fortunately, these tags create links that are spearate from one another, enabling us to implement them according to conventional methods of navigation. Simply customize the link text such that it means the opposite of the tag’s name and then switch the tags’ order in the source code. Let’s look at a few examples to help clarify this technique.

Examples

Here are some examples to demonstrate the use and flexibility of the previous_posts_link() and next_posts_link() template tags:

Customized link text

To keep the navigation operating conventionally, simply switch the meaning of the link text to convey the opposite meaning of the template tag and then position the tags accordingly:

Default WordPress theme

Even the default WordPress theme, Kubrick, uses this technique to display proper navigational links in the correct order and on opposite sides of the page:

Thus, we see how to use the previous_posts_link() and next_posts_link() template tags to easily display your post-archive navigational links appear in the conventional, intiuitive, and correct order. Problem solved.

Keep ‘em separated with images (best method)

Here’s the proper way to create navigational links using images instead of text:

And as before, you may use any text or markup with this template tag, making it possible to integrate into just about any design.

previous_post_link() and next_post_link() — separate links for single-view post navigation

[ ↑ ] The previous_post_link() and next_post_link() template tags provide separate links to the previous post and next post, respectively. In doing so, these tags enable visitors to navigate chronologically through your single post permalink pages. These tags may be used anywhere on the sinlge.php template page, either in or out of the loop. Here is an example of these tags showing their four accepted parameters:

Default usage

Unlike other navigational tags, next_post_link() and previous_post_link() eliminate navigational confusion and ambiguity by using actual post titles for their link text. Here are some examples of the default usage of these tags, followed by their corresponding output (bullet added for clarity):

•

« Previous Post Title • Next Post Title »

Parameters

Here are the accepted parameters for each of these template tags:

format — format string for the link. Here you specify the text/HTML to appear before and after the link. The link itself is specified according to the link parameter by including the %link variable in the format string. For example, a format value of “Next: %link »” will result in the following output: “Next The Post Title »”
link — link text to display. Anything specified here will be used as the %link variable in the format parameter (see previous). By default, this parameter returns the post title via the %title variable. For example, a link parameter with a value of “[[%title]]” will result in the following output: “[[The Post Title]] »”
in_same_cat — boolean value indicating whether or not the next or previous post must be in the same category as the current post. If set to TRUE, only posts from the current category will be displayed. Options are: TRUE or FALSE (default).
excluded_categories — string indicating any collection of category IDs from which the next post should not be listed. In all versions of WordPress except 2.2, multiple categories are separated via “ and ”, for example: ‘1 and 3 and 7’ Oddly enough, in WordPress version 2.2, a comma is used to concatenate multiple excluded categories, for example: ‘1, 3, 7’

Examples

Here are some examples to demonstrate the use and flexibility of the previous_post_link() and next_post_link() template tags:

Custom title with link description before/after post link

Here we are displaying custom link titles with the text “Previous post: ” and “Next post: ” appearing before the previous and next post, respectively:

•

Links to posts within the same category, excluding one

Here is how to display next and previous post links only to posts that are in the same category as the current post unless the current post is in category 7. Any number of categories may be excluded from this “same-category” navigation by using “ and ” as a delimiter:

•

Display images as links

Instead of using text for the next/previous-post links, we can use a custom set of images:

•

Indeed, there is much that may done with this set of template tags. If you know of any juicy tricks not covered here, share them in the comments!

One for the road

Every now and then, you may encounter an older WordPress theme that includes the following navigation tags:

For the record, these are the now-deprecated predecessors of the previously discussed previous_post_link() and next_post_link() template tags. The deprecated versions provide navigation of single permalink post views and use essentially the same parameters as the current tags. Now you know! :)

References

Advanced WordPress Targeting with body_class_plus()

Jeff Starr — Mon, 17 Aug 2009 03:56:30 +0000

Since WordPress 2.8, we can target specific types of page views with CSS using the new body_class() tag. Designed for use within the element, body_class() outputs various class attributes according to the current type of page view. This makes it easy to apply page-specific styling such as current-page navigation highlighting and other nifty CSS tricks.

Strengths and shortcomings of the `body_class()` tag

For the uninitiated, here is a quick review of the body_class() tag. When used as follows:

The body_class() tag will output the following class names depending on current page type:

.home — class name output for the home page
.archive — class name output for any archive page
.category — class name output for any category page
.search — class name output for any search page
.tag — class name output for any tag archive page
Plus many more..

So, for example, when you are logged in to WordPress and viewing your blog’s home page, the body_class() tag will result in something like this:

Or, if you were logged out and visiting your “Asides” category archive, your source code would include this:

This functionality enables you to, say, apply styles to the

heading elements on all of your search pages:

body.search h1 {
	border-bottom: 1px solid #ffff99;
	color: #ffff99;
	}

Likewise, the class names output by the body_class() tag make it possible to target conditionally any element on any type of page, thereby greatly increasing the stylistic flexibility of WordPress. Yet despite its awesomeness, body_class() is essentially an “all-or-nothing” proposition. We can apply styles to all category pages, all search pages, all page pages, and so on. We can even use CSS chaining to target all category views when the user is logged in:

.home.logged-in { border: 100px solid red; }

This is powerful, yes, but what if we want to target, say, all categories that include the term “services” in the category slug? Sure, we could declare each of them individually, like this:

.category-coffee-service { color: red; }
.category-brunch-services { color: red; }
.category-dinner-services { color: red; }
.category-snacks-services { color: red; }
.category-drinks-services { color: red; }
.category-inside-services { color: red; }
.category-design-services { color: red; }
.category-health-services { color: red; }
.category-services-info { color: red; }
.category-services-data { color: red; }
.category-services-cost { color: red; }

But that’s pretty inefficient. Plus, what if the user/client needed to create new “services-related” categories? Have fun explaining to them how edit the CSS file with the appropriate rules.

We could, I suppose, use CSS-3’s wildcard substring-matching attribute-selector:

body[class*="services"] { color: red; }

Definitely cleaner, but there a significant number of browsers that do not support CSS 3, so this is less than an ideal solution.

A better solution would be to add pattern-matching functionality to the body_class() tag. After all, body_class() keeps track of just about every possible type of page-view available on your site. So why not filter the output of body_class() for any instances of “services” and output a specific class-attribute for all matching pages. This would allow us to target and apply styles to virtually any subset of page-views, including those new “services-related” categories for our client site. Say “goodbye” to manual code updating and say “hello” to automated advanced targeting with body_class_plus().

Advanced targeting with `body_class_plus()`

The body_class_plus() tag extends the functionality of body_class() by using PHP’s output buffering to conditionally evaluate its contents. This functionality enables us to pattern-match for specific phrases, and execute conditional operations based on the contents of body_class().

Here is the body_class_plus() function that may be placed in your functions.php file:

Update: There is a new & improved version of this code available via plugin!

To call this function in your theme template, include the following tag in the element of your choice (e.g., within the element):

This is a exemplified version of the body_class_plus() function that enables us to target and apply specific class attributes to any page or category containing the following terms in the URL/page-slug:

“services” — will apply class="services"
“products” — will apply class="products"
“business” — will apply class="business"
“pleasure” — will apply class="pleasure"

This makes it easy to match specific groups of categories, pages, posts, or any combination thereof. Even better, the body_class_plus() function makes it possible to do more than apply classes to targeted page types. In addition to, or instead of, applying classes to specific groups of pages, you can implement any type of functionality desired. For example, you could display template tags, echo content, or execute custom scripts depending on page type. The possibilities are endless.

Download the plugin

If custom functions aren’t your thang, and you would rather implement this functionality via plugin, you can grab it here:

body-class-plus_v02.zip (latest version)
body-class-plus_v01.zip (original release)

Thanks to Peter Kahoun for contributing his expertise and improving the functionality of this plugin.

Take-home message

The take-home message is that the body_class_plus() function extends the functionality of the body_class() tag to target and apply styles to any particular subset or combination of page types. Further, the body_class_plus() function takes body_class() beyond the realm of CSS, making it possible to apply template tags, PHP, and other scripts to virtually any custom-defined set of pages and page types.

Complete list of body_class() attribute values

Here is a complete list of the available classes for the body_class() tag:

rtl
home
blog
archive
date
search
paged
attachment
error404
single postid-(id)
attachmentid-(id)
attachment-(mime-type)
author
author-(user_nicename)
category
category-(slug)
tag
tag-(slug)
page-parent
page-child parent-pageid-(id)
page-template page-template-(template file name)
search-results
search-no-results
logged-in
paged-(page number)
single-paged-(page number)
page-paged-(page number)
category-paged-(page number)
tag-paged-(page number)
date-paged-(page number)
author-paged-(page number)
search-paged-(page number)

For more ways to dynamically set body IDs, check out my article, 9 Ways to Set Dynamic Body IDs via PHP and WordPress.

Awesome Image-Attachment Recipes for WordPress

Jeff Starr — Mon, 10 Aug 2009 06:10:05 +0000

Recently, I found myself on the front lines of WordPress’ somewhat complicated Media-Library system. The site that I was developing required a rather elaborate system of retrieving and displaying image attachments. So, using the latest version of WordPress (2.8.3 at the time), I found myself experimenting with as many template tags and custom functions as I could find. After much experimentation, I discovered the perfect solution, and along the way I collected a healthy collection of recipes for displaying image attachments and their various types of associated information.

In this DiW article, you will learn some tasty ways to include image-attachment information in your posts. From echoing the latest image path to displaying custom-sized image-links for all post attachments, this article should serve as an invaluable resource for anyone working with WordPress’ Media Library and its media-attachment functionality.

Basic display of gallery attachments

When displaying your images via the [gallery] shortcode, WordPress will display image-links for each image in the gallery. Each of these image-links points to the image-gallery page for that particular image. The image gallery is created by the image.php template if present in your theme files. Here is a basic way to display your gallery images from within the image-gallery loop:

ID, 'medium'); ?>

This code will display a medium-sized image-link to the original image. To display an image attachment of a different size, replace the $size parameter in the wp_get_attachment_image() template tag. Accepted values are thumbnail, medium, large, or full. The actual dimensions of these sizes are determined by your preferences in the Media panel of the WordPress Admin.

Display the URL of the latest image attachment

Perhaps the most useful template tag for displaying image-attachment information is wp_get_attachment_url(). This function returns a full URI for an attachment file. If no attachment is found, a value of false is returned. Here are several ways to use this tag within the loop:



ID); ?>

The output of this tag is similar to the following for each attachment:

http://digwp.com/wp-content/uploads/2009/08/example.png

If you are using the image.php file to display your attachments, use the second recipe to display the latest URI for each post. If you are displaying your attachments from any other template file (e.g., index.php, single.php, etc.), use the third recipe and refer to this section of the article for the code required to generate dynamically the $attachment_id variable for the post ID.

Display the latest image attachment as an image

The wp_get_attachment_image() template tag is used to display the latest image attachment as an actual HTML image element. If no image attachment is found, a value of false is returned. Here are several ways to use this tag within the loop:



ID); ?>

The output of this tag is similar to the following for each attachment:

The wp_get_attachment_image() template tag may be customized with the following parameters:

$attachment_id — ID of the desired attachment. Not required if used within an attachment loop, otherwise, refer to this section to generate the ID for non-attachment loops.
$size — Size of the image shown for an image attachment: thumbnail, medium, large or full
$icon — (Optional) Use a media icon to represent the attachment. Default value: false.

Display the thumbnail of the latest image attachment

I couldn’t find any official documentation for the get_attachment_icon() template tag, but after some experimentation, it seems useful for displaying a thumbnail of the latest image attachment for each post. Here are some examples:



ID); ?>

The output of this tag is similar to the following for each attachment:

If using this tag within an attachment loop, such as in the image.php or attachment.php theme file, the post ID parameter is generated automatically. If using within a non-attachment loop, such as in the index.php or single.php theme file, refer to this section for the code required to generate dynamically the post-ID variable.

Other useful template tags for displaying image attachments

Here are some other useful template tags for displaying image attachments and their related information:

See the next section for generating the values of the $attachment_id variable.

Dynamic generation of the post ID for non-attachment loops

If you are using any of the above recipes within a single.php, index.php, or any other non-attachment loop, you will need to include the following line of code to generate the ID for each post:

get_var("SELECT ID FROM $wpdb->posts WHERE post_parent = '$post->ID' 
AND post_status = 'inherit' AND post_type='attachment' ORDER BY post_date DESC LIMIT 1"); ?>

This code dynamically generates the $attachment_id variable that is used in some of the examples above. Here is an example showing how to display the latest attachment URI for each post from within the index.php loop:

get_var("SELECT ID FROM $wpdb->posts WHERE post_parent = '$post->ID' 
AND post_status = 'inherit' AND post_type='attachment' ORDER BY post_date DESC LIMIT 1"); 
echo wp_get_attachment_url($attachment_id); ?>

Enough of the simple stuff! Let’s move on to some more advanced recipes.

Display all attachments for each post

Up to this point, we have been using template tags to display information related to the latest attachment only. With any of the above methods, the output for any of the template tags represents a single attachment item. In order to display multiple attachments for each post, we need to employ WordPress’ get_children() functionality. The get_children() tag returns an associative array of posts with post IDs as array keys. The default parameters are as follows (as of version 2.7):

$defaults = array( 
	'post_parent' => 0,     // get children of this post ID; null value gets all children
	'post_type'   => 'any', // post type: attachment, page, revision, or any; default: any
	'numberposts' => -1,    // number of child posts to retrieve; default: -1 (unlimited)
	'post_status' => 'any', // post status: publish, draft, inherit, or any; default: any
);

For (cough) complete information (cough), refer to the official documentation.

Using this functionality, we are well-equipped to use any of the previously discussed template tags (or any other attachment-related tag) to display all of the attachments for each post in the loop. Here is the basic technique, using the wp_get_attachment_link() template tag:

 'ASC',
	'post_type'      => 'attachment',
	'post_parent'    => $post->ID,
	'post_mime_type' => 'image',
	'post_status'    => null,
	'numberposts'    => -1,
);
$attachments = get_posts($args);
if ($attachments) {
	foreach ($attachments as $attachment) {
		echo apply_filters('the_title', $attachment->post_title);
		echo wp_get_attachment_link($attachment->ID, 'thumbnail', false, false);
	}
}
?>

When used within the loop, this code will output the title and thumbnail-size image-link for every attachment of each post within the loop. As is, the image-links point to the URI of the original, full-size attachment file. To get the image-links to point to the attachment page for each image, change the third parameter in the wp_get_attachment_link() tag to true.

Currently, the function will display all attachments for each post. To limit the number of attachments displayed, change the numberposts value from “-1” to whatever number you wish.

Once you get the hang of this basic attachment-display method, you can have some fun experimenting with different output formats by swapping out and/or including additional template tags. For example, instead of displaying a thumbnail link along with the attachment title, you may want to display the URI of the original attachment. To do so, you would simply replace this line:

echo wp_get_attachment_link($attachment->ID, 'thumbnail', false, false);

..with this:

wp_get_attachment_url($attachment->ID)

Now, what about all of the other tags? How to implement and integrate them into a cohesive configuration of image-attachment bliss? There are far too many possible configurations to even begin to cover them all, but I did come up with an effective way of demonstrating the configurational possibilities with a little function I like to call the “Attachment Toolbox”.

Image-attachment enlightenment with the Attachment Toolbox

The idea is simple: learn by example. This function is essentially a “live” demonstration of the various template tags and their generated output. To use this function, create a few posts and attach some images (or other types of attachments) to each of them. Then, place the following code into your theme’s functions.php file:

 get_the_ID(),
		'post_type'      => 'attachment',
		'numberposts'    => -1, // show all
		'post_status'    => null,
		'post_mime_type' => 'image',
	))) {
		foreach($images as $image) {
			$attimg   = wp_get_attachment_image($image->ID,$size);
			$atturl   = wp_get_attachment_url($image->ID);
			$attlink  = get_attachment_link($image->ID);
			$postlink = get_permalink($image->post_parent);
			$atttitle = apply_filters('the_title',$image->post_title);

			echo 'wp_get_attachment_image()
'.$attimg.'';
			echo 'wp_get_attachment_url()
'.$atturl.'';
			echo 'get_attachment_link()
'.$attlink.'';
			echo 'get_permalink()
'.$postlink.'';
			echo 'Title of attachment
'.$atttitle.'';
			echo 'Image link to attachment page
'.$attimg.'';
			echo 'Image link to attachment post
'.$attimg.'';
			echo 'Image link to attachment file
'.$attimg.'';
		}
	}
}
?>

Then, in your index.php or single.php (or other non-attachment) loop, call the function with the following tag:

Then check the results in your browser. You will see that the code has output a variety of different attachment data, including title, attachment URI, post URI, image URI, image thumbnail, image links, and so on. After examining the output, refer back to the function itself to understand the functionality of each tag. Once you begin to see the correlation between source code and page output, you will be well equipped to transform the function in any way you see fit, or even use it as a guide to create your own custom attachment-display function. It’s all there, just dig in and check it out :)

Check please

That does it for this fun-filled DiW article. We have seen how to display many different types of image-attachment information, including everything from thumbnail links and URL paths to custom-sized images and multiple attachments. This collection of recipes is by no means exhaustive, but it provides plenty of key techniques to help implement and customize your own image-attachment functionality. Working with WordPress’ Media Library can be a convoluted process, to say the least, so any tips and tricks that you happen to know will be greatly appreciated by the incredibly awesome WordPress community.

Delicious Recipes for WordPress Page Menus and Page Listings

Jeff Starr — Mon, 13 Jul 2009 15:01:50 +0000

There are so many awesome ways to display your WordPress pages. Out of the box, WordPress provides two different template tags for displaying lists of your site’s pages. The first, most-commonly used tag is wp_list_pages(), and the second, lesser-known tag is wp_page_menu(). First we’ll explore the highly flexible wp_list_pages() template tag, and then we’ll dig into the new wp_page_menu() tag. Along the way, we’ll check out some delicious recipes, tips and tricks for creating the perfect WordPress Page Menu.

Digging into the wp_list_pages() template tag

Almost everyone is familiar with the wp_list_pages() template tag, and it has served us well since WordPress version 1.5. Using this tag is easy, just add the following code to your sidebar or other choice location:

And then you can customize that in many ways using the fine menu of arguments provided at its Codex Reference Page. Some of the highlights include:

Extreme Sorting Power

You can sort your pages by the descriptor of any field in the wp_post table of the WordPress database. By default, you get alphabetical by page title, but there are some other great options as well. Here are some delicious copy-&-paste recipes for your next project:

That first one there is a little wonky, but can prove very helpful for getting your pages to display in any order imaginable. To configure custom Page order to display via the menu_order parameter, you simply assign each Page a numerical value in its Write/Edit Admin screen. You can see a full list of available descriptors here.

Include and Exclude Anything

WordPress makes it easy to include and exclude any pages to create the perfect page menu. By default, the wp_list_pages displays all pages, but this is easily customized with three useful arguments:

The exclude_tree parameter is new as of WordPress version 2.7. It makes it super-easy to omit an entire branch of pages (the parent page and all descendant pages) from your page listings.

Control the Depth of Pages

There are two parameters designed to control the depth of pages displayed by the wp_list_pages() tag. The first is the depth parameter, which by default displays all subpages, regardless of depth. There is also the child_of parameter, which defaults to a value of 0 to display all pages and subpages. Here are some recipes to customize these default values:

The child_of parameter is a great way to display sub-menus of specific pages, for example for implementation of drop-down menus and so forth. Note that multiple instances of wp_list_pages() may be used on any given web page.

Use with Custom Fields

Here is an extremely powerful way to customize your page menus using custom-field values. Using meta_key and meta_value parameters, you can tell WordPress to display only those pages that contain specific custom-field key/value pairs. Here are some examples:

This parameter also gives you the flexibility of modifying page listings without having to touch any source code. Great for clients and family members who may not feel comfortable “digging in” ;)

Even more functionality (new in WordPress 2.7 & 2.8)

WordPress recently rolled out some new tricks for the wp_list_pages() tag. Namely, we now have the ability to wrap the anchor text of our page listings with any HTML or text. Other new features include the number of pages to display as well the number of pages to pass over when displaying page listings. Let’s have a look:

&link_after='); // wrap anchor text with a span tag ?>

A complete copy/paste recipe for wp_list_pages()

There are several more useful parameters for the wp_list_pages() tag, but rather than explaining each one, I will refer you to the Codex for all the boring details. So now, before digging into the juicy stuff, here is a “super-delicious” tag recipe equipped with every possible parameter, especially designed for easy customization:

&link_after=&authors=0&number=0&offset=0'); // contains all parameters as of version 2.8 ?>

Alright, enough of the basics, let’s explore some truly delicious page-listing recipes.

List all subpages of current page

Here is a way to simplify your sidebars and overall page designs. Instead of listing every subpage on all of your site’s web pages, you can dynamically display subpages only when the visitor is viewing the parent page. So for example, your homepage sidebar would list all of your parent pages, and then each of the parent pages would display a list containing all of its subpages. Here’s one way to do it, as demonstrated in the Codex:

ID.'&echo=0');
if ($children) { ?>

Placed in your theme template file, this code will generate a list of all subpages for the current parent page. If there are no subpages, nothing will be displayed.

As is, this method will only display the subpages when visiting the parent page, but we can modify the code so that all subpages are displayed when visiting either the parent page or any of the subpages:

post_parent)
	$children = wp_list_pages("title_li=&child_of=".$post->post_parent."&echo=0");
else
	$children = wp_list_pages("title_li=&child_of=".$post->ID."&echo=0");
if ($children) { ?>

And you can do even better than that. With this next method, your page listings will be displayed as follows:

When visiting main page, all top level pages are listed in the sidebar.
When visiting a top level page with no children, all top level pages are listed.
When visiting a top level page with children, just the children pages, and descendant pages, are listed.
When visiting a child page, just the children, and descendant pages, of that parent, are listed.

Top Level Pages' );
if (is_page( )) {
	$page = $post->ID;
	if ($post->post_parent) {
		$page = $post->post_parent;
	}
	$children=wp_list_pages( 'echo=0&child_of=' . $page . '&title_li=' );
	if ($children) {
		$output = wp_list_pages ('echo=0&child_of=' . $page . '&title_li=Child Pages');
	}
}
echo $output;
?>

All this is great, but it’s also helpful to know how to style the markup generated by the wp_list_pages() template tag. Let’s look at that next..

Styling wp_list_pages() markup

Here is the default markup generated by the wp_list_pages() template tag (assuming a total of five pages with the current page having an ID of “1”):

Pages
	
		Page ID 1
		Page ID 2
		Page ID 3
		Page ID 4
		Page ID 5

You can strip the outer

and the enclosing tags by including “title_li=” (empty string) as a parameter in the wp_list_pages() template tag. You may also keep these outer tags and customize the “Pages” text with whatever markup and/or text you need. Instead of an empty string, use something like “title_li=Pages” instead. Note also that specific class attributes will be applied to both parents and ancestors of the current page (see next section).

Styling page menus generated by wp_list_pages()

Here is a list of the selectors available for styling your page menus:

.pagenav {}               /* li tag containing page menu */
.page_item {}             /* inlcuded on every page item */
.page-item-n {}           /* specifies page with id of n */
.current_page_item {}     /* specifies the current page */
.current_page_parent {}   /* any parent of current page */
.current_page_ancestor {} /* any child of current page */

Now, ready for some new stuff? Brace yourself..

Digging into the wp_page_menu() template tag

So what about this new wp_page_menu() template tag? With all of the flexibility of wp_list_pages(), why is it necessary? In a nutshell, wp_page_menu() is a simplified version of wp_list_pages(). In addition to accepting a few of the same parameters, this new tag brings one new trick to the table: it provides the ability to add your site’s Home page to the list of Pages displayed. This tag was introduced in WordPress version 2.7, and, in my opinion, should have been integrated into the existing Page-listing template tag. In any case, for those looking for an easy way to include your Home page into the list of Pages, here you go:

As mentioned, most of the parameters are the same as before. Here is a list of common parameters:

sort_column
include
echo
link_before
link_after

And — drum roll please — here are the new parameters: menu_class and show_home! Let’s check ‘em out..

menu_class

This is a no-brainer. It simply specifies the class attribute for the surrounding

. Yes, the list is wrapped in a division. Any string may be used, here is an example:

show_home

Ahh, the long-awaited “include-the-home-page” functionality. Now, instead of hacking your client’s functions.php file to include the Home Page in the main menu, you can simply do this instead:

By default, this parameter returns false and no Home Page is displayed. When set to true, the Home Page will be displayed as the first item in the page list. The URL for the Home Page is taken from the value for your site’s “Blog address”, as specified in the WordPress Admin under Settings > General.

When the Home Page is displayed, the default anchor text is simply “Home”, but you can customize that to whatever you want by specifying such for the parameter value:


'Digging into WordPress', 'sort_column'=>'menu_order')); // include the home page ?>

For more information on this new tag, check it out at the WordPress Codex

Take-home message

WordPress provides two different ways to list your pages: wp_page_menu() and wp_list_pages(). The wp_list_pages() tag is powerful, flexible and fully functional. So, unless you need to include your Home Page, your best bet is always wp_list_pages(). For page menus that include the Home Page, you will need to use wp_page_menu() instead. Beyond listing your Home Page, the wp_page_menu() can do a few things, but nothing that wp_list_pages() can’t already handle.

My question for the day is: Why wasn’t the home-page functionality integrated into the existing tag? Why complicate things with an otherwise redundant tag? Share your thoughts!

Add/Remove Buttons from WordPress Write Panel

Chris Coyier — Tue, 23 Jun 2009 14:07:44 +0000

One of the features of WordPress 2.8 was a “increased speed of the Admin area”, which cited compressed JavaScript files as the reason for the speed increase. One of those files that was compressed was the file quicktags.js in the wp-includes/js directory.

When you have the visual editor turned off, this is the file responsible for created the buttons above the write panel. You know, the buttons like b for strong tags, i for em tags, b-quote for blockquote tags, etc. Personally I much prefer this to the Visual Editor, as I can see exactly what tags are being applied to my content.

But those default buttons are often not quite enough. I like to have a few more buttons easily available to me, like ones for h3-h5 tags, one that will wrap text in both code and pre tags, and one for a float-clearing div.

But remember in WordPress 2.8, this quicktags.js file is now compressed so it cannot be easily altered to include these new buttons like it used to. Thankfully they left a non-compressed version of the file in there as well, called quicktags.dev.js. To use this instead, just rename the quicktags.js file something like quicktags.ORIG.js and rename quicktags.dev.js into quicktags.js.

To add a new h3 button, add a block of code like this, amongst all the other similar code blocks:

edButtons[edButtons.length] =
new edButton('ed_h3'
,'h3'
,'<h3>'
,'</h3>'
,'h3'
);

Force refresh your Edit Post page and you should see the new button!

Custom WordPress Title Tags

Jeff Starr — Mon, 01 Jun 2009 23:03:33 +0000

By default, WordPress provides a decent way of including </code> information for your posts, pages, and various archive views. Using WordPress’ built-in template tag, “<code>wp_title()</code>”, we can specify several useful parameters, including: <ul> <li><code>sep</code> – a string value indicating the separator displayed before the title</li> <li><code>echo</code> – a boolean value determining whether or not the title is displayed</li> <li><code>seplocation</code> – specifies the position of sep string, either left or right of the title</li> </ul> Here is the basic format for this tag: <pre><code><?php wp_title('sep', 'echo', 'seplocation'); ?></code></pre> ..which is typically combined with the <code>bloginfo('name')</code> tag and used in the <code>header.php</code> file as follows: <pre><code><head> <title><?php wp_title(' | ', 'echo', 'right'); ?><?php bloginfo('name'); ?> </head></code></pre> This would produce the following output for each of the following page types: <ul> <li>The Home page – outputs the name of the site</li> <li>Individual pages – page title | name of site</li> <li>Single post views – post title | name of site</li> <li>Archived post views – outputs the name of the site</li> <li>Date-based archives – year and/or month | name of site</li> <li>Category archives – category title | name of site</li> <li>Author archives – public username | name of site</li> <li>404 error pages – outputs the name of the site</li> <li>Search results – outputs the name of the site</li> <li>Tag archives – tag name | name of site</li> </ul> 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: <pre><code><title> <?php if (is_category()) { echo 'Category: '; wp_title(''); echo ' - '; } elseif (function_exists('is_tag') && is_tag()) { single_tag_title('Tag Archive for "'); echo '" - '; } elseif (is_archive()) { wp_title(''); echo ' Archive - '; } elseif (is_page()) { echo wp_title(''); echo ' - '; } elseif (is_search()) { echo 'Search for "'.wp_specialchars($s).'" - '; } elseif (!(is_404()) && (is_single()) || (is_page())) { wp_title(''); echo ' - '; } elseif (is_404()) { echo 'Not Found - '; } bloginfo('name'); ?>

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.

Digging into WordPress » tags

Rounded Font-Sizes (with Colors!) for Tag Clouds

Class names for colors

The Difference Between is_singular() and is_single()

Definitive Guide to WordPress Page Navigation

posts_nav_link() — paired links for index, category, and archive pages

Default usage

Parameters

Caution: it’s all backward

Examples

previous_posts_link() and next_posts_link() — separate links for index, category, and archive pages

Parameters

These are backward too

Examples

previous_post_link() and next_post_link() — separate links for single-view post navigation

Default usage

Parameters

Examples

One for the road

References

Advanced WordPress Targeting with body_class_plus()

Strengths and shortcomings of the body_class() tag

Advanced targeting with body_class_plus()

Download the plugin

Take-home message

Complete list of body_class() attribute values

Awesome Image-Attachment Recipes for WordPress

Basic display of gallery attachments

Display the URL of the latest image attachment

Display the latest image attachment as an image

Display the thumbnail of the latest image attachment

Other useful template tags for displaying image attachments

Dynamic generation of the post ID for non-attachment loops

Display all attachments for each post

Image-attachment enlightenment with the Attachment Toolbox

Check please

Delicious Recipes for WordPress Page Menus and Page Listings

Digging into the wp_list_pages() template tag

Extreme Sorting Power

Include and Exclude Anything

Control the Depth of Pages

Use with Custom Fields

Even more functionality (new in WordPress 2.7 & 2.8)

A complete copy/paste recipe for wp_list_pages()

List all subpages of current page

Child Pages

Styling wp_list_pages() markup

Pages

Styling page menus generated by wp_list_pages()

Digging into the wp_page_menu() template tag

Take-home message

Add/Remove Buttons from WordPress Write Panel

Custom WordPress Title Tags

Strengths and shortcomings of the `body_class()` tag

Advanced targeting with `body_class_plus()`