9rules - The best content from the independent web.

The response from the last episode was overwhelming. Thanks to everyone that commented, emailed, instant messaged me, and linked back to that post from your own sites.

Last time we discussed how I used mostly smoke and mirrors to build our data structure using WordPress. Things didn’t change much for quite sometime, but I thought I’d jot down how we used custom fields to store the meta-data we needed for each member, rather than hacking WordPress’ fields in order to store our data.

Custom fields to the rescue

WordPress allows for unlimited and even duplicate custom fields per post. For every project I’ve used WordPress for, custom fields are probably the feature I use most. For more information on using WordPress’ custom fields, I suggest reading the Codex page of “Using Custom Fields“.

At this point in our story, still late-Spring or early Summer 2005, we only stored 3 custom fields per member. We needed a place to store the member’s URL, feed URL, and Author name(s). Instead of utilizing one of WordPress’ existing fields, and using it improperly, we opted to use custom fields which makes it easy to keep this data up-to-date per member.

Getting the data I need out of each custom field is not only easy, but convenient at any given time in my code. Typically when Mike Rundle turns over a comp to me, he will ask “Hey homie, is there a way to stick the Author’s name in there? Not sure how hard that would be.”. I left in his misspelling of homey, for authenticity purposes. He stopped asking that question rather quickly when I replied: “At any point, on any page, at any time, I can put any members data wherever I’d like, without even thinking of ‘how to do it’”. That was all he needed to hear. But how do I pull it off? We’re working with WordPress created data, am I in THE_LOOP? Am I using a plugin for the_post()? None of the above, here is a simple function that allows me to snatch the then existent custom fields we were using.

function siteInfo($id='') {
global $wpdb;

if ($id && $id != '') {

// Per site info
$member_author = get_post_meta($id, 'Site owner', true);
$member_rss = get_post_meta($id, 'RSS', true);
$member_url = get_post_meta($id, 'URL', true);

$siteInfo = array(
			'id'=>$id,
			'url'=>$member_url,
			'rss'=>$member_rss,
			'author'=>$member_author);

} else {

// There was an error
$siteInfo = array(
			'error_number'=>1,
			'error_text'=>'No site_id was given');

} // end if $id

return $siteInfo;
}

At any point in my code, I can run this function and retrieve the data I need for any of our members, and should I accidently not give it an $id it will end up giving me a definitive error that will be immediately recognizable.

As a side note, whenever I’m building datasets based on any number of variables, I typically return them as multidimensional associative arrays. This makes it much easier to check for validity, for referencing later in your code, and just making the data generally available at anytime you need it.

You might be asking where we stored the title, or name, of each member’s Web site. We stored this in the title field, so I typically had the $id and $post_title at any point when I would need to use siteInfo(). That is why that particular function does not need to fetch the title, or name, of the Web site - because I already have them in memory at that point.

The possibilities are endless

For those of you that feel limited using WordPress, and feel that just about any other CMS will work for you better, remember custom fields. It really makes the possibilities endless, per post, for what you’re able to accomplish. Over at TheUberGeeks.net, we use several custom fields to create our featured posts. We have custom fields such as; featured_art, featured_caption, album_art, cover_art, and a few others that allows us to display more than the typical content that WordPress would allow out of the box. Om Malik of GigaOm.com uses custom fields, by the assistance of a few plugins, to control his “Featured Post” of the day. Most of these examples are non-complex and generally easy to duplicate, should you use WordPress for your site and you’d like to extend your capabilities.

In our next episode, which I call Revenge of the Server, we’ll get into how I used our page views to build our cache of member data (it was my only choice at the time), and how Media Temple came to our rescue. The smoke and the mirrors had to be replaced with viable solutions at some point, right?!