Building a WordPress Site: Plugins

The reinvention of my site offered me a clean slate in many ways.  In this post, I’m going to delve into functionality driven by plugins. In total, I am using 17 plugins to drive both the front and back ends of my site.

I figured the easiest way to discuss them is by grouping them by their general functionality.

Administrative Plugins

To me, an administrative plugin is one that drives day-to-day operations in the blog’s back-end.

  • Akismet: delivered with all WordPress installs, it remains the easiest anti-spam solution for my needs.
  • Maintenance Mode: it allowed me to put up a “Coming Soon” page to keep visitors busy while I performed the steps for site relaunch.
  • Stats: some people are stat whores, digesting them down to the n<sup>th</sup> degree. While I think that Woopra is the best of class, I don’t have enough visitors to warrant paying for one of their packages.  This plug meets my simple statistical needs for free.
  • Contact Form 7: previously a user of the Contact Form ][ plugin, I’ve moved onto Contact Form 7, with an eye towards future expansion of forms on my site.
  • FeedBurner FeedSmith: I cannot remember what motivated me to use FeedBurner, but I continue to use it so I don’t lose my current subscribers.  FeedBurner’s tracking features might be handy someday, so it’s not a huge pain to continue going forth with it.
  • Subscribe To Comments: the one plugin I can’t live without, Subscribe to Comments is an important tool to encourage conversations 0n your content.  Without it, your readers aren’t as obligated to visit your Posts more than once.

Social Media Plugins

These plugins assist with getting the word out whenever I have published new content.  Because these plugins involves web services outside of my site, I’m occasionally at the mercy of Facebook or Twitter when attempting to cross-posts to their sites.

  • Wordbook: it notifies my Facebook Wall for each new post.  At one time, this was better than just linking your RSS feed to your Wall, as comments were directed to my site instead of my Wall.  Over time, Wordbook’s behavior — or Facebook — has changed, and comments are once again ending up exclusively on my Wall.  Is it too much to ask that all comments be kept in one, tidy place?
  • Twitter Tools: this notifies Twitter, and it used to work without issues.  However, the most-recent version (2.0) has been quite buggy of late, enough so that I had to downgrade to 1.6 in order for it to work.  Since it’s currently more work than it’s worth to debug, I’ve moved on to spending my time posting instead of fixing Twitter Tools.

Convenience Plugins

These plugins provide minor site tweaks with huge return.  In other words, my site would function just fine without them, but man! Am I glad they are there!

  • Top Level Categories: you can find many contrasting opinions on how to structure your permalinks.  As you know, WordPress will add the path “category/” before posts within a category (Example:  I personally peffer that all of my posts fall under the root site URL, which this plugin allows me to accomplish.  That same URL now reads as without the “category/” text in the middle.  This is important for my site’s future, as I plan to take up several simultaneous projects, each of which will be a series of posts under its own category.
  • WPtouch iPhone Theme: I occasionally like to read my site’s posts and comments from my iPhone.  This amazing plugin enables an iPhone-specific theme that is not only robust but also gorgeous to look at.

Book of Spam/Stories Plugins

Now this is where things get interesting!  These plugins are essential cogs in my site’s functionality, which is to display not only my regular blog content, but also serialized Stories with references to common Characters and Locations.

  • Custom Taxonomies: one of the most-useful plugins I’ve ever employed, its wizard helped me create the two custom Taxonomies: Characters and Locations.  Once I completed the wizard, each of these Taxonomies appeared in their proper place under my Pages menu in the Dashboard.  For details on how I use these Taxonomies, see my previous post in this series.
  • Media Tags: I wanted to display images associated to the Characters and Locations on each of their Term pages.  While I still needed a custom function to handle this (see Custom Plugins below), this plugin allowed me to categorize my images so they could be selected for display.  This was accomplished by tagging my images, as if I were adding Tags to a Post.
  • Redirection: using the Media Tags plugin creates one side effect: a like-named Taxonomy Page located at at  I didn’t want people to ever visit that Page, so configuring Redirection with that URL ensures noone accidentally visits it.
  • RSS Includes Pages: since my Stories are composed of Pages, they would never end up in my RSS feed.  RSS Include Pages changes that with one simple activation.
  • Page Excerpt: because Pages are now appearing in my RSS feeds, I use this plugin to enable the Excerpt field (on the Edit Page screen) and control what excerpt displays to my subscribers.  I’ve never understood why WordPress hides this field for Pages, but I’ve used this plugin for quite some to get around that limitation.
  • My Page Order: suggested by fellow, hyperlocal WordPresser Randy Hoyt, I use this plugin to order my Story Parts and take advantage of the delivered Page Order field.  My Page Order uses a simple drag-and-drop interface to facilitate this, allowing me to keep Parts correctly sorted even if written out of sequence.

Custom Plugins

Finally, I hit the point where other people’s plugins couldn’t solve all of my needs.  Because of this need for custom site-specific functionality, I created one single plugin to handle this.

  • Book of Spam: I went with a plugin — versus adding functions to my theme — so my code would be portable in case of a theme switch.  I also didn’t want to accidentally overwrite my functions in case of a theme upgrade.  At some point, if and/or when this site matures, I might take this plugin and offer it to the public for their use.  Specific functionality I added includes:
    • Featured Story: a series of functions to drive the prominent display of a featured Story on the Stories Page.
    • Lists of Characters and Locations: for both Story Parents and their Parts, the sidebar will list links of the Characters and Locations that play starring roles.  Each then links to the proper custom Taxonomy Term Page.  Look here for an example.
    • Story navigation: these functions display “previous” and “next” links where applicable, allowing users to easily flip between Story Parts.  You can see an example of these links here.
    • Custom Taxonomy image display: on the custom Taxonomy Pages for Characters and Locations, these functions will display thumbnails for any Character or Location featured on at least one published Story.  Then when viewing the Page for the custom Term itself, a larger image will be displayed — specifcally, any image whose Media Tags match the custom Term’s slug and also tagged with the word “default.”  For example, when viewing my Character Page, it is displaying an image with the Tags “spamboy” and “default.”  Anytime I ever want to change the image being displayed on that Page, I just untag the one image and apply the “default” Tag to another.
    • First Occurence of Term Replacement: to facilitate cross-site links, I created a function which takes the Post Body, searches it for whole-word occurences of Character and Location slugs, and replaces the first occurence of each with  link to said Character or Location.  I had hoped to code this as a CSS hover instead of a link, but I wanted to get something going quickly while I later readdress making things prettier.
    • Permit XHTML in Taxonomy descriptions: a simple WordPress filter allowing me to include links and images within the Taxonomy and Term descriptions.  Without this filter, any attempt to add HTML would lead to its eventual stripping out upon save.
    • Miscellaneous theme overrides: various changes I made to the Carrington theme to suit my tastes.  Changes include: display of comments links, minor sidebar widget enhancements, etc.

Coming Soon

In the final two posts of this series, I’ll delve into the migraiton plan that supported the go-live for my new site.  I’ll also touch upon how I plan to enhance my site once it’s been stable for a lengthy period of time.


Building a WordPress Site: Categories, Tags, Pages, and Permalinks

The relaunch of my blog has brought about radical changes in how I view Categories and Tags.  It also changed my approach to Pages (static content outside the timeline of my blog) and Permalinks (the designed URL for each of my Pages and Posts).  In this Post, I will discuss Categories & Tags and explain why I chose to change my approach towards both.

A Little Background

My old site presented content in two forms:

  • Stories
  • The Book of Spam

Stories allowed me to tell self-contained tales in multiple parts, allowing for literary constructs such as cliffhangers, epilogues, and prologues.  Each Story constituted of several parts as Posts linked to a parent Page, the latter of which served as an introduction to the overall Story.

One example was a story named “Enter the Spamboy” presented in four parts.  This meant I had a WordPress Page at the URL:

Enter The Spamboy

…and the four parts used that URL as the base for their own, as follows:

To establish this link between Story Parts and the Story Parent, each Story Part used a WordPress custom field to hold the unique ID of the Story Parent.  So if the Story Parent’s Page ID was 17, then each Story Part has a custom field named “story” whose value was “17”.

Besides Stories, The Book of Spam was an alternate way to present these Story Parts all at once.  Each Story had the potential to overlap with others.  The Book of Spam took all Story Parts and displayed them in chronological order.  For example, Part 1 of Story A might occur between Parts 3 and 4 of Story B. The examples would appear in this order within The Book of Spam:

  1. Story B, Part 3
  2. Story A, Part 1
  3. Story B, Part 4

This was accomplished by creating a root Page for TBoS:

…then assigning it a custom Page Template coded and added to my blog theme.  This custom Page Template’s code retrieved the Story Parts in chronological order and display them grouped into chapters.  Ordering Story Parts by chronology was accomplished by use of custom fields once again.  Each Story Part stored the chronology in a string format.  WordPress functions were used to enforce pagination, helping simulate the experience of flipping through the pages of a book.  Here are some samples of how the URLs appeared in The Book of Spam:

  • Table of Contents:
  • Preface:
  • Chapter:
  • Specific Page in Chapter:

To supplement Stories and The Book of Spam, I maintained Pages which listed the Characters and Locations that appeared in both.  Viewing these Pages provided you with a quick biography of each subject, plus a list of links to the Stories they starred in.  Once again, custom fields came to my rescue, allowing me to link Characters/Locations by adding their Page IDs to the Story Parts.

If all the above sounds complicated, it’s because it was. And such complexity was killing both my site and my creativity.

Why the Big Change

Well, several reasons:

  • Keeping my blog code and design up to date took valuable time away from actually writing posts
  • The rigidity of my design — being so focused on Stories — kept me from exploring other subjects more suitable to a blog format

I asked myself what I wanted to make of my new site, which led to the following short list of goals:

  1. Whatever I do, it needs to make writing as easy as possible
  2. I wanted to keep the concept of Stories
  3. I also wanted to preserve having Characters and Locations, but find a easier way to manage them and their associations to Stories
  4. The Book of Spam would be tabled for future consideration.  The time spent implementing this would delay go-live for my new design and pursing Goal #1: writing!
  5. I wanted the flexibility to post about other subjects I enjoy, such as WordPress and my artwork

How I Did It

It’s easiest for me to explain by diving into my blog design element-by-element, starting with…


On my old site, I used Categories to drive both the Stories and The Book of Spam.  For Stories, each Story Part would be assigned the Category “Stories”.

In addition, each Story Part would also be assigned a Category that coresponded to a chapter in The Book of Spam.  There was a parent Category (“Book of Spam”) with child Categories for Chapters (“Chapter 23”).

As a result, each Story Part would have multiple Categories, at least one of which was nested.  This required clever coding on my part to make everything display correctly, as WordPress doesn’t like mixing these Category structures.

On the new site, I’ve ended the use of Categories by Stories.  Instead, I have just two Categories used solely for my non-Story-related Posts

  • Personal: a bucket for personal thoughts and observations
  • WordPress: a subject-specific Category, since I plan to write more WordPress-specific content in the future — starting with this writeup of my blog design.  🙂

In the future, I may use Categories to drive timeline-based content for future projects.  For example, I am already contemplating posting some of my artwork, and I would likely create an “Artwork” Category to contain all art-related musings.


On my old site, I had more than 200 Tags.  Now I have zero.  At some point, I plan to start using Tags.  However, I much perfer to focus on writing Posts than wasting time trying to put them into buckets of Tags.  Once I’ve generated enough of a body of work, I’ll go back and tag my previous Posts.


Use of Pages has expanded on my new site.  I have your standard About and Contact Pages.

Stories are a different matter.  As I mentioned above, Categories are no longer used to drive Stories.  Also, Stories no longer consist of a lone WordPress Page linked to by multiple WordPress Posts.  Instead, each Story is 100% composed of Pages — one parent Page with multiple child Pages.  This means anything that Story Part previously a Post is now a Page.

This structure makes more sense than my previous method, as mixing Pages and Posts is a mess in WordPress — it’s just not meant to be done.  And the work I did trying to make that work led to me composing unnecessary code to fix a problem I created.  By using all Pages, this allows me to leverage delivered WordPress behavior such as Page Order and Page-specific functions.

Finally, I have two Pages created to support my custom Taxonomies.  More on that below.


In years of reading about WordPress and best practices for Permalinks, I’ve come to realize I swim against the flow.  I’ve always used the custom Permalink structure “/%category%/%postname%/” and continue to use it here.  I’ve just always liked the look of it, as it reminds me of nested folders on my desktop machine.  It also works better on my new site, as I am no longer using nested Categories.  At some point, I might change to a “/%category%/%post_id%/” structure, just to ensure that I don’t run into a duplicate permalink issue within the same Category.

I even went so far as to remove the word “category” from the URL base.  So instead of “”, I now have “”, which I think better represents my aim for sorting my Posts into easily-accessible project-like URLs.  Some have said this leads to an SEO hit, but frankly, my dear…you fill in the rest.

Custom Taxonomies

A part of WordPress since the 2.3 days, custom Taxonomies are starting to get onto people’s radars thanks to their power and flexibility.  Thanks to the information within Justin Tadlock’s excellent tutorials, I’ve shifted to using custom Taxonomies to support my Characters and Locations.

Instead of assigning Characters and Locations to my Stories using custom fields, they are now presented as lists in my Edit Page screen.  And instead of needing to know the Page IDs of the Character/Locations to include in the custom fields, I instead just mark one or more checkboxes, and everything gets saved using the taxonomy model.  I can even create a new Character/Location while editing my Stories — no need to switch over to another screen to add either.

There are significant advantages to using custom Taxonomies for this purpose:

  • Character and Locations are natural uses of Taxonomies
  • The interface is simple and intuitive, and I didn’t have to build it myself
  • Using Taxonomies allows me to use delivered WordPress Taxonomy functions in my theme files

All of this was accomplished by creating two custom Taxonomies, whose slugs are:

  • characters
  • locations

When you create a custom Taxonomy in WordPress, you have to define the context under which it will be available: either Pages, Posts, or Links.  I chose Pages, as the Characters and Locations are featured in Stories only, whose Story Parts are WordPress Pages (not Posts).

Everytime I edit a Page, I am given the option to pick Characters or Locations, just by defining the custom Taxonomy.  In turn, these Taxonomies are not available for use when editing Posts. WordPress also provides screens for Taxonomy maintenance, just like the Edit Tags screen in your Dashboard.

WordPress Pages are automatically generated for each custom Taxonomy Tag.  Once again, this is automatic with no extra action required on my behalf.  In turn, these Pages are available the second I create the new Tag.  For example, if I added a new Character named “Cletus”, you could go immediately to his Page ( and see information about that lovable slack-jawed yokel.

You can see this in action now by viewing my own Character biography at

My picture and the text below it are what’s stored in the Tag’s Description field.  All I did was modify my WordPress theme to display that Description when viewing a custom Taxonomy’s Tag Page.


As you can see, alot of work went into designing my website — not the look-and-feel, but its structure.  This in turn guided the development of the custom code that drives it.  If anyone has any questions about the above, please let me know.  Thanks again to Justin Tadlock for his tutorials!

In my next post in this series, I plan to walk you through the Plugins I am using.

Building a WordPress Site: Introduction

In a separate Post, my blog yelled, “Hello World” as I launched its redesign.  The amount of time it took me to make that announcement was less than 1% of the time it took me to recreate my website.

Rather than taking my old site and upgrading it to use new themes and plugins, I went with the more favorable approach of nuking it all and re-implementing from scratch.

I could have performed an upgrade on my existing blog, but going forward with a re-implementation provided me with far more advantages than drawbacks.  The former include:

  • I now have a true blank slate.  No more clutter of half-finished posts and spit-and-waddle code patches distracting Ol’ Captain OCD here
  • My speed to publish has been improved.  In addition to taking advantage of the New Post panel in the latest WordPress release, I’ve also been able to setup custom widgets to enter associated data from my custom Taxonomies (more on this later)
  • WordPress core file updates can be performed Day One.  My previous mess of custom code would have surely been broken by a major WordPress upgrade, so I am safe (for now)
  • Security has been improved.  For example, I no longer have a WordPress account called “admin”, which was a vulnerability that required an unexpected security release.  Database tables now have a custom prefix
  • I can integrate more easily with social media. My old site format was heavily centered around writing long-form non-fiction instead of smaller, more-frequent posts.  Thanks to my design shift, my shorter posts can cross-post more easily to platforms like Twitter, Facebook, etc.

In the end, I’ve come away with a leaner, quicker blog, capable of supporting a variety of material, not just a few types.  For you stats hounds, here’s a rundown of the numbers:

Object/Element Old Site Design New Site Design Details
Days in Development Unknown 3 total work days (24 hours) All work was performed in 30-60 minute chunks over the course of several lunch breaks and late-night DVR viewings
Posts 80 0 Remember the blank slate part? I may migrate some content from the old site, but overall I plan to proceed from scratch
Pages 41 3 One Page supports a Contact form, just like on the old design. The other two support my custom Taxonomies (more on this later)
Categories 49 2 Categories drove a book layout on my old design, complete with multiple Chapters. Book tructure is now handled using the delivered WordPress Page hierarchy
Tags 238 0 I went insane with Tags on the old design, making them useless for searching. On the new design, I will hopefully be more prudent and manage them better
Custom Taxonomies 0 3 Custom taxonomies are key to driving my Stories framework (more on this later)
Plugins 10 24 This number increased so dramatically because I am using plugins to handle minor tasks I had previously done via custom code. This allows me to leverage code (within the plugins) which has been road-tested by others

In future posts, I’ll deep-dive into some details on my design, including:

  • Thoughts on the Carrington Theme I am using, and why I chose it over other worthy candidates
  • A detailed compare/contrast between my old and current use of Categories and Pages
  • A walk-through of my custom Taxonomies and how they are driving user-friendly workflow in my new design
  • Quick-hits regarding the Plugins I am using
  • How I created a migration plan that walked me through the dangers of converting a live production site from one design to another
  • Future plans for this blog, mostly centered around what I’ll be writing but also touching upon some fun development I will also tinker with