Design by Fire Cleanup

This article has been retired and will no longer be updated. Caveat emptor!

Last week, Andrei Herasimchuk of Design by Fire announced a contest to see who could take his site’s current design and “clean it up, optimizing it for best semantic and structural architecture.” Having the final code judged by three industry bigwigs (Dave Shea, Dean Jackson, and Eric Meyer), Andrei is offering the winner their choice of any three Adobe products. It’s a widely known fact that software from Adobe is like crack to designers, so I figured I’d have a go at it.

I by no means would consider myself an “expert” on web standards (at least not in the same league as these guys), but my anal-retentive temperament has provided me with the abnormal patience to sit down and scour the web for details regarding this subject matter. I’d like to think that although I may not have a lot of industry experience, I have read tons about web standards and do enough work on my own to offer advice when it’s needed.

The contest consisted of cleaning up three different pages of code, and also optimizing the CSS involved in creating the look of Andrei’s site. Initially underestimating the amount of time it would take to complete this cleanup, I immediately downloaded the necessary source code and began hacking away.

Screenshot of DxF Code

The Results

After about four days of working on the contest, creating three new images, having two bloodshot eyes, and one neglected girlfriend, I decided my pseudo redesign was complete. I’m sure it’s not perfect, but I can honestly say that it is better.

Overall, my changes make the site much more consistent…not only in its structure, but in the way it’s displayed across different browsers and platforms. It’s also much more accessible, much more semantic, and it tastes like chicken!

The final judging for the contest has yet to take place, but I’m crossing my fingers. Even if I don’t win the software, it has been a good way for me to flex my design muscles — plus there’s the added bonus of three very prominent designers in the industry who will be looking closely at my work.

If any of my readers are interested in seeing the completed code (yes, I’m talking to both of you), the three pages can be found here:

I’ve also created a zip file that contains all of the new code, images, CSS, and source files used in creating my entry. Inside the zip, you’ll also find a changelog that discusses the improvements I made in more detail.

Wish me luck!


Faking Multiple Templates in WordPress

This article has been retired and will no longer be updated. Caveat emptor!

One of the things that surprised me when I first switched from Movable Type to WordPress was its lack of multiple templates. In MT you create numerous templates which allow you to change the look of different pages on your site (i.e., the homepage, archive pages, individual entries, etc.). If you want a list of your favorite links to appear on the homepage, but not on the page for an individual entry, you just delete that section of code from the appropriate template.

WordPress handles its pages a bit differently. Everything is based off of a single template, and through the magic of database queries and dynamic page generation, the right content is always shown according to which type of page you’re looking at.

The Problem

By using a single template, the default installation of WP will show the exact same sidebar on every page, and likewise, whenever you view an entry listing, it will always look the same. This one-template structure is viewed as a blessing to some, but an over-simplification to others.

What if you want to show a list of just the entry titles on your archive pages, rather than the entire entry itself? What if you want to hide the sidebar’s calendar on your individual entry pages? There are countless scenarios like these that require a little more flexibility than the default index.php file can give you.

This issue has been discussed many times on the WordPress support forums, but I’ve found most of the proposed solutions to be less than ideal. It’s rumored that the functionality to control these types of things will be built into WordPress 1.3, but for the time being, it seems we’re on our own.

A Common Solution

Many people suggest using .htaccess rules and simply forward visitors to templates other than index.php. I feel this method over-complicates things, and here’s why:

  1. It creates duplicate code when most of the time you’ll have the exact same basic page structure in each template. Not only that, but multiple templates aren’t very easy to maintain if you ever need to change that underlying structure.
  2. There’s no guarantee that all WP users will be able to create, edit, and use .htaccess files. Some hosting companies just don’t allow it.
  3. Writing .htaccess rules can be downright confusing!

My Solution

Using some simple PHP and the functionality that’s already built into WordPress, you can easily control what appears on different page types without having to create multiple templates. The key lies in exploiting a few under appreciated variables…

