In my previous post I discussed the importance of good admin user interface (UI) Design. Now I want to start talking about some of the tools available in WordPress that are designed to help a developer achieve this and some of the things to avoid.

The first thing I want to look at is custom post types and taxonomies.

History of Custom Post Types

Different types of posts have existed in WordPress for a long time. For example “posts”, “pages”, “attachments”, “revisions” and “menus” are all examples of different post types. Version 3.0 of WordPress which was released in June of 2010 gave us the ability to add custom post types.

Seriously, this has been there since 2010, finding out this information was a shocker for me. I have been looking at WordPress sites created by others for most of the 3 years that this has been available but I never saw any hint of these mysterious “Custom Post Types” in use. So I didn’t even know they existed until Site-Seeker decided to adopt WordPress as its primary CMS and I began digging into them.

So why didn’t most of the sites I’ve dealt with use them?

1. Like me, the developer didn’t know about them. This for me is the worst excuse. When Site-Seeker adopted WordPress as its primary CMS I read everything I could about it. If I’m going to call myself a WordPress developer then I really ought to know what I’m talking about. I spent many hours reading about it and researching what can and cannot be done. For another developer that considers themselves to be a good WordPress developer to not know about custom post types or use them if they do does not tell me good things about that developer.
2. Using custom post types may increase development time and requires, at a minimum, adding custom theme templates. From my experience most of the work I’ve seen involved taking the default WP theme and modifying it to work for a particular need. This is great as long as you don’t need anything special and you’re just going to use pages and posts. In other words, this is great if you’re going to have a handful of pages on your site and focus on blogging. If you’re going to add more complicated data, such as a warehouse of products, then you really need a custom theme. Building a custom theme from scratch, it seems, is beyond the ability of the average person that calls themselves a WordPress Developer. Using an existing theme for more than simple brochure sites is one of the things that leads to a poor admin UI. The only exception to this is if the theme you use meets your needs exactly without any modification.
3. There’s some controversy over the use of custom post types. Some developers think that custom post types and the data associated with them should be controlled only by plugins. Others think it is okay to have it controlled by the theme. I’m with the majority on this one in that data for a custom post type should be controlled only by a plugin. The reason for this is that even if you do decide to change themes or have a new theme built then the data will still be available in the back-end even if the theme is not capable of displaying that data. Data is never lost and your new developer does not need to worry about maintaining data, only about displaying the data that is already there and you can already manage. So, using custom post types usually means that the developer not only needs to be skilled at creating a custom theme to display your data but also needs to have some skill at creating a plugin that will manage that data, or be adept at using a plugin designed for this purpose.

Overview of Custom Post Types

Technical details about post types and custom post types can be found in the WordPress Codex. I’m not going to go into those details, what I want to discuss is how and why they make for a better UI.

In a nutshell, custom post types and taxonomies allow you to separate different types of data so that it is easier to manage.

More about the benefits of Custom Post Types:

• Help organize pages or “posts” of a similar type into a group
• Have a custom display of content without complicated hard coding of queries to retrieve only posts or pages of a specific category, tag or with a specific custom field.
• Each custom post type can have its own fields and requirements that do not appear on other post types in the editor.
• Allow for easier management and organization of content
• Increase usability. It is much easier for a client to understand that if they need to create a new “Product” to simply click on the “Products” tab in the admin menu rather than needing to remember they need to create a “Post” with a specific category and possibly additional steps.
• Reduces the need for additional plugins that may be insecure or may not be actively supported
• Improve productivity
• Can have their own custom taxonomies that have no effect on other post types or pages

Overview of Custom Taxonomies

I found that taxonomies is a difficult concept for some people to wrap their head around. I had a hard time with this at first. Many people just say that they are like categories, but in reality a category is just a type of taxonomy. A good place to read about what a taxonomy is at Wikipedia. I also cover them in a recent post I did about the different types of pages on a WordPress site.

Basically a taxonomy is a way to separate things. For example, if you have a site with products you may “Categorize” your products by product type or brand. “Product Type” and “Brand” are Taxonomies. Each of these are then further separated into different specific product types or brands, these are the “Categories” and WordPress calls these “Terms.”

How Do Custom Post Types and Taxonomies Improve the Admin UI

Let’s say for example you’re a manufacturer and you want to create a section of your site that shows the various products that you make.  You don’t deal directly with consumers, so your site is so that possible distributors can see what you do. We don’t really need a shopping cart or any type of eCommerce solution, we simply want to show products and we want to format them in a way that is different than other pages on the site and maybe we even want to separated them by different types of products.

The typical way that I’ve seen this done is that the developer adds a “post category” named “products” and then creates sub-categories below this category for the different product types. Then adds several custom fields through one of the products to hold various product specific information. Then they hack the “category.php” template to display the product categories and the “single.php” template to show the product-specific data when the “post” is in the “products” category. The special queries and coding that needs to be added generally makes it difficult for other developers to maintain or modify your site, not to mention slowing down your page load times because they have to do additional queries to get the correct data on top of those already done when WordPress loads.

Let’s look at the typical instruction set for adding a product in this scenario:

1. Click on Posts => Add New
2. Make sure you select one of the categories that is a sub-category of the “Products” category
3. Don’t select any of the other categories or your product will appear as a blog post or in some other part of your site.
4. Make sure that the custom fields section is displayed on the edit page. To do this click on the “Screen Options” tab at the upper right of the edit page and make sure that the “Custom Fields” option is checked.
5. Scroll down to the custom fields section of the page and do the following.
   1. Select the field “product_number” or click the “enter new” button and enter “product_number” into the field.
   2. Enter the value of your product number.
   3. Make sure you enter the correct type of data for the field you are editing
   4. Click Add Custom Field
   5. Repeat a thru d above for the following fields
      1. diameter
      2. bore
      3. teeth
      4. bevel
      5. depth
      6. fastener_type
      7. offset
      8. Etc.
      9. Etc.

The above gets even more complicated if some of our fields contain HTML or images or other types of data. Not to mention that the UI is cluttered and hard to follow. Different people may add fields in different orders so that everything is in a different place on every product. You also must remember to add everything and you can’t always know what everything is by looking at the field list. I’ll discuss this more when I discuss custom fields in my next post.

Now let’s look at this same type of thing using a custom post type. In this case, I create a custom post type called “Product” and I add a custom Taxonomy to it called “Product Type”. (I’ll talk about the importance of using a custom taxonomy rather than the standard category in a bit.) Then I create 3 new template files: archive-product.php, single-product.php and taxonomy-product-type.php. These three templates will be cleaner to code because I don’t have to do any coding to see what “category” I am displaying and show different types of pages, WordPress automatically pulls the correct information so I don’t need to add any custom queries either.  Then I create a custom field group and add it to my custom post type.

The instructions for adding a product in this setup are:

1. Click on Products => Add Product
2. Select a product type
3. Add your product information

I don’t really even need to give instruction because it is evident just by looking at the UI where someone would edit products.

Of the two, the second will cause much less confusion for the client and make it easier for them to add and edit products. Another benefit is that these products have their own separate area so that the client does not have to scroll through all of the post of all of the various types to find the product to edit when they need to, they simply go to the “Products” section and only products are listed.

The image at the right here shows the admin menu of a site I am currently working on. This site has 5 different custom post types. Can you imagine the mess if all of the data in these were all crammed into “posts” and each had its own special categories, tags and custom fields? Then add all the custom fields required on the editor pages for the taxonomies associated with these post types, unless you want the client to seek out a new developer I would not suggest doing it the typical way.

It is also important that you always create custom taxonomies to go with your custom post types. Why? This becomes evident when you have the standard “category” list on your blog page. If you use the standard “Category” and “Tags” taxonomies to separate your products you will find your product categories listed along with your blogs on the front end of the site. That is unless the developer also hacks theses standard queries and lists to remove them, more time wasted changing things instead of letting WordPress do the heavy lifting for you.

What to use Custom Post Types and Taxonomies For

You should use a custom post type for everything that is not a “Post” or a “Page”. The list is really endless. Any time that you are going to store data that is repeatable or should logically be a separate entity, like a product, then it should have its own post type to live in. Examples for which I’ve used custom post types include:

• Products
• Industries served
• A document library
• A directory of employees or staff
• A directory of addresses
• A list of distributors or vendors
• Photo Galleries
• Portfolios
• Resources

Even something as simple as a rotating home page banner can benefit from the use of putting them in a custom post type. It gives the client an extremely simple interface to add, edit and remove images and it is a simple matter for an experienced developer to create a query in WP to retrieve the URLs of the images and feed them to the JavaScript code that will create the effect.

Naming Custom Post Types and Taxonomies

The last thing I’d like to touch on that has to do with the best way to use custom post types and taxonomies is naming them. Names selected should be in the same naming convention as what WordPress suggests for plugins, themes and function names. They should all have a prefix that identifies them. They should also be named in a way that has little chance of interfering with other plugins and themes. Let’s take the example of creating a custom post type for products. I would not use “product” because I know there are several plugins available that already uses this name for their custom post type. So, if I was creating this for “ABC Tools” I would probably call the custom post type “abc-tools-product” and the product type taxonomy “abc-tools-product-type”. The only drawback to this is that these will be the URL slugs used for all of the products and product types in this section of the site. But at least I know the client or some other developer in the future can’t break my work by adding some plugin in the future.

How to Create Custom Post Types and Taxonomies

I could go into a long discussion of the technical coding to create a custom post type and add custom taxonomies to it, but I’m not going to. Fortunately there is no reason for me to do this coding myself. While I do need to code the new templates to display my data, and there’s little you can do to change this or avoid it. You can add custom post types to your system by using one of the various plugins that are available for doing so. I personally like Custom Post Type UI. It has everything you need for adding custom post types and taxonomies. You can even export the code needed and embed it into your own plugins that use custom post types so that it cannot be edited by anyone but another developer.

Conclusion

Custom post types elevated WordPress from a blog platform to a true CMS with the ability to create a clean, intuitive user interface. The only requirement for the developer is knowing when and how to use them and most of the really hard work can be handled without any coding simply by finding a plugin that is built well that you can understand and use.