Fig. 1 The image above is an example of the feature enhancement in action.

WordPress’ get_adjacent_post() Function

The function, get_adjacent_post() has been around since WordPress 2.5, but despite it’s availability, I’ve seen a number of hacks that come in the form of bloated plug-in files and unnecessary SQL Queries (using WP_Query).

With all of the great upgrades that WordPress has received with the 3.0 release, it’s too bad that some of the core features didn’t receive additional treatment–but then again, I suppose that an update to a function like get_adjacent_post() wouldn’t make much sense and would likely break backwards functionality (and not to mention that WordPress is intended to be extensible.)

With that in mind, let’s take a look at how we can extend a core feature like get_adjacent_post().

The getPostNavigation() Function

Using get_adjacent_post() we are able to retrieve the previous and next post easily, but the real benefit comes in the fact that we’re retrieving all of the data associated with that post: Post Title, Post Content, Post Excerpt, Post Permalink, etc.

Note: There exists two other function calls that go unnoticed by the majority of theme developers: get_previous_post(), and get_next_post(). Both of these utility functions use get_adjacent_post(), but these are really just vanity methods for get_adjacent_post()–we want to go straight to the original method.

Goals of this function:

1. Get the Previous, Next, and Current Post with one function call
2. Get a well-formatted unordered list
3. Extensibility

/**
 * Get either the current, previous or next post in an unordered list structure.
 * @param String $post_position The post position: "previous" = previous post, "next" = next post, "current" = current post.
 * @param Bool $showpermalink Show or hide the permalink in the post title (typically used only for the previous and next posts)
 * @param Array $classes An array of classes to be applied to the unordered list
 * @return string The previous or next post formatted in an unordered list that can be styled
 */
 function getPostNavigation( $post_position = 'previous', $showpermalink = false, $classes = array() )
 {
 try
 {
 $objPost;
 $classes[] = 'post-navi';
 switch( $post_position )
 {
 case 'next' :
 $objPost = get_adjacent_post( false, '', false );
 $classes[] = 'next-post';
 break;
 case 'current' :
 global $post;
 $objPost = $post;
 $classes[] = 'current-post';
 break;
 case 'previous' :
 default:
 $objPost = get_adjacent_post( false, '',true );
 $classes[] = 'prev-post';
 break;
 }

 if( empty( $objPost ) ) return;

 // The title with additional formatting applied
 // TODO: Apply your own formatting, truncation, etc.
$title        = htmlentities( $title );

 // An HTML safe string to be used with the tooltip
 $tooltip    = ( $post_position != 'current' ) ? "View Post: "" . $title . """ : """ . $title . """;

 // Standard elements, heading, permalink, and excerpt
 $heading    = ( $post_position != 'current' ) ? '<a href="' . get_permalink( $objPost->ID ) . '" title="' . $tooltip . '">' . $title . '</a>' : $title;
 $permalink    = '<a href="' . get_permalink( $objPost->ID ) . '" title="' . $tooltip . '">Read More</a>';
 $excerpt     = trim( strip_tags( $objPost->post_content ) ) ;

 // The formatted output
 $output     = "<ul class=\"" . implode(' ', $classes) . "\">\r\n";
 $output    .= "<li class=\"post-navi-heading\">{$heading}</li>\r\n";
 $output    .= "<li class=\"post-navi-excerpt\">{$excerpt}</li>\r\n";
 $output    .= ( $showpermalink == true ) ? "<li class=\"post-navi-permalink\">{$permalink}</li>\r\n" : '';
 $output    .= "</ul>\r\n";
 }
 catch( Exception $err )
 {
 throw new Exception( $err->getMessage() );
 }

 return $output;
 }

Example Usage

if( function_exists( getPostNavigation ) )
 {
 $prev_post_ul = getPostNavigation( 'previous', true, array( 'your-custom-class', 'another-class', 'one-more-class' ) );
 $curr_post_ul = getPostNavigation( 'current', false, array( 'link-list', 'col', 'one-col' ) );
 $next_post_ul = getPostNavigation( 'next', true, array( 'link-list', 'col', 'one-col', 'last' ) );
 }

