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:
- 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:
…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:
- Story B, Part 3
- Story A, Part 1
- 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: 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:
- Whatever I do, it needs to make writing as easy as possible
- I wanted to keep the concept of Stories
- I also wanted to preserve having Characters and Locations, but find a easier way to manage them and their associations to Stories
- 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!
- 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 “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.
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:
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.
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.