One of the most common mistakes made by both beginners and seasoned web developers alike when building a new website, WordPress or otherwise, is the lack of foresight to plan out the site’s information structure and hierarchy. Especially when you are starting out, there’s the romantic notion of sitting on a barstool somewhere, having a bright idea for a site, and then sketching ideas on a napkin for the next million-dollar online business model. Undoubtedly, this happens from time to time, but it’s the exception to the rule. Ultimately, many of us become far too caught up in the graphic design of a site, and then wonder why we end up with a watered-down product that fails to work as we intended.

Most effective websites are planned from an information hierarchy perspective, rather than from a design perspective. For our purposes, we’ll define information hierarchy (or information structure) as the overall planned organization of the content on a given website. An effective information hierarchy takes various factors into account and puts them together to form a cohesive structure. These factors include the actual site content topics and how content should be presented. Will you be using pages and subpages for some types of content, or will it be posts added to categories and subcategories? What types of content should be searchable? Should some content be searchable on its own, without search entries from posts or pages elsewhere on the website? All these variables combine to create the information hierarchy of a given website.

When you begin putting together a site (or working with a client to put together their site), it’s perfectly fine to ask questions about what the site should look like. However, it’s far more important to ask what the site should do. What information is going to be on the site? How should users be able to interact with that information? Should the information be clustered together in one area of the site, or do we need more structure? Understand that there are no right or wrong answers to these questions, but it’s important you ask them and seek genuine responses.

What you should attempt to end up with is a content wireframe for your website. Unlike layout wireframes, which show the overall design layout of a web page’s basic components prior to it being fleshed out by a graphic designer, a content wireframe offers a comprehensive plan for your site’s information hierarchy. We’ll show you some examples of developed content wireframes in just a bit, but for now consider your responses to these basic considerations carefully. Take your time and be specific with your responses, and remember that regardless of how awesome WordPress or any other web development tool you happen to be using is, it’s ultimately up to you to build your website intelligently.

Part of your plan for the information hierarchy for your website is sorting out which content will be filtered into categories and posts, and which will be set up as pages. Organizationally, you’ll also seek to figure out what you can label and cross-reference as tags. In truth, you can do a lot with WordPress pages, posts, categories, and custom post types, but using custom taxonomies is a fairly easy technique that provides more flexibility in how you organize your content. Using custom taxonomies is also more professional, as it provides the type of polish that clients tend to recognize and respect.

Throughout this chapter, we’ll use a common example to highlight how to use custom taxonomies, and why they might be useful. We’ll put together a WordPress site for a real estate company named Rutherford Real Estate, which wants to display properties organized by neighborhoods in several regions. Furthermore, Rutherford Real Estate has many sales agents working for it, all of whom represent multiple properties in any given region or neighborhood. If Rutherford Real Estate sells property in three regions—each of which have several neighborhoods—and agents can sell properties in any region or neighborhood they choose, let’s have a look at what a visual representation of the business might look like, in Figure 7.1.

Figure 7.1. Regions and neighborhoods for Rutherford Real Estate

It’s plain to see we’re dealing with two types of information: hierarchical and nonhierarchical, with neighborhoods being hierarchical subsets of regions, and sales agents acting as free radicals that can attach to whatever they please. In WordPress terms, this means that we should be able to safely use categories for regions and neighborhoods, and tags for the agents. Now let’s reframe our chart into a content wireframe that explains the information hierarchy for this business model in our website, in Figure 7.2.

Figure 7.2. Content wireframe with category tags

That’s more like it. Our taxonomy is starting to take shape. We’ve established that our three regions will be set up as categories, each having several related subcategories to handle the respective neighborhoods. Subsequently, individual posts will be used to handle individual properties, giving us a nice way to categorize our property listings for Rutherford Real Estate. We’ve also established that we’ll be using tags to handle sales agents, as individual agents can sell properties in different regions, and there may be instances when several agents team up to represent one property in particular. Functionally, this should work well, and many developers will choose to simply stop here and proceed with development. However, with a bit of further planning, you’ll be able to further customize WordPress functionality for Rutherford Real Estate. In the absence of this, a common default permalinking taxonomy that may be configured for Rutherford Real Estate might look like this:

/%category%/%postname%/

If we configured the site as described previously, this might render a permalink for a property titled “Farmhouse” in Traverse City to look like this:

http://www.esquandoloas.com/category/midwest/traverse-city/farmhouse