<!-- SET: POST NAVIGATION -->
 <div>
 <?php echo $prev_post_ul; ?>
 <?php echo $curr_post_ul; ?>
 <?php echo $next_post_ul; ?>
 </div>
 <!-- END: POST NAVIGATION -->

Like the get_previous_post_link() and the get_next_post_link(), we can use the function’s output wherever we want in our template, giving us the flexibility to fit the output into simple or complex layouts.

The Breakdown

 $objPost;
 $classes[] = 'post-navi';
 switch( $post_position )
 {
 case 'next' :
 $objPost = get_adjacent_post( false, '', false );
 $classes[] = 'next-post';
 break;
 case 'current' :
 global $post;
 $objPost = $post;
 $classes[] = 'current-post';
 break;
 case 'previous' :
 default:
 $objPost = get_adjacent_post( false, '',true );
 $classes[] = 'prev-post';
 break;
 }

All of the magic really happens in the Switch statement. It is here that we condition the get_adjacent_post() function to retrieve the previous and next post–but for the current post data, we simply use the readily available $post variable.

Note: In order to use the $post variable in any function, it’s scope must be declared using the “global” keyword.

The Switch statement is also used to add three additional CSS classes to the unordered list that can be used for custom styling if you want to use the functions’ defaults. These three classes allow for distinction amongst the expected output:

1. next-post
2. prev-post
3. current-post

The Output

The output itself is pretty straight-forward: we’re slugging various fields of the previous, next, or current post into an unordered list that we can style with CSS; here is an example:

$output     = "<ul class=\"" . implode(' ', $classes) . "\">\r\n";
 $output    .= "<li class=\"post-navi-heading\">{$heading}</li>\r\n";
 $output    .= "<li class=\"post-navi-excerpt\">{$excerpt}</li>\r\n";
 $output    .= ( $showpermalink == true ) ? "<li class=\"post-navi-permalink\">{$permalink}</li>\r\n" : '';
 $output    .= "</ul>\r\n";

Extending getPostNavigation()

As usual, this function will need to be placed in your functions.php file, but you shouldn’t stop there—the output can be structured however you need it. Customization for your particular needs can be accomplished by simply replacing the html markup in the function with your own.

Generally speaking, if you’re using WordPress as a CMS (or any CMS really), you’re likely to have some sort of tiered development setup. Such a setup typically consists of a Development, Staging, and Production environment (servers—virtualized or otherwise), and with each of those environments will likely have a corresponding Database server like MySQL.

The Issue

A tiered development workflow typically requires that you promote changes in one database to another (upstream), e.g. Development to Staging to Production. In some cases the replication can be bi-directional (upstream and downstream), e.g. Production to Staging and Back to Production. This last case can be pretty rare, but it exists, and where a CMS is involved, replicating the database can be a chore unless you’ve done some serious work to automate the process.

Where WordPress is concerned, we run into issues when we migrate content from our Staging Server and onto our Production server.

Here’s a Simple Illustration:

URL: http://localhost/mywordpress/

<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Cras ut risus purus. Class aptent taciti sociosqu ad litora torquent per conubia nostra, per inceptos himenaeos. <a href="http://localhost/mywordpress/2010/09/01/the-quick-brown-fox">The quick brown fox jumps over the lazy dog</a>. Integer iaculis augue non lorem fermentum ac vulputate odio convallis. Curabitur congue sem vitae ipsum tempor sagittis.</p>

URL: http://www.stagingserver.com/mywordpress/

<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Cras ut risus purus. Class aptent taciti sociosqu ad litora torquent per conubia nostra, per inceptos himenaeos. <a href="http://localhost/mywordpress/2010/09/01/the-quick-brown-fox">The quick brown fox jumps over the lazy dog</a>. Integer iaculis augue non lorem fermentum ac vulputate odio convallis. Curabitur congue sem vitae ipsum tempor sagittis.</p>

URL: http://www.productionserver.com/