$single, $cat, $m, and $year are all built in variables used by WP to determine information about the type of page you’re looking at. The $single variable corresponds to individual entry pages, the $cat variable to categorical listing pages, $m to monthly listings, and $year to yearly listings.

When you’re viewing each variable’s corresponding page type, only that variable will be assigned a value. If you’re viewing the main page of your site, then none of those variables will be assigned a value. Thus, a simple test of whether or not each variable has a value can be use to control exactly what is displayed and when. Here’s the basic idea:

if ($single) {
    // individual post contents
} else if ($cat) {
    // categorical listing contents
} else if ($m) {
    // monthly listing contents
} else if ($year) {
    // yearly listing contents
} else {
    // main page contents
}

All you have to do is place the content you want to appear in the appropriate spot. If you don’t want to do anything different in a particular section from how WP handles it by default, just leave out that variable’s test.

How to Apply It

Using one of the scenarios from above as an example, let’s say that you want to show just the entry titles when viewing a categorical listing. All you’d have to do is change the <div id="content"> section of your index.php file to be something like this:

<div id="content">
    <?php
    if ($posts) : foreach ($posts as $post) : start_wp();

    if ($cat) { ?>
        <h3 class="storytitle" id="post-<?php the_ID(); ?>"><a href="<?php the_permalink() ?>" rel="bookmark" title="Permanent Link: <?php the_title(); ?>"><?php the_title(); ?></a></h3>
    <?php } else { ?>
        <?php the_date('','<h2>','</h2>'); ?>

        <div class="post">
            <h3 class="storytitle" id="post-<?php the_ID(); ?>"><a href="<?php the_permalink() ?>" rel="bookmark" title="Permanent Link: <?php the_title(); ?>"><?php the_title(); ?></a></h3>

            <div class="meta">
                <?php _e("Filed under:"); ?> <?php the_category() ?> &#8212; <?php the_author() ?> @ <?php the_time() ?> <?php edit_post_link(); ?>
            </div>

            <div class="storycontent">
                <?php the_content(); ?>
            </div>

            <div class="feedback">
                <?php wp_link_pages(); ?>

                <?php comments_popup_link(__('Comments (0)'), __('Comments (1)'), __('Comments (%)')); ?>
            </div>

            <!--
            <?php trackback_rdf(); ?>
            -->

            <?php include(ABSPATH . 'wp-comments.php'); ?>
        </div>
    <?php }

    endforeach; else: ?>
        <p><?php _e('Sorry, no posts matched your criteria.'); ?></p>
    <?php endif; ?>
</div>

The process would be just as easy to change what appears in the sidebar of your page…just edit the <div id="menu"> section. Once you get the hang of it, these variables can be used to manipulate just about anything.

Taking It a Step Further

Adding in code for each of these page types can get confusing really fast. With that much information packed in to one file, the scanability of index.php drops considerably and it becomes difficult to find what you want when you need it.

To combat this, I’ve taken the fake template concept a step further…rather than listing all of the code directly in index.php, I use PHP includes to import each custom section from an external file. Rather than make this tutorial any longer than it already is, here’s how I set it up:

<div id="content">
    <?php
    if ($posts) : foreach ($posts as $post) : start_wp();
        // Faking multiple templates
        if ($single) {
            require('includes/single.php');
        } else if ($cat) {
            require('includes/category.php');
        } else if ($m) {
            require('includes/month.php');
        } else if ($year) {
            require('includes/year.php');
        } else {
            require('includes/main.php');
    }
    endforeach; else:
        require('includes/nomatches.php');
    endif;
    ?>
</div>

In the external files themselves, simply put what content you want to appear, and that’s it! I hope this helps some of you guys out.


WP Plugin: Code Viewer

This article has been retired and will no longer be updated. Caveat emptor!

Code Viewer is a WordPress plugin that pulls source code from an external file and displays it, optionally adding a link to download the code directly. The plugin displays the code with proper indentation, line numbers, and automatic long-line wrapping.

