{I tend to ramble a bit. If you just want a step-by-step tutorial, you can skip to here.}
Woohoo!
I feel like I’ve reached a milestone in a project I’ve had in mind, ever since I learnt about Custom Post Types in WordPress 3.0: Using WordPress as a content directory.
The concept may not be so obvious to anyone else, but it’s very clear to me. And probably much clearer for anyone who has any level of WordPress skills (I’m still a kind of WP newbie).
Basically, I’d like to set something up through WordPress to make it easy to create, review, and publish entries in content databases. WordPress is now a Content Management System and the type of “content management” I’d like to enable has to do with something of a directory system.
Why WordPress? Almost glad you asked.
These days, several of the projects on which I work revolve around WordPress. By pure coincidence. Or because WordPress is “teh awsum.” No idea how representative my sample is. But I got to work on WordPress for (among other things): an academic association, an adult learners’ week, an institute for citizenship and social change, and some of my own learning-related projects.
There are people out there arguing about the relative value of WordPress and other Content Management Systems. Sometimes, WordPress may fall short of people’s expectations. Sometimes, the pro-WordPress rhetoric is strong enough to sound like fanboism. But the matter goes beyond marketshare, opinions, and preferences.
In my case, WordPress just happens to be a rather central part of my life, these days. To me, it’s both a question of WordPress being “the right tool for the job” and the work I end up doing being appropriate for WordPress treatment. More than a simple causality (“I use WordPress because of the projects I do” or “I do these projects because I use WordPress”), it’s a complex interaction which involves diverse tools, my skillset, my social networks, and my interests.
Of course, WordPress isn’t perfect nor is it ideal for every situation. There are cases in which it might make much more sense to use another tool (Twitter, TikiWiki, Facebook, Moodle, Tumblr, Drupal..). And there are several things I wish WordPress did more elegantly (such as integrating all dimensions in a single tool). But I frequently end up with WordPress.
Here are some things I like about WordPress:
- Free Software ethos.
- Neat “.org vs .com” model for Open Source blogging software and freemium blogging service.
- Broad user and support communities around both the software and the service.
- WordCamps are a useful way to deepen knowledge of the software (and, to an extent, the service).
- The software is remarkably flexible.
- The service has some neat features, both free and paid.
- The software is easy to install on just about any webhost.
- The service is free in cost and headaches.
- Both software and service offer nice learning curves.
This last one is where the choice of WordPress for content directories starts making the most sense. Not only is it easy for me to use and build on WordPress but the learning curves are such that it’s easy for me to teach WordPress to others.
A nice example is the post editing interface (same in the software and service). It’s powerful, flexible, and robust, but it’s also very easy to use. It takes a few minutes to learn and is quite sufficient to do a lot of work.
This is exactly where I’m getting to the core idea for my content directories.
I emailed the following description to the digital content editor for the academic organization for which I want to create such content directories:
You know the post editing interface? What if instead of editing posts, someone could edit other types of contents, like syllabi, calls for papers, and teaching resources? What if fields were pretty much like the form I had created for [a committee]? What if submissions could be made by people with a specific role? What if submissions could then be reviewed by other people, with another role? What if display of these items were standardised?
Not exactly sure how clear my vision was in her head, but it’s very clear for me. And it came from different things I’ve seen about custom post types in WordPress 3.0.
For instance, the following post has been quite inspiring:
I almost had a drift-off moment.
But I wasn’t able to wrap my head around all the necessary elements. I perused and read a number of things about custom post types, I tried a few things. But I always got stuck at some point.
Recently, a valuable piece of the puzzle was provided by Kyle Jones (whose blog I follow because of his work on WordPress/BuddyPress in learning, a focus I share).
Setting up a Staff Directory using WordPress Custom Post Types and Plugins | The Corkboard.
As I discussed in the comments to this post, it contained almost everything I needed to make this work. But the two problems Jones mentioned were major hurdles, for me.
After reading that post, though, I decided to investigate further. I eventually got some material which helped me a bit, but it still wasn’t sufficient. Until tonight, I kept running into obstacles which made the process quite difficult.
Then, while trying to solve a problem I was having with Jones’s code, I stumbled upon the following:
Rock-Solid WordPress 3.0 Themes using Custom Post Types | Blancer.com Tutorials and projects.
This post was useful enough that I created a shortlink for it, so I could have it on my iPad and follow along: http://bit.ly/RockSolidCustomWP
By itself, it might not have been sufficient for me to really understand the whole process. And, following that tutorial, I replaced the first bits of code with use of the neat plugins mentioned by Jones in his own tutorial: More Types, More Taxonomies, and More Fields.
I played with this a few times but I can now provide an actual tutorial. I’m now doing the whole thing “from scratch” and will write down all steps.
This is with the WordPress 3.0 blogging software installed on a Bluehost account. (The WordPress.com blogging service doesn’t support custom post types.) I use the default Twenty Ten theme as a parent theme.
Since I use WordPress Multisite, I’m creating a new test blog (in Super Admin->Sites, “Add New”). Of course, this wasn’t required, but it helps me make sure the process is reproducible.
Since I already installed the three “More Plugins” (but they’re not “network activated”) I go in the Plugins menu to activate each of them.
I can now create the new “Product” type, based on that Blancer tutorial. To do so, I go to the “More Types” Settings menu, I click on “Add New Post Type,” and I fill in the following information: post type names (singular and plural) and the thumbnail feature. Other options are set by default.
I also set the “Permalink base” in Advanced settings. Not sure it’s required but it seems to make sense.
I click on the “Save” button at the bottom of the page (forgot to do this, the last time).
I then go to the “More Fields” settings menu to create a custom box for the post editing interface.
I add the box title and change the “Use with post types” options (no use in having this in posts).
(Didn’t forget to click “save,” this time!)
I can now add the “Price” field. To do so, I need to click on the “Edit” link next to the “Product Options” box I just created and add click “Add New Field.”
I add the “Field title” and “Custom field key”:
I set the “Field type” to Number.
I also set the slug for this field.
I then go to the “More Taxonomies” settings menu to add a new product classification.
I click “Add New Taxonomy,” and fill in taxonomy names, allow permalinks, add slug, and show tag cloud.
I also specify that this taxonomy is only used for the “Product” type.
(Save!)
Now, the rest is more directly taken from the Blancer tutorial. But instead of copy-paste, I added the files directly to a Twenty Ten child theme. The files are available in this archive.
Here’s the style.css code:
/* Theme Name: Product Directory Theme URI: http://enkerli.com/ Description: A product directory child theme based on Kyle Jones, Blancer, and Twenty Ten Author: Alexandre Enkerli Version: 0.1 Template: twentyten */ @import url("../twentyten/style.css");
The code for functions.php:
<!--?php /** * ProductDir functions and definitions * @package WordPress * @subpackage Product_Directory * @since Product Directory 0.1 */ /*Custom Columns*/ add_filter("manage_edit-product_columns", "prod_edit_columns"); add_action("manage_posts_custom_column", "prod_custom_columns"); function prod_edit_columns($columns){ $columns = array( "cb" =--> "<input type="\"checkbox\"" />",
"title" => "Product Title",
"description" => "Description",
"price" => "Price",
"catalog" => "Catalog",
);
return $columns;
}
function prod_custom_columns($column){
global $post;
switch ($column)
{
case "description":
the_excerpt();
break;
case "price":
$custom = get_post_custom();
echo $custom["price"][0];
break;
case "catalog":
echo get_the_term_list($post->ID, 'catalog', '', ', ','');
break;
}
}
?>
And the code in single-product.php:
<!--?php /** * Template Name: Product - Single * The Template for displaying all single products. * * @package WordPress * @subpackage Product_Dir * @since Product Directory 1.0 */ get_header(); ?--> <div id="container"> <div id="content"> <!--?php the_post(); ?--> <!--?php $custom = get_post_custom($post--->ID); $price = "$". $custom["price"][0]; ?> <div id="post-<?php the_ID(); ?><br />">> <h1 class="entry-title"><!--?php the_title(); ?--> - <!--?=$price?--></h1> <div class="entry-meta"> <div class="entry-content"> <div style="width: 30%; float: left;"> <!--?php the_post_thumbnail( array(100,100) ); ?--> <!--?php the_content(); ?--></div> <div style="width: 10%; float: right;"> Price <!--?=$price?--></div> </div> </div> </div> <!-- #content --></div> <!-- #container --> <!--?php get_footer(); ?-->
That’s it!
Well, almost..
One thing is that I have to activate my new child theme.
So, I go to the “Themes” Super Admin menu and enable the Product Directory theme (this step isn’t needed with single-site WordPress).
I then activate the theme in Appearance->Themes (in my case, on the second page).
One thing I’ve learnt the hard way is that the permalink structure may not work if I don’t go and “nudge it.” So I go to the “Permalinks” Settings menu:
And I click on “Save Changes” without changing anything. (I know, it’s counterintuitive. And it’s even possible that it could work without this step. But I spent enough time scratching my head about this one that I find it important.)
Now, I’m done. I can create new product posts by clicking on the “Add New” Products menu.
I can then fill in the product details, using the main WYSIWYG box as a description, the “price” field as a price, the “featured image” as the product image, and a taxonomy as a classification (by clicking “Add new” for any tag I want to add, and choosing a parent for some of them).
Now, in the product management interface (available in Products->Products), I can see the proper columns.
Here’s what the product page looks like:
And I’ve accomplished my mission.
The whole process can be achieved rather quickly, once you know what you’re doing. As I’ve been told (by the ever-so-helpful Justin Tadlock of Theme Hybrid fame, among other things), it’s important to get the data down first. While I agree with the statement and its implications, I needed to understand how to build these things from start to finish.
In fact, getting the data right is made relatively easy by my background as an ethnographer with a strong interest in cognitive anthropology, ethnosemantics, folk taxonomies (aka “folksonomies“), ethnography of communication, and ethnoscience. In other words, “getting the data” is part of my expertise.
The more technical aspects, however, were a bit difficult. I understood most of the principles and I could trace several puzzle pieces, but there’s a fair deal I didn’t know or hadn’t done myself. Putting together bits and pieces from diverse tutorials and posts didn’t work so well because it wasn’t always clear what went where or what had to remain unchanged in the code. I struggled with many details such as the fact that Kyle Jones’s code for custom columns wasn’t working first because it was incorrectly copied, then because I was using it on a post type which was “officially” based on pages (instead of posts). Having forgotten the part about “touching” the Permalinks settings, I was unable to get a satisfying output using Jones’s explanations (the fact that he doesn’t use titles didn’t really help me, in this specific case). So it was much harder for me to figure out how to do this than it now is for me to build content directories.
I still have some technical issues to face. Some which are near essential, such as a way to create archive templates for custom post types. Other issues have to do with features I’d like my content directories to have, such as clearly defined roles (the “More Plugins” support roles, but I still need to find out how to define them in WordPress). Yet other issues are likely to come up as I start building content directories, install them in specific contexts, teach people how to use them, observe how they’re being used and, most importantly, get feedback about their use.
But I’m past a certain point in my self-learning journey. I’ve built my confidence (an important but often dismissed component of gaining expertise and experience). I found proper resources. I understood what components were minimally necessary or required. I succeeded in implementing the system and testing it. And I’ve written enough about the whole process that things are even clearer for me.
And, who knows, I may get feedback, questions, or advice..