<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Cras ut risus purus. Class aptent taciti sociosqu ad litora torquent per conubia nostra, per inceptos himenaeos. <a href="http://localhost/mywordpress/2010/09/01/the-quick-brown-fox">The quick brown fox jumps over the lazy dog</a>. Integer iaculis augue non lorem fermentum ac vulputate odio convallis. Curabitur congue sem vitae ipsum tempor sagittis.</p>

Each instance of WordPress on the Development, Staging, and Production environments uses a replicated database. If you examine the links in each, you’ll see that each link is identical:

<a href="http://localhost/mywordpress/2010/09/01/the-quick-brown-fox">…</a>

We’ve moved the content from one environment/database to the another, but the URIs in the content haven’t changed. That leaves us with our fundamental migration issue, and if you’ve been in such a situation, you’ll probably have taken the following approach to deal with it:

Manually Updating The Database:

In most cases, you’d likely run a Search & Replace SQL statement that will modify all of the posts/pages/etc for you. Your Search & Replace SQL might look something like this:

UPDATE wp_options SET option_value = REPLACE(option_value, "localhost", "www.stagingserver.com");
UPDATE wp_posts SET post_content = REPLACE(post_content, "localhost", "www.stagingserver.com");
UPDATE wp_posts SET post_content_filtered = REPLACE(post_content_filtered, "localhost", "www.stagingserver.com");
UPDATE wp_postmeta SET meta_value = REPLACE(meta_value, "localhost", "www.stagingserver.com");

With this approach you’d need to run this search and replace each time you migrate the database from your localhost to your staging platform.

What a pain.

WordPress Content Filters to The Rescue

To avoid all of the unnecessary hassle we need to dig a little deeper into some of the inner workings of WordPress. In this case, content filters.

WordPress comes with a number of built in filters that Plug-in developers can hook to enhance parts of WordPress’ core feature set. In fact, in a default setup, WordPress applies a number of filters to the content when you first save a draft; when you publish an article or page; and when you use features within the_loop().

“Token” Replacement

A token in the context of this article is simple a common placeholder string that can be easily referenced programmatically, and transformed/replaced with something else. As the term suggests, the “token” should be simple and easy to find in your html markup of your content.

The objective of this approach is to replace all of the instances of your site URL with that of a token, and do this in such a way that it is invisible to you or whomever is tasked with managing the content, e.g. set-it-and-forget-it.

Let’s begin.

Step 1: Choosing a Token

The first thing we need to do is to determine the format of our token. Here are some considerations:

1. The token should be something that is unique in comparison to the surrounding content—meaning that if it was garbled in with html markup and other text, it would be easily recognizable.
2. The token should use only characters that are HTML safe—this excludes any special characters that might be transformed into HTML entities by WordPress’ other default content filters. There are ways to get around this, but that will be for you to discover.
3. The token that we determine should be stored as a reference in a globally accessible file, e.g. functions.php

For the purposes of this article we will use the following as our token: [%URL%]

Step 2: The Token Replacement Functions

<?php
$URL_TOKEN = '[%URL%]';
/**
* Find instances of the current domain and replace them with a token
* @param String $content - The orignal content
* @return String - The updated content with the token replacement in place of the site URL
*/
function f3_createDomainToken( $content )
{
	$domain = get_bloginfo('url');
	$token = $URL_TOKEN;

	$content = str_replace( $domain, $token, $content );

	return $content;
}

/**
* Find instances of the token and replace them with the current domain
* @param String $content - The orignal content
* @return String - The updated content with the site URL in place of the token
*/
function f3_replaceDomainToken( $content )
{
	$domain = get_bloginfo('url');
	$token = $URL_TOKEN;

	// Find instances of the token and replace them with the current domain
	$content = str_replace( $token, $domain, $content );

	return $content;
}
?>

What we have with these two functions is a means to parse the content that is supplied to each one, and transform any initial references to your domains, e.g. “Site URL” into a token. Line 1 in the above code illustrates a constant that is accessible by each function and should be placed at the top of your functions.php file. The functions themselves will be to be placed in functions.php where you see fit.

Step 3: The Content Filters, e.g. “Hooks”