That’s not bad. It certainly includes the category and post slugs that describe what the content is all about (a farmhouse in Traverse City that’s located in the Midwest), but we could do even better from an SEO perspective. Custom taxonomies allow us to create a separate hierarchical structure with a more descriptive permalink that increases the relevance for search engines like Google, producing higher rankings. Consider a situation where we set up a custom taxonomy for our properties that could create a permalink that looked like this:

http://www.esquandoloas.com/properties-for-sale/midwest/traverse-city/farmhouse

This is semantically a much better permalink, as it instantly establishes to both search engines and real users that the content on this link is a property that’s for sale, located in the Midwest (Traverse City, to be exact), and a farmhouse. Furthermore, if we set this up as a custom taxonomy, we create a whole new taxonomy to work with, leaving our original category taxonomy untouched and intact, which can be used for other purposes on the website—say blogging about news and events that support Rutherford Real Estate’s sales efforts. By adding a custom taxonomy to handle properties, the new content wireframe might look like Figure 7.3.

Figure 7.3. Our full content wireframe

Now we’re cooking with gas. We have our custom taxonomy set up to work in a hierarchical manner, and we’ve also created a place to use our normal categories and tags for marketing purposes. In addition, we fully expect to set up our permalink taxonomies to reflect two different structures.

For our properties, we’ll have permalinks that look like: http://www.esquandoloas.com/properties-for-sale/midwest/traverse-city/farmhouse, while for our news and events, we’ll have taxonomies that look like: http://www.esquandoloas.com/category/events/marcos-crazy-estate-blowout-sale. Aren’t we fancy?

There are two other really cool aspects of custom taxonomies: extensible functionality requirements and custom searching. Custom searching is fairly straightforward. Using custom taxonomies allows us to delineate content so we can create custom searching restrictions. Therefore, if we want to search the website and only return properties, we can restrict the parameters of the search to only pull from that taxonomy type (more on that in a bit). And when we consider custom taxonomies as a tool we can plug in at any time, we realize that we can extend WordPress in almost any direction we want, even if the site we’re looking to extend is already in place and filled to the brim with existing content. We need do nothing more than establish the new type of content that we want to log within the site, create our taxonomies, and begin to use them.

Creating new taxonomies in WordPress is a relatively simple process, and WordPress provides us with a function that accomplishes the job: register_taxonomy(). You should always use the init action hook when calling register_taxonomy(), or else you will incur fatal errors, and nobody likes anything that includes the word “fatal”, do they?

register_taxonomy() takes one required parameter and two optional but extremely useful parameters:

register_taxonomy( $taxonomy, $object_type, $args );

The $taxonomy parameter is required; it is simply the name of the taxonomy being used, and must exclude capital letters and spaces. It’s extremely important to ensure that the name of the taxonomy is unique so that it avoids conflicts with plugins. Drawing from our Rutherford Real Estate example, when naming the taxonomy for sales agents, we’d be better served using “Rutherford-sales-agents” instead of “agents.”

The $object_type parameter must be defined as either a predefined object that is built into core WordPress, or the slug name of a given custom post type that has already been created in the installation. The parameter is technically optional, but leaving it out (or explicitly setting it to null) will register the taxonomy without associating it with any objects. Therefore, the taxonomy will be unavailable for administration within the WordPress back end, and you’ll have to manually register it using the taxonomy parameter (passed through $args) when registering a custom post type with register_post_type() or register_taxonomy_for_object_type().

WordPress built-in post types that can be passed in as a valid value for the $object_type parameter are as follows:

The most commonly used of these built-in post types with custom taxonomies are post or page.

The $args parameter is an associative array of arguments that define and describe the taxonomy. While it is technically an optional parameter, the functions and switches that are managed within this array are essential for shaping taxonomies and making them do what you want. In fact, it’s such an important aspect of understanding and managing taxonomies that we should delve deeper into this array.

The $args array (or arguments array, as we’ll refer to it here) takes up to 12 different arguments, one of which is not recommended for use by core developers (the _builtin argument—see the Codex, which states it’s just for documentation purposes). Each argument is optional, and individually handles important functionality switches for taxonomy registration, which can be useful for a variety of reasons. Let’s look at them in detail.

This sums up the arguments array, but as we noted earlier, we need to discuss the labels argument further.

The array used for the labels argument is important for providing the text used throughout the WordPress administrative back end for all your taxonomy terms. These labels can and should be set up to be localized for eventual translation (see Chapter 11 for an explanation of localization). Let’s have a look at what’s available to be configured:

That’s all there is to register_taxonomy(), which frankly is an awful lot. Yet register_taxonomy() is really just a function that defines a lot about how we want our taxonomy to work. This is best understood by looking at a real-life example, so let’s revisit Rutherford Real Estate.

We’ve already set up the content wireframes for Rutherford Real Estate that define their information hierarchies. As you may recall, we want to create a new taxonomy to handle locations (regions and neighborhoods), as well as a separate taxonomy to handle sales agents who represent the properties in different regions. The locations taxonomy needs to be hierarchical, as specific neighborhoods (Chicago, East Lansing, and Traverse City) are subsets of the regions they are situated in (Midwest). Conversely, a sales agent named Palmer may represent a property in several neighborhoods, and in more than one region, so there is no hierarchical relationship with sales agents. The taxonomy that handles sales agents should therefore be loose in structure and act similarly to tags. Let’s see what our code should look like to register our new taxonomies:

<?php
//hook into the init action and call create_property_taxonomies
add_action( 'init', 'create_property_taxonomies', 0 );

//create two taxonomies, locations and sales agents
function create_property_taxonomies() 
{
  // Add new taxonomy locations, make it hierarchical (like categories)
  $labels = array(
    'name' => _x( 'Locations', 'taxonomy general name' ),
    'singular_name' => _x( 'Location', 'taxonomy singular name' ),
    'search_items' =>  __( 'Search Locations' ),
    'all_items' => __( 'All Locations' ),
    'parent_item' => __( 'Parent Location' ),
    'parent_item_colon' => __( 'Parent Location:' ),
    'edit_item' => __( 'Edit Location' ), 
    'update_item' => __( 'Update Location' ),
    'add_new_item' => __( 'Add New Location' ),
    'new_item_name' => __( 'New Location Name' ),
    'menu_name' => __( 'Locations' ),
  );

  register_taxonomy('location', post, array(
    'hierarchical' => true,
    'labels' => $labels,
    'show_ui' => true,
    'query_var' => true,
    'rewrite' => array( 'slug' => 'location' ),
  ));

  // Add new taxonomy for sales agents, NOT hierarchical (like tags)
  $labels = array(
    'name' => _x( 'Sales Agents', 'taxonomy general name' ),
    'singular_name' => _x( 'Sales Agent', 'taxonomy singular name' ),
    'search_items' =>  __( 'Search Sales Agents' ),
    'popular_items' => __( 'Prolific Agents' ),
    'all_items' => __( 'All Sales Agents' ),
    'parent_item' => null,
    'parent_item_colon' => null,
    'edit_item' => __( 'Edit Sales Agent' ), 
    'update_item' => __( 'Update Sales Agent' ),
    'add_new_item' => __( 'Add New Sales Agent' ),
    'new_item_name' => __( 'New Sales Agent' ),
    'separate_items_with_commas' => __( 'Separate agents with commas' ),
    'add_or_remove_items' => __( 'Add or remove agents' ),
    'choose_from_most_used' => __( 'Choose from the most prolific sales agents' ),
    'menu_name' => __( 'Sales Agents' ),
  ); 

  register_taxonomy('agent','post',array(
    'hierarchical' => false,
    'labels' => $labels,
    'show_ui' => true,
    'update_count_callback' => '_update_post_term_count',
    'query_var' => true,
    'rewrite' => array( 'slug' => 'agent' ),
  ));
}
?>

This pulls together all that we’ve just covered on the register_taxonomy() function quite nicely—so let’s pick it apart. First of all, we’re creating a function called create_property_taxonomies(), which we’re adding with the init action hook. Our new function begins by defining a $labels variable that consists of the nested labels array we discussed, and establishes all the text for the location taxonomy we’ll define in our first register_taxonomy() function call. Notice that in keeping with standard coding practices throughout this book, we have set up the values in our labels array to be localized if required. Additionally, in the register_taxonomy() function we’ve defined the hierarchical parameter to be true, ensuring that locations will work similarly to categories.

Immediately after our first register_taxonomy() function call, we have reset the information in the $labels variable by adding a new array similar to the first, this time inserting the internationalized text variables that focus on the sales agents. We use the previous technique in pulling this array into the register_taxonomy() function that defines sales agents; however, notice that this time our hierarchical parameter is set to false, allowing the agents to operate as tags. We’ve also added the option update_count_callback with a string value of _update_post_term_count to our register_taxonomy() function. This ensures that the taxonomy behaves like a tag, and in instances where you add multiple items to the taxonomy separated by commas, the items are saved as separated values as intended, rather than one long, single item that makes no sense.