When using Code Viewer, you no longer have to worry about typing countless entity references in order to make your code “HTML friendly” or to simulate tabs…it’s all done automatically with PHP and a little CSS. By inserting line numbers on your page, the plugin also eliminates the problem of long, non-breaking lines screwing up your layout. In addition, line numbers make convenient reference points when discussing code samples.

Last, but not least…because you’re pulling the source code from an external file (rather than having it embedded directly in your entry), the same code can be repeated on numerous pages, and you only have to type it in once. This not only saves you time, but when you update the code in the centralized file, all instances of that code will be updated along with it.

Installation

I am no longer maintaining Code Viewer, please see Current Status of the Code Viewer Wordpress Plugin for more details on where to get the latest version.

  1. Download Code Viewer v1.1
  2. Open the downloaded file in a text editor and configure the $default_path variable (found on line 12), setting it equal to the absolute path of your code folder
  3. Save the edited file
  4. Change the extension of the saved file from .txt to .php
  5. Upload the changed file into your wp-content/plugins/ directory.
  6. Activate the plugin on your WP Admin » Plugin Management page by clicking the corresponding “Activate” link under the Action column.

You’ll also want to add some new classes to your CSS that will control the look of the code listing. Everything (with the exception of auto-indention) works just fine without the CSS; but adding it in makes a huge difference on readability. Feel free to change these values to whatever you like, but this is how I have mine set up:

/* ---( CODE VIEWER FORMATTING )------------------------- */

ol.codelist {
    border: 1px solid #DDD;
    color: #C63;
    font-family: "Courier New", Courier, monospace;
    line-height: 130%;
    padding: 12px 12px 12px 45px;
    margin: 1.5em 0;
    }

ol.codelist li {
    margin: 0;
    padding: 1px 2px;
    }

ol.codelist li.tab0 { padding-left: 2px; }
ol.codelist li.tab1 { padding-left: 26px; }
ol.codelist li.tab2 { padding-left: 50px; }
ol.codelist li.tab3 { padding-left: 74px; }
ol.codelist li.tab4 { padding-left: 98px; }
ol.codelist li.tab5 { padding-left: 122px; }
ol.codelist li.tab6 { padding-left: 146px; }
ol.codelist li.tab7 { padding-left: 170px; }

ol.codelist li.odd { background-color: #FFF; }
ol.codelist li.even { background-color: #F0F0F0; }

ol.codelist li.sourcelink {
    color: #000;
    font: 115% Georgia, "Times New Roman", Times, serif;
    list-style: none;
    margin-left: -32px;
    padding-top: .85em;
    text-align: center;
    }

ol.codelist li code { color: #222; }

Usage

Code Viewer basically searches your entry for a custom XML tag named <viewcode />, that tells the server to look at an external file and parse it line-by-line into an ordered list. It can be placed anywhere a block-level tag is valid, and like any empty element in XHTML, the tag must be properly closed.

To better illustrate its usage, the tag used in this entry (to show the code-viewer.css listing above) was:
<viewcode src="2004/09/code-viewer.css" link="yes" />

Parameters

<viewcode src="URL" link="display" />

Here are some examples of valid syntax recognized by Code Viewer…note that all of these examples point to the same file (assuming the $default_path variable is set to "http://elasticdog.com/code/"):

<viewcode src="http://elasticdog.com/code/example.txt" link="no" />
<viewcode src="http://elasticdog.com/code/example.txt" />
<viewcode src="/code/example.txt" />
<viewcode src="example.txt" />

Each attribute value must be surrounded with double quotes ("), and not single quotes ('), or the tag will not be recognized.

Version History

Credits

The idea to use ordered lists in XHTML to present code, originated from Simon Willison’s CSS Numbered Code Listings blog entry. The same idea has been used by other designers, and in particular, a fellow WP plugin author named David House…

Looking at David’s code-snippet system, I fell in love with the idea, but thought his implementation could be improved upon. Code Viewer should be much more efficient in comparison and has the added functionality of optional link inclusion, styling differences for every other line, and better URL & file type support. A big thanks goes out to both David and Simon for their contributions to my latest creation.