Our Blog

Bending WordPress

Posted by
5 May 2011
1 comment

WordPress 3 has been with us for almost a year now, yet few realize exactly what the changes that came with it imply.

This week’s tech insight will give you the bigger picture on what can be done with WordPress, mainly as a result of three (relatively) new features:

  1. Custom Post Types
  2. Custom Taxonomies
  3. Custom Data Fields (pre-defined)

Bending WordPress

The History

When WordPress was started in 2003 (as an open source project, which it still is), it probably had as little ambition to be the world’s leading CMS as Twitter had to become the world’s leading news wire. WordPress started its life as a small tool to enhance typography and quickly turned into a blogging platform.

Fortunately, it was adaptable enough to turn into exactly what its users wanted it to be, partly because of the fact that, being open source, it is created by its users. So, more and more it started turning into a Content Management System (CMS), slowly but surely obliviating the distinction between blog and website.

Still, the debate raged on whether WordPress could be called a CMS or not, with the traditional CMS side of the argument progressively stiffening in their stance.

Then came 3.0.

Custom Post types

WordPress has two main built-in post types: Posts and Pages. Actually there are more, like Attachments and Revisions, but the others are slightly less visible. In a nutshell, Posts are blog updates, typically organized by date, and Pages contain static content, like an About page, typically organized by hierarchy. These are the two main components of a blog.

This is not the full story though. WordPress’ plugin and theme infrastructure is so immensely open and extendable, that any half-decent PHP developer can, without changing the WordPress core at all, turn it into anything they want.

In other words, the effort of bending WordPress is almost as little as using it, and herein lies the key to its success.

Having said this, the WordPress back end has always been very much blog oriented. And the more you bent it, the more you had to train a client exactly how to use the back end in order to get their content up. Something along the lines of:

“so when you want to publish a new podcast, create a new post, but don’t give it any content. Do give it an excerpt though … no, that’s the bottom block … then manually check the mp3 file length and enter that into …”

Not nice. Well, not anymore …

Custom Post Types allow you to create any new data type. Not just content, but literally anything that you’d like to store and present in some way or another, and mold the back end to make sense for the person who will eventually have to enter the data.

By using Custom Taxonomies, the equivalent of Tags and/or Categories can be created under a different description and applied to a specific Post Type. For instance, on an Event Post Type, a Speaker Custom Taxonomy can be created, to list the speakers at the event.

By using Custom Data Fields, specific attributes of Custom Posts can be extracted and exposed for editing. For example, when editing an MP3 Download Post Type, the Artist and Album can be extracted from the ID3 tag in the MP3 file, and exposed as Custom Data Types, which the person who’s uploaded it can change if they want to.

Why do people misunderstand Custom Post types?

Well, to begin with, Custom Post Types are actually a misnomer. According to WordPress UI Guru Jane Wells:

” … they just got named poorly because they live in the Posts table in the database … “

Custom Post Types should actually be called Custom Content Types, or maybe even Custom Data Types (since it can be used for more than just content). More than just content?

Some Saucy Examples

Ok – obviously there’s a lot you can do with Custom Post Types for different types of content. But where’s the fun in that? Let’s think completely outside the box:

  • Company Info Post Type
    Every company website has certain info about them that appears in various places, like the address, telephone number, twitter handle, etc. Why not create a non-public Post Type (not meant to be queried & displayed on its own), but that is always available when you need it, like in the header, footer, contact page, etc.
  • Client Post Type
    You could run your entire invoicing & bookkeeping system on WordPress with the right Post Types. Deliverables as Freeform Custom Fields, Total and Sales Tax as Defined Custom Data Fields, and the Client Post Type’s monthly archive page displays that month’s invoice (with a button to send it via email). Nice!
  • API Call Post Type
    Instead of making the template that deals with the display of this Post Type display HTML, why not let it churn out XML or JSON? This way, WordPress becomes the platform for hosting your entire API or the server-side components for your AJAX calls.

So, as you can see, WordPress has not really become a CMS at all. WordPress has become a complete platform on which, amongst other systems, you can also build CMS’s. Now there’s something to think about.

Posted by

1 Trackback

Leave a Comment

Your email is never shared. Required fields are marked *