Notice that in the screenshots and the previous code example, we’re associating our new taxonomies with generic posts. In many instances (especially a real estate property), you may be looking to associate the taxonomy with a custom post type instead of a generic content type. In this case, you’d actually want to call the name of the custom post type or an array of instances of that post type in a hierarchical situation, as seen in this code chunk:

<?php

// Associating the $object_type with an array of instances of custom post type
  register_taxonomy('location',array('property'), array(
    'hierarchical' => true,
    'labels' => $labels,
    'show_ui' => true,
    'query_var' => true,
    'rewrite' => array( 'slug' => 'location' ),
  ));

// Associating the $object_type with a single instance of a custom post type
  register_taxonomy('agent','property',array(
    'hierarchical' => false,
    'labels' => $labels,
    'show_ui' => true,
    'update_count_callback' => '_update_post_term_count',
    'query_var' => true,
    'rewrite' => array( 'slug' => 'agent' ),
  ));

Regardless of how you set up your taxonomy, you’ll see it in your WordPress administrative back end once it’s registered, and thus have the ability to begin managing content therein. For Rutherford Real Estate, we have chosen to just associate our taxonomies with regular old posts. As a result, you can find our two new taxonomy types on the Posts submenu panel, as shown in Figure 7.4.

Figure 7.4.  Locations taxonomy

Notice that the locations taxonomy management page looks identical to the categories management page; were we to have a look at the sales agents taxonomy page, we’d see an interface that likewise mimics that tag management page. Furthermore, since we’ve associated our new taxonomies with posts, when we go to add a new post or edit an existing post, we’ll now see the appropriate meta boxes in the right-hand column, as seen in Figure 7.5.

Figure 7.5.  Locations and Sales Agents meta boxes

We can use these meta boxes to mark our property’s neighborhood—as well as the sales agents representing it—in the same way we utilize categories and tags. Overall, it’s intuitive, easy-to-use stuff!

We’ve already discussed the notion of WordPress template hierarchies and nomenclature at length in Chapter 6, but WordPress does give us a template hierarchy nomenclature dedicated to custom taxonomies. This is seen in Figure 7.6.

Figure 7.6. Custom taxonomy template hierarchy structure

Using this template hierarchy system automatically tells WordPress which visual blueprint should be used for any given taxonomy. This automatically simplifies the process of deciding which functional display logic we’ll use for each of our taxonomy types by removing the conditional logic for us. At this point, the taxonomy nomenclature should be fairly straightforward, but let’s review it briefly, just to be sure.

The most specific taxonomy template file is the top one, which in our example might look like taxonomy-location-firenze.php. If this file was created and populated, it would be the default file that WordPress would utilize when displaying information for the “Firenze” neighborhood. However, if we were comfortable with all the neighborhoods and regions having display logic that worked in exactly the same way, we could add that display logic to the taxonomy-location.php file. Similarly, if we wanted our display logic for neighborhoods and agents to act the same way, we’d be fine using a file named taxonomy.php. From there, the nomenclature defaults into the general system, with archive.php and then index.php being the final defaults in that order. It’s easy to see how this can allow you to customize the appearance of WordPress in conjunction with taxonomies (especially if you choose to work with custom post types as well), but exactly what type of functions are available in the context of these template files? We’re glad you asked …

Yes, we’re back to the meat of WordPress again; after all, who doesn’t love The Loop? We know that The Loop is the beating heart of WordPress, and in order to customize the display output and functionality it’s often necessary to roll your sleeves up and plunge into the template files that manage logic in The Loop. With respect to custom taxonomies, there are several functions you can utilize to change the way The Loop pulls in post information.

The most useful and common way to customize the display of your taxonomy output outside of The Loop is through the use of the wp_tag_cloud() function. This core function creates a Tag Cloud, and one of the parameters it will take is a taxonomy parameter. Therefore, if we decided that we wanted to create a Tag Cloud which listed all our agents and then insert that tag cloud into our sidebar, we could place the function call <? wp_tag_cloud( array( ‘taxonomy’ => ‘agents’ ) ); ?> into the appropriate location, either in a widget or within the code for our sidebar display.

As you can see, custom taxonomies are useful features that are hidden in the depths of core WordPress, and using them to your advantage can really provide the polish that makes your work superior to your competitors. It’s not that hard to use custom taxonomies; it’s more a case of understanding how to register them and then utilize the template hierarchy and a few loop functions to make all the pieces come together nicely.