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.
• WordPress.com Stats: some people are stat whores, digesting them down to the n^th 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: http://spamboy.com/category/wordpress).  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 http://spamboy.com/wordpress 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 http://spamboy.com/media-tags/.  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.

<sup>superscripted!</sup>

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:

http://spamboy.com/stories/enter-the-spamboy/

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

http://spamboy.com/stories/enter-the-spamboy/enter-the-spamboy-part-1/
http://spamboy.com/stories/enter-the-spamboy/enter-the-spamboy-part-2/
http://spamboy.com/stories/enter-the-spamboy/enter-the-spamboy-part-3/
http://spamboy.com/stories/enter-the-spamboy/enter-the-spamboy-part-4/

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:

http://spamboy.com/book-of-spam/ (Note: there is a reason this is not a hot link; see below)

…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: http://spamboy.com/book-of-spam/
• Preface: http://spamboy.com/book-of-spam/preface/
• Chapter: http://spamboy.com/book-of-spam/part-ii/chapter-20/
• Specific Page in Chapter: http://spamboy.com/book-of-spam/part-ii/chapter-20/page/5/

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…

Categories

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.

Tags

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.

Pages

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.

Permalinks

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 “http://spamboy.com/category/wordpress/”, I now have “http://spamboy.com/wordpress/”, 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 (http://spamboy.com/characters/cletus/) and see information about that lovable slack-jawed yokel.

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

http://spamboy.com/characters/spamboy/

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.

Wrapup

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.

John Bickerstaff, writing yesterday on the WordPress for iPhone blog, has indicated that the application will be going down the path of iPhone OS 3.0 compatability.  Whatever that means.

A majority of the changes delivered with iPhone OS 3.0 were global changes like cut-and-paste, landscape keyboard, and Safari improvements, all of which are accessible today using the current version of WordPress for iPhone.  So what could the application do that’s not already being done?

What would be more interesting is if the WordPress for iPhone application took advantage of the benefits of the hardware upgrade that comes with the iPhone 3GS.  Specifically, video capability — the ability to vlog from anywhere in a minimal number of steps would be quite killer.

I hope that the upcoming 1.4 beta release addresses many of the application’s pedestrian features, including:

• User Interface: compared to other applications, the GUI is horrid. Ugly, sluggish, and non-intuitive. I would easily compare it to that of the Facebook for iPhone application — except that in its latest release, it corrected these shortcomings and delivered a powerful user interface.
• Category and Tag Management: assigning these to your posts from the iPhone is a painful process, especially since these lists do not synchronize well between phone and server
• Custom Taxonomies: unsupported in the current version and critical to running my current blog’s incarnation
• Option to Force Server-Side Drafts: I have no desire to create post drafts on my iPhone, as a catastrophic hardware failure or theft would undo my work. If possible, I’d much prefer that they be created on my blog always and never provide me the option to do otherwise.

New site, new theme. Simple as that, right? Right…? Bueller…?

Before I discuss themes, I need to declare the #1 self-imposed rule during this site’s redeisgn: do not do a Big Bang approach.

This is because past incarnations of this site involved big ideas, all of which I wanted to see implemented at once.  This led to a never-ending coding cycle that kept me from writing actual blog content.  This time around, I wasn’t going to be slowed down from my set goal of a two-week project cycle, even if it meant some of my ultimate ideas would have to come in the future.

For my rule to work, I had to make quick decisions and roll with them.  This led me to spend just 15 minutes looking for a new theme in the WordPress theme directory.  I quickly stumbled upon Crowd Favorite’s Carrington theme and it proved to be a winner for several reasons:

• It is cutting edge. Carrington is incredibly young in dog years.  Instead of your standard WordPress template files, it provides an engine to piece together the user presentation from a variety of sub-templates, the selection of which is defined by the viewing context.  For example, viewing the About page vs. a Category archive could show you different sidebars, content areas, headers, and more, depending on how you design it.  You can even control what’s displayed when viewing posts by different authors.
• Sub-template file organization is logical. As mentioned above, many sub-templates combine to make full templates.  These sub-templates are stored in context-specific folders.  For example, the various sub-templates which display post content are in the “content” directory.  There are also folders for other elements: “sidebar”, “loop”, “header”, etc.
• Customization was quick and easy. I am addicted to changing any code which resides on my site.  For WordPress, this is because the themes and plugins I use only meet 90% of my needs, and I have to supply the rest.  Making changes to Carrington was easy.  I housed my custom code in custom sub-templates outside the core theme files.  Also, these smaller chunks of code were much easier to handle during the debugging process than a larger template file.
• Upkeep should be a piece of cake. As noted above, my custom code is contained within custom sub-templates.  Since I barely touched the core files, upgrading Carrington down the line should be as simple as overwriting the existing core files with the latest release.  This is a huge improvement over my previous blog designs, which would require side-by-side comparison between new and existing files then manual reapplication of my code.
• The price is right. In other words, it was free!

Actually, I shouldn’t brag so much about the theme being free.  The developers at Crowd Favorite have earned my gratitude for providing such a robust framework while only asking for attribution in return.  The matching documentation on their website was also quite useful.  Besides the few hours it took me to get oriented after first installing it, Carrington proved to be an easy theme framework to work with.

At some point in the future, I will skin Carrington to appear like the site I want vs. looking like all other Carrington sites out there. This is one of the many things I’ve put off to the future in order to get rolling today.

That’s the skinny on themes.  My next post will compare & contrast use of Pages and Categories between my current and old designs.  If you haven’t already, check out my previous post about the site redesign.

Anyone involved with rolling out changes to production systems knows that there’s always something that goes wrong, no matter how trivial.  I was bitten by two immediate issues with this week’s relaunch.  One was fixed easily, the other not quite so quickly. For those interested, a run-down:

1. Nuking my site and starting from scratch broke use of the WordPress for iPhone application.  I received the “Precondition Failed” error discussed in this thread on the WordPress Support Forum.  It appears I had lines in my .htaccess file which fixed this months ago, and reapplying them restored functionality once again.
2. Alex King’s Twitter Tools plugin — which provides the means for posting to Twitter anytime you publish on your blog — is not working.  The title of my post will appear in Twitter, but sans URL (shortened or full).  This is not a must-have feature for my site, although it does slow down my workflow to either find a fix or manually do the work a working plugin would automate.  As an alternative, Tony Cecala recommended TwitPress, but from what I read it would barf on scheduled Posts. My first plan of attack is to downgrade to a previous version of the plugin, then switch to manual updates if it continues to not work.  A few others have already discussed this on the Wordpress Support forum here and here.

Never a dull moment.

Update 9/4/2009: downgrading Twitter Tools to 1.6b2 is the current workaround to Issue #2 above. I’m awaiting a better solution when time permits