This last step is essential. In order for these functions to be of any benefit to you, they must be added to WordPress’ filter queue using the “add_filter()” method. You can use these functions independently rather than as filters, but you’ll only gain some marginal benefit, and it will require that you call the filters in your templates where you use the functions: the_content(), and get_the_content().

What we want to do is ensure that when the_content() function is called in your template, the resulting output is already correctly formatted, e.g. your token has been replaced. Here are the hooks that you will need to use these functions effectively:

<?php
// DOMAIN REPLACEMENT FILTERS
add_filter( 'the_content',      'f3_replaceDomainToken', 11);
//add_filter( 'get_the_content',  'f3_replaceDomainToken', 11);
add_filter( 'content_edit_pre', 'f3_replaceDomainToken', 11);
add_filter( 'content_save_pre', 'f3_createDomainToken', 11);
add_filter( 'the_editor_content', 'f3_replaceDomainToken', 11);
?>

The function “add_filter()” expects three parameters, two of which are required, and the last is optional. If you look at the example above, you can see that we’re using some of WordPress’ hooks:

<?php
the_content()
get_the_content()
content_edit_pre()
content_save_pre()
the_editor_content()
?>

The first two you might already familiar with if you’ve done some template development, but the last three are ones that are primarily used by WordPress Plug-in Developers. What you probably don’t know is that all of what I’ve illustrated here can be easily wrapped into a simple WordPress plug-in. If you really consider how WordPress is built, you’ll also realize that functions.php is a very simple example of how a plug-in functions.

Notes:

• If you’re paying attention, you’ll notice that line 3 in the above code is commented out, this is because some plug-ins might already be applying filters to the output of get_the_content(), and you as a WordPress developer might want to do some other transformations on your content.
• Line 6 is a rarely used (please correct me if I’m wrong) plug-in hook that’s used for plug-ins that introduce additional content fields into the normal WordPress editor.
• You will still need to update the site url in the options table (wp_options) when you migrate from one database/environment to another, but you can use the first SQL statement I’ve provided in this article to handle that.
• Full automation of this process can be accomplished with some edits to the wp_config.php by defining a constant that will be automatically updated as you migrate from server to server; this constant will replace the reference to bloginfo(‘url’) in the functions I’ve provided (I’m going to let you figure that one out).

Conclusion:

Content migration is still going to be painful at times, and it doesn’t really matter if you’re using WordPress or some other setup (even your own); however, it doesn’t always have to be that way. What I’ve illustrated here is a means to mitigate some of that headache. Take some time to explore how WordPress’ content filters work–you might be amazed at how much more control you actually have over your content and it’s formatting.

References:

1. WordPress Codex: the_loop() explained
2. WordPress Codex: apply_filters() explained

Strategic use of texture can help to shape the perception of a design; it can turn a simple website layout into something evocative; when delivered in context with the subject matter of the site (articles, information, etc), texture can help to communicate tone and attitude.

Texture In Web Design

Visual textures can be lumped into three relative categories:

1. Patterns
2. Photographic
3. Illustrated

Patterns as Texture

Patterns are the most common type of texture that you encounter on the web. In many cases they are tileable images that are rendered as background images in a page, or appear as textured design accents. Patterns can range from illustrated elements that can repeat endlessly, or as three dimensional (often photographic) textures that can evoke a sense of depth and dimension.

Example:

Fig. 1 – Tileable Patterns.

Resources:

• K10K Pixel Patterns
• SquidFingers Patterns
• BgPatterns

Photographs as Texture

It would be more appropriate to consider photographic texture as singular instances of texture applied to the design, rather than something that is explicitly tiled as in the case of patterns. Photographic textures tend to range in subject matter, but the most common example of photographic texture are images that can be used as backgrounds, such as walls (brick, cement, etc).

Example:

Fig. 2-4 – Light, textiles and other industrial textures.

Resources:

• ImageAfter
• iStockPhoto

Illustration as Texture

Illustrated texture is something of a trend over the past few years, where artists and designers mix various sources such as photographs, tileable patterns, and light to create unique textures.

Examples:

Fig. 5-7 – Mixed water color backgrounds.

Resources:

• iStockPhoto
• Brusheezy

Texture in WordPress Themes

