{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(); ?-->
Congrats! Way to get through the hurdles.
I’m doing displays of custom field data a bit differently, so I’ll be sure to get a post up so we can compare differences.
~Kyle~
Thank you so much, Kyle! It’s not very clear from this post but your help got me past the major hurdles.
Almost thought of emailing you a question about images, at some point. But using the featured image makes more sense, to me.
Though it’s not Perl, I still follow the TIMTOWTDI motto. What I like about this method is that I understand it fairly well.
Still haven’t solved the title column issue, but I might use the person’s full name when it’s a person. I’ve also been thinking about using Gravatars and such.
Again, thanks a lot for your help.
—
Alex