Texture as a design element contributes to the overall personality of the design. When it comes to WordPress Themes, authors tend to exhibit a need to communicate an aspect of their personality through the theme they choose to employ on their blog.

If you’re thinking about using texture as part of your design, consider the following:

1. Theme: What is the theme of your theme?
2. Prominence: How prominent are the textures going to be in your design?
3. Repetition: How often and how many repeatable textures are you planning to use in the design?

Bringing it Together

Designing a successful WordPress theme is no different from designing a compelling website layout – both need to illustrate an artistic (and practical) balance of many design concept where texture may be one fundamental aspect of that balance.

When you’re considering the design of your WordPress theme, think about how your chosen texture(s) will work together with your other design elements to communicate the overall theme.

For example, if you’re out to create a theme that needs to communicate and “outdoors lifestyle” or “nature”, you may want to consider using textures that are organic. In a case like this could could mix various types of textures (tileable, photographic and illustrated).

Fig. 8 – Outdoor Italia

The Outdoor Italia site is a great example of how various types of tileable and photographic texture can be used in a design to communicate a theme. The site makes great use of photographic textures in the form of leaves, paper, and the occasional physical item to deliver a sense of depth.

Fig. 9 – Wild About Gardening

The Wild About Gardening is one of my favourite sites for two reasons: the illustration work makes subtle use of — and reference to — watercolor art, and it blends well with photographic texture. This site is a great example of Photographic and Illustrated texture working naturally together to communicate a sense of unity in the design.

The above examples aren’t WordPress themes, but the leap from content to editorial layout isn’t difficult to make.

Remember that not every WordPress design you create has to have shiny buttons and glossy blocks. Take time to experiment with texture in your design, and discover how different textures can dramatically change the tone and style of your design.

For the most part, you may be stuck with using the setup that the Theme Designer decided to adopt.

Blogs typically take one of three common approaches to displaying posts:

1. Posts are displayed as excerpts with a “read more” link.
2. Posts are displayed with the full body of the posting.
3. Only one post is displayed with pagination available.

The first approach — the most common of the three — is likely a result of the Theme Designer choosing to use the out-of-the-box functionality of the blogging software (and to be fair, it is likely the most efficient); however, not everyone wants a cookie cutter solution to displaying their posts.

The reality is such that you don’t actually need to do a lot of work to get your blog postings to appear the way you want them to. I can’t speak for other blogging software packages, but when it comes to WordPress, there are a many techniques you can apply to customize your postings.

WordPress – The Loop

The meat-and-potatoes of WordPress is “The Loop“. If you’ve ever attempted to customize a WordPress theme, it’s likely you’ve encountered this The Loop (essentially a “while” loop). This is an example of a very simple loop (taken from the WordPress codex):

   1: if (have_posts()) :

   2:    while (have_posts()) :

   3:       the_post();

   4:       the_content();

   5:    endwhile;

   6: endif;

This is a better explanation if you’re not too familiar with code:

The Loop is used by WordPress to display each of your posts. Using The Loop, WordPress processes each of the posts to be displayed on the current page and formats them according to how they match specified criteria within The Loop tags.

If you examine one of the template files of your theme you may encounter a more complicated version of the above snippet.  The Loop is where we are going to start to customize the appearance of your postings.

Postings

A post in WordPress is comprised of a number of elements such as the Title of the post, the Content of the post, and assorted information like the Date/Time, etc. In the common approaches, all of the postings share the exact same format and display identical information.

Boring.

But it doesn’t have to be this way. The developers of WordPress were smart enough to realize that while the majority of theme designers don’t mind this type of homogenous approach, there are a few Theme Designers out there who prefer not to follow this pattern. As such, WordPress is built with with the ability to modify how The Loop is applied.

There are several approaches to modifying The Loop, but the two that I prefer are:

1. Use query_posts with counter and offset.
2. Use The Loop with counter and conditions.

The Loop With query_posts(…)

It took me a while to understand what this feature did; quite simply put, it adds additional parameters in the The Loop to instruct WordPress on what to output.

   1: <?php query_posts('showposts=1'); ?>

   2: <?php if (have_posts()) : while (have_posts()) : the_post(); ?>

The snippet above was taken from one of my WordPress themes. In the theme, I use the above approach to display ONLY my most recent posting in full. Here’s a simplified version of the markup I use:

   1: <!-- set main-entry -->

   2: <?php query_posts('showposts=1'); ?>

   3: <?php if (have_posts()) : while (have_posts()) : the_post(); ?>

   4: <div class="main-entry">

   5:     <h2><a href="<?php the_permalink(); ?>" rel="bookmark" title="Permanent Link to <?php the_title(); ?>"><?php the_title(); ?></a></h2>

   6:     <?php //the post meta ?>

   7:     <ul class="meta-top">

   8:         <li><strong>Posted:</strong> <?php the_time('F j, Y'); ?></li>

   9:         <li><strong>Author:</strong>  <?php the_author(); ?></li>

  10:         <li><strong>Filed under:</strong> <?php the_category(','); ?></li>

  11:         <li><?php if( get_the_tags() != NULL ) { the_tags('<strong>Tags:</strong> ',', '); }else{ echo "<strong>Tags:</strong> No tags set for this entry."; }?></li>

  12:     </ul>

  13:     <?php

  14:         the_content('Read more...');

  15:     ?>

  16: </div>

  17: <?php endwhile; endif; ?>

  18: <!-- end main-entry -->

In this example, The Loop is executed only once and only once. The query_posts() function passes instructions to The Loop to show only one post (using query_posts(‘showposts=1′)). While The Loop is executed, it will output all of the post’s information that I’ve specified using the appropriate Post tags.

NOTE: I have set the container <div> class to “main-entry”. This references a rule in my CSS file that will style the output accordingly.

Unfortunately, you’re stuck with only one posting on your page. We need to display older postings as well, and ideally in a format that is different than the most recent.

As previously mentioned, The Loop was executed only once with the example above. This is a powerful feature of query_posts(), in that you have a tremendous amount of control over The Loop — in this case, how many times it is executed.

To render the older postings, you can do this:

   1: <!-- set past-entry -->

   2: <?php query_posts('showposts=9&offset=1'); ?>

   3: <?php if (have_posts()) : while (have_posts()) : the_post(); ?>

   4: <div class="past-entry">

   5:     <ul class="dateblock left">

   6:         <li class="top"><?php the_time('M Y'); ?></li>

   7:         <li class="bottom"><?php the_time('j'); ?></li>

   8:     </ul>

   9:     <div class="entry-content">

  10:         <h1><a href="<?php the_permalink() ?>" rel="bookmark" title="Permanent Link to <?php the_title(); ?>"><?php the_title(); ?></a></h1>

  11:         <?php

  12:             the_excerpt();

  13:         ?>

  14:     </div>

  15: </div>

  16: <?php endwhile; endif; ?>

  17: <!-- end past-entry -->

Aside from the simpler markup, the core difference between this second snippet and the first are the instructions/parameters in query_posts(), and the CSS class which is referenced.

   1: <?php query_posts('showposts=9&offset=1'); ?>

   2: <?php if (have_posts()) : while (have_posts()) : the_post(); ?>

   3: <div class="past-entry">

If you combine both of the examples above, what you’ll find is that you’re actually running The Loop twice — in the first instance, The Loop only outputs the most recent post. In the second instance, it skips over the most recent  post completely, and outputs as many older posts as you defined in query_posts().

NOTE: if you examine the parameters in the second query_posts() instance, you should see “showposts=9&offset=1” — this will output 10 posts in total on your page, where 9 such posts are older.

Styling The Posts

What you need now are two CSS rules which define:

1. “main-entry”
2. “past-entry”

   1: /* CSS Snippet */

   2: #post-container div.main-entry {

   3:     background-color: #CCCCCC;

   4:     color: #000000;

   5:     font-size: 1em;

   6: }

   7:

   8: #post-container div.past-entry {

   9:     background-color: #ffffff;

  10:     color:#333333;

  11:     font-size: .92em;

  12: }

The XHTML markup does not have to be different between these posts, and as you can see in the CSS snippet above, you can get away with as little as displaying a different background color, font color or a larger font size.

The Caveat

Yes, there is a downside to using query_posts(). Programmatically speaking, you should try to optimize the number of queries you execute against your database. Since WordPress is largely database driven, you can expect a high volume of requests on any given page. Using query_posts() should be done sparingly (I limit it’s use to the homepage of my blog).

Also, if you are wanting to support pagination, you will need to do a little more work to setup the query properly — you can read more about it here.

The Loop With Counter & Conditions

The simplest method to determine and style your most recent post in contrast to your older postings is a pure implementation of “The Loop”. This implementation also relies on using a counter to keep track of how many posts you’re outputting (as determined by your WordPress settings), as well as a condition to determine which class to reference when styling the output.

Here is an example of this in action:

   1: <?php

   2:     if (have_posts()) {

   3:         // the counter (initialized to 0 );

   4:         $n = 0;

   5:         // the while loop

   6:         while (have_posts()) {

   7:             // the CSS class to apply

   8:             $class = ( $n == 0 ) ? "main-entry" : "past-entry";

   9: ?>

  10:             <!-- set post -->

  11:             <div class="<?php echo $class; ?>">

  12:                 <ul class="dateblock">

  13:                     <li class="top"><?php the_time('M Y'); ?></li>

  14:                     <li class="bottom"><?php the_time('j'); ?></li>

  15:                 </ul>

  16:                 <div class="entry-content">

  17:                     <h1><a href="<?php the_permalink() ?>" rel="bookmark" title="Permanent Link to <?php the_title(); ?>"><?php the_title(); ?></a></h1>

  18:                     <?php

  19:                         if( $n == 0 ) {

  20:                             the_content();

  21:                         }else {

  22:                             the_excerpt();

  23:                         }

  24:                     ?>

  25:                 </div>

  26:             </div>

  27:             <!-- set post -->

  28:

  29: <?php

  30:             // incriment the counter

  31:             $n .= 1;

  32:         }

  33:

  34:     }

  35: ?>

As you can see from the example above, we’ve taken a basic instance of The Loop and added in two variables:

1. $n — this is the counter used to determine which which is the most recent (starting at “0″ — the first).
2. $class — this is the CSS class that we want to reference (“main-entry” or “past-entry”).

The method and approach to styling the post is the same as the examples in query_posts(). The XHTML markup can be re-used between new and older postings, but this is not required. With a little work you can supply The Loop with two different sets of markup to render.

The Caveat

While this implementation is rather straight forward, it can get complicated quickly if you want to include more and more variations between postings. Each variation requires a little more forethought, and the appropriate conditions to determine what to do and what to render. What you may end up with is a lot of messy markup that is difficult to read.

Conclusion

It doesn’t take a lot of work to modify your WordPress template to render your most recent posting in a unique fashion. In some cases, you can download plugins to help you style your postings; for me, having to rely on additional plugins seems more overhead than is necessary. The techniques outlined in this article are only two of many such approaches (and certainly a manual approach).

Don’t feel as if you have to select one over the other. In fact, your writing style and your choice of template play a large part in determining which method is most appropriate.

Hi Chris,

I’m really curious on how you got that quote feature on your comment section. Do you mind sharing your code?

Cheers,
[author name omitted]

While this is not a new feature by and large, it is one that I thought would bring a sense of discussion to the linear WordPress comment format much like how forums work. I’ve attempted to use threaded commenting plugins, but they are ugly and overly complicated for something that should be fairly straight forward.

In any case, this is the JavaScript snippet that I wrote (you need jQuery, but comes with the theme)

// attach a function to the quote comment link
  $('a.quote-comment').click( function() {
      var tb = $('#comment');
      var strQuote = $(this).attr('title');
      // assign the value
      tb.val('<blockquote>' + strQuote + '</blockquote>');
      return false;
   });

This is the result:

There are a couple caveats to this feature

1. You can only quote one comment at a time, as I didn’t build in concatenation.
2. It is not parameterized so you’ll have to customize it for your own theme.
3. Requires some additional styling (no big deal).

If anyone wants to improve on this, feel free to share!