Note: This article is an extension of Custom Post Types, Custom Taxonomies, and Permalinks in WordPress 3.0 which discusses the Custom Post Type and Custom Taxonomy implementation we’ve setup thus far. While a summary is offered here, please know that some details discussed herein reflect the implementation discussed previously.

In order to set up front end visible archive pages for Custom Taxonomies, everything begins with the rewrite slug attached to your Custom Taxonomy. This can be edited using the Custom Rewrite Slug field provided by Custom Post Type UI. Some planning is required on your part, but the plan must take into consideration the Page structure currently implemented.

So far, we’ve based our Cameras Custom Post Type on the slug of /cameras/. This works out well as our Custom Post Type houses information based on DSLR Cameras. We’ve set up an index-style page that sits at /cameras/, and our single pages are stored under /cameras/%postname%/. We’ve just now included a Custom Taxonomy, and we’d like to include that in the mix as well.

Out of the box taxonomy permalinks

By default, a Custom Taxonomy rewrite slug is based on the Taxonomy Name. Considering our Brands Custom Taxonomy, we might expect the Taxonomy listing would be made available at /cameras/brands/%taxonomyname%/; unfortunately that’s not the case. Given the Taxonomy being a default implementation, we’d actually find the listing at /brands/%taxonomyname%/. You’ll also note that any Cameras we’ve marked under a particular brand will show up in the listing. For example, if we navigated to http://wordpress/cpt/brands/canon/, we’d be faced with a page resembling:

This listing behaves just like a regular Posts archive page would, and that’s because it’s literally based on the archive.php template file of your theme. While it works, it’s not ideal. Thinking ahead, if you have multiple Custom Post Types along with WordPress posts, there isn’t much segmentation when it comes to actually viewing archive pages on the front end.

Take into consideration the possibility of us expanding our content by also including a Custom Post Type for Flashes. If we were to use a Custom Taxonomy for Flash Brands (as opposed to Camera Brands) with that Custom Post Type as well, we’d have overlapping entries and it would quickly become unorganized as results for both flashes and cameras would turn up when viewing http://wordpress/cpt/brands/canon/ which isn’t always desirable.

At this point it’s important to note the specificity of a Custom Post Type/Custom Taxonomy implementation. There is a strong possibility that you very well may want to merge Canon flashes and cameras in your archive pages, but you may not. For the purpose of example, we’re going to deem it necessary to segment the two. To accomplish that, you’ll need to beef up the rewrite slug for your Custom Taxonomies.

Customizing your Custom Taxonomy template

When dealing with taxonomies, WordPress looks for specific theme files. As with other theme files, templates for Custom Taxonomies can be based on the taxonomy name, in this case brands. Create a file called taxonomy-brands.php in your theme directory, WordPress checks for this file before hitting archive.php which can allow you to make the front end more custom. As an example, we’ll use the following for our taxonomy-brands.php:

<?php get_header(); ?>

  <?php $term = get_term_by( 'slug', get_query_var( 'term' ), get_query_var( 'taxonomy' ) ); ?>
  <div id="container">
    <div id="content" role="main">

      <h1 class="page-title"><?php echo $term->name; ?> Archives</h1>

      <?php if (have_posts()) : ?>
        <?php while (have_posts()) : the_post(); ?>

          <div class="post type-post hentry">
            <h2 class="entry-title">
              <a href="<?php echo get_permalink(); ?>" title="<?php the_title(); ?>" rel="bookmark">
                <?php the_title(); ?>
              </a>
            </h2>

            <div class="entry-meta">
              <span class="meta-prep meta-prep-author">Posted on</span>
              <a href="<?php echo get_permalink(); ?>" title="<?php the_time( 'g:i a' ); ?>" rel="bookmark">
              <span class="entry-date"><?php the_time( 'F j, Y' ); ?></span></a>
            </div><!-- .entry-meta -->

            <div class="entry-summary">
              <?php the_excerpt(); ?>
            </div><!-- .entry-summary -->
          </div>

        <?php endwhile; ?>
      <?php endif; ?>

    </div><!-- #content -->
  </div><!-- #container -->

  <?php get_sidebar(); ?>
<?php get_footer(); ?>

This file is based on category.php with a few modifications. First is the call to get_term_by() which uses get_query_var() to determine what Custom Taxonomy term we’re working with. From there, we carry on through The Loop as normal, outputting the information we’d like to use and where.

The only lasting problem here, is the fact that we’re still sitting at http://wordpress/cpt/brands/canon/. I’d much rather have this page available at http://wordpress/cpt/cameras/brands/canon/ as to differentiate it from other Custom Post Types and their Custom Taxonomies.

Correctly identifying your rewrite slug

Custom Post Type UI makes it really easy to modify our Custom Rewrite Slug, which controls this change entirely. As mentioned earlier, a rewrite slug, unless otherwise defined, is based on the Custom Taxonomy name itself, hence our current /brands/%taxonomyname%/ result. We simply need to change our Custom Rewrite Slug to include the URL structure we’re looking for, in this case cameras/brands:

Saving the change to our Custom Taxonomy rewrite slug will push the permalink change and we’ll finally be able to hit our more appropriate http://wordpress/cpt/cameras/brands/canon/ URL, right? Not quite. It turns out that if we hit http://wordpress/cpt/cameras/brands/canon/ WordPress thinks we’re trying to hit a single post from our Cameras Custom Post Type and redirects us to the closest match.

In order to get our final archives-style pages to load properly, we’re going to have to modify our Custom Post Type Custom Rewrite Slug to differentiate a request for a single post entry versus our archive-style pages. To do that, we’ll need to change the slug from cameras to something more appropriate like cameras/body which could signify that we’re viewing a camera body.

With that change in place, we’re in business! We’re now able to hit http://wordpress/cpt/cameras/brands/canon/ and view the Posts that have been marked as Canon Posts, using our custom permalink as well as our custom template file. You can repeat this process with additional taxonomies by creating appropriate rewrite slugs in conjunction with new taxonomy-%taxonomyname%.php template files.

Adding links to Taxonomy archives in the sidebar

Many of the WordPress-native functions can be adapted for use with Custom Post Types and Custom Taxonomies. To add links to your newly created Custom Taxonomy archive pages, you could add something like this snippet to your sidebar.php:

<li id="camera-brands" class="widget-container">
  <h3 class="widget-title">Camera Brands</h3>
  <?php $cam_brands = get_terms('brands', 'hide_empty=1'); ?>
  <ul>
    <?php foreach( $cam_brands as $brand ) : ?>
      <li>
        <a href="<?php echo get_term_link( $brand->slug, 'brands' ); ?>">
          <?php echo $brand->name; ?>
        </a>
        <ul>
          <?php
            $wpq = array( 'post_type' => 'cameras', 'taxonomy' => 'brands', 'term' => $brand->slug );
            $brand_posts = new WP_Query ($wpq);
          ?>
          <?php foreach( $brand_posts->posts as $post ) : ?>
            <li>
              <a href="<?php echo get_permalink( $post->ID ); ?>">
                <?php echo $post->post_title; ?>
              </a>
            </li>
          <?php endforeach ?>
        </ul>
      </li>
    <?php endforeach ?>
  </ul>
</li>

While a bit of the markup is specific to Twenty Ten’s sidebar.php we can dissect what’s going on here:

1. Pull our brands
2. Create a list item for our brand
3. Pull all posts that have been marked as being that brand (via the taxonomy and term arguments)
4. Loop through each post within that defined Custom Taxonomy entry and dump out what we’d like to use
5. Repeat until finished with all Custom Taxonomy entries

When incorporated into the sidebar, we’ll get something like this:

As you can imagine, that sidebar listing would quickly grow to an unmanageable size, but the example illustrates just what’s possible using a few WordPress native functions and your Custom Post Types/Custom Taxonomies.

Custom Post Types and Custom Taxonomies are powerful

These changes in WordPress 3.0 are more than welcome, as they’re going to set the stage for much more traditional CMS-like behavior. The implementation discussed in this short series of articles is quite specific but hopefully outlines one of the many ways to work with Custom Post Types and Custom Taxonomies, all the while keeping a prettier permalink structure throughout your sites.

Advertise here with BSA

Custom Post Types are a huge boon to everything WordPress. The feature has been long awaited, and lays a nice foundation for WordPress becoming more of a CMS to those still convinced it’s merely a blogging engine.

Custom Post Types, for those not familiar, is basically a templated content type based at their core off of WordPress’ Posts. There are a number of optional fields you can include within a Custom Post Type, and you can also build in your own. It opens the door to building a refined UI for data storage within WordPress given custom circumstances.

That said, you may be curious how that effects other systems such as Pods. If you haven’t had a chance, I discussed WordPress 3.0 and Pods in detail and have concluded that Custom Post Types and Pods achieve different goals at this point, and working with Pods gives you a level of control Custom Post Types currently do not (and in part do not strive to) achieve.

As full disclosure, I’ve recently been accepted as a Pods Core Developer but hope to express that circumstance having no effect or any biased opinions toward Custom Post Types. The Pods team wouldn’t exist without WordPress, and we’re all super thrilled about the existence of Custom Post Types.

In this walkthrough, I’d like to cover a fully top-to-bottom implementation of Custom Post Types, specifically targeting the task of ensuring a pretty permalink structure for your single pages. A follow-up article will take into consideration custom taxonomies for archive-style pages.

Up and running with Custom Post Types

Perhaps the biggest outstanding learning curve with Custom Post Types is the implementation itself. While programmers will love it, less experienced theme developers are likely to become quickly frustrated with the initial setup of Custom Post Types. While there is a lot of information in the always useful Codex, Custom Post Types still require an understanding of WordPress established conventions for implementation.

I’m a stickler for understanding the ins and outs of a system in which you work professionally, but I also understand that WordPress is a fantastic platform for tinkering. That said, if you’re a professional you’re looking to save as much time as possible. If you’re a tinkerer you’re looking to get up and running as quickly as possible so (hopefully) you can dissect how it happened. Given that, a really nice way to rapidly set up your Custom Post Types is the Custom Post Type UI WordPress plugin. Custom Post Type UI completely removes the tediousness of setting up Custom Post Types by providing an interface within the WordPress admin to do so. I’ve been using it on all of my recent projects and it’s a huge time saver. I do recommend though, that prior to using the plugin, you take the time to really understand what Custom Post Types are and how they fit into the big picture.

For the purposes of this walkthrough, we’ll set up an informational DSLR site with some information about a few cameras. Using Custom Post Type UI, we’ll set up a Cameras Custom Post Type:

While you can create a Custom Post Type filling out just the fields above, we’re working for a full implementation here, so we’re going to fill in the Advanced Label Options too:

If these fields are not populated, defaults will be used based on the initial labels used to set up the Custom Post Type. In this particular case, using those defaults would have worked out just fine, but there will be circumstances where a revised nomenclature will be much more meaningful to clients. We’re also going to customize the Advanced Options offered by Custom Post Types/Custom Post Types UI:

Using these fields we’re able to further refine the attributes of our Custom Post Type. Many of these can be left as default, but we’ll pay particular attention to both the Custom Rewrite Slug as well as the Supports areas. Built-in Taxonomies are also important, but we’re going to revisit that later. The Custom Rewrite Slug is responsible for ensuring your permalink structure remains accurate and in tact. More on that during implementation. Now that our options are set, clicking Create Custom Post Type will add our Custom Post type to the admin UI:

Adding a new entry will provide a familiar, but customized content entry view:

Once we’ve added some entries, we’ll begin building our library of content:

With Custom Post Types comes all of the built in content management functionality of WordPress, but at this point, we’ve got nothing to show for it within our theme; these pages are nowhere in sight on the front end. Our first option could be to use WordPress 3.0 Menus and manually build out a navigation system with a series of Custom Links, but that would quickly become overbearing given the fact that we’re hoping to build a website with hundreds (or thousands) of content pages.

Structuring WordPress for Custom Post Types

Custom Post Types are just that, they’re a collection of content. For the sake of organization as well as user experience, there should be some sort of hierarchy that incorporates your Custom Post Types. Currently, if you were to hit one of our Camera pages using the Permalink outlined on the edit page, you’d see the content included in the post:

For the purpose of this example, the permalink we’re working with is http://wordpress/cpt/cameras/canon-7d/ which is just fine; I like the way it’s structured. The trouble creeps in when, by experience, we want to view an index page by stripping off the last URL segment and trying to hit http://wordpress/cpt/cameras/. Out of the box we’re slammed with a 404 error. As a fix, I’d suggest creating a WordPress Page called Cameras (with the proper slug) to ensure we no longer hit that 404.

This ties into my philosophy of structuring WordPress sites; WordPress Pages should dictate the overall structure (for both content and URLs) and be the foundation of everything built on top of it. To our benefit, Custom Post Types work within thsi philosophy.

With our http://wordpress/cpt/cameras/ URL now properly resolving, we could create a custom Page template to pull in all of our Cameras. There are two approaches here, you can either set the Page Template in the Page Attributes sidebar on the edit screen, or simply name your template file using the Page slug. We’ll take the latter approach and create a new file within our theme directory called page-cameras.php consisting of:

<?php

/* Template Name: Cameras index */

get_header(); ?>

  <div id="container">
    <div id="content" role="main">

      <?php
        query_posts( 'post_type=cameras' );
        get_template_part( 'loop' ); // looks for loop.php which is specific to Twenty Ten
        wp_reset_query();
      ?>

    </div><!-- #content -->
  </div><!-- #container -->

  <?php get_sidebar(); ?>

<?php get_footer(); ?>

Note: The call get_template_part() looks for loop.php, a template file specific to Twenty Ten, the stock theme that ships with WordPress 3.0

What we’re doing in this template is simply querying all posts for our cameras Custom Post Type and sending that data to The Loop. Last, we reset to the original query fired during page creation which will prevent any funkyness with sidebar and/or footer logic. What results is a page that mimics a default Posts entry view in Twenty Ten:

While the implementation so far is great for including the data stored in our Custom Post Type, it’s not very organized.

Organizing Custom Post Type data using a Custom Taxonomy

Closely related to Custom Post Types are Custom Taxonomies. To our benefit, the Custom Post Type UI plugin handles the creation and maintenance of Custom Taxonomies as well. We’re going to organize our Cameras Custom Post Type by attaching a few Taxonomies:

When creating them, we’ve attached the Taxonomies to our Custom Post Type, and they now show up as expected:

Out of the box, Custom Taxonomies behave like tags. Depending on how you’d like to use your Taxonomy, tags might be an applicable solution. In this case, however, I’d like to offer a choice-based system for my client. To do that, and therefore make your Taxonomy behave more like a WordPress Category, you’ll need to edit the Advanced Options of the Taxonomy:

By setting your Taxonomy to being hierarchical you’ll provide a listing of all existing entries as well as a check/uncheck interaction:

As with most things Custom Post Type, while you’re able to add/edit/remove the data, it doesn’t do much out of the box on the front end. Viewing the Canon 7D page we just edited on the front end results in no visible change. We’re going to use our Custom Taxonomy to provide category-style archive listings.

The end of the basics

This walkthrough sets the stage for the more difficult task of setting up Custom Taxonomy-based archive-style pages using appropriate permalinks. If you’d like to take the next step in pushing your Custom Taxonomies to the front end of your site check out WordPress Archive Pages Based on Custom Taxonomies.

Advertise here with BSA

In part 1 I examined the current WordPress cart plugin landscape and outlined a number of reasons I feel that PHPurchase is currently the leading solution for an e-commerce solution, especially with the arrival of Custom Post Types. I’d like to share how and why using Custom Post Types works so well for a WordPress shopping cart.

Setting up and prepping WordPress

The first step will be to get your WordPress 3.0+ install up and running. That’s the extent of detail we’ll cover there. The next step will be to obtain and install a copy of PHPurchase. There are a number of purchase options available, but this walkthrough will cover functionality available under all licenses of PHPurchase.

The installation of PHPurchase is as straightforward as any other plugin. Once you’ve uploaded the plugin files and activated the plugin, you’ll need to enter your PHPurchase order number on the Settings screen:

After validating your order number, the reminder to do so will disappear and you’ll be able to enter in your PayPal, Authorize.net, or Quantum Gateway payment settings. These details aren’t required at this point, but until that information is entered, the plugin won’t let you check out. For now, those are the only details we’ll cover as far as setup is concerned. Using the PHPurchase menu in the WordPress admin, you can begin adding products.

As it stands PHPurchase will automatically implement a number of system Pages it will use to handle the cart view and checkout process for purchases.

While these pages are an extremely important part of the overall e-commerce implementation, none of the products we just added are made available out of the box.

By editing the Store page, you can quickly add a number of products using the PHPurchase icon in the editor toolbar:

At this point, you can feel to proceed as normal. Using this Store page you could add every product you have available as well as apply some style and content using imagery, product copy, and links to relevant information. You could take it a step further and also create child pages with the Store as the parent and dedicate a product detail page to each of your products.

While helpful, you’ll quickly discover missing features that are very commonly found in other e-commerce platforms. Features such as browsing products by category and providing additional information about products in the form of multiple product shots and/or PDF downloads aren’t directly built into PHPurchase. The beauty lies in the fact that you can customize WordPress in all the usual ways to add these features as you see fit.

With the arrival of WordPress 3.0, however, there is an entire layer of additional functionality found in Custom Post Types that makes working with these features a breeze.

Using Custom Post Types for your PHPurchase Store

Custom Post Types are sometimes intimidating to more novice developers. Out of the box in WordPress 3.0 you need to manually register and set up your Custom Post Types. As with many developer-heavy tasks at hand, there is a plugin to make life easier when it comes to Custom Post Types; Custom Post Type UI.

Custom Post Type UI gives WordPress admins the ability to create, edit, and manage all of the Custom Post Types available within the WordPress Install:

Using the plugin you can easily create a Custom Post Type to handle all of your product pages in PHPurchase. You’re able to customize the phrasing used throughout and viewing the Advanced Label Options gives you even more to work with. On top of these Custom Post Type Settings, you can also set up custom taxonomies which can be used in this specific case for a set of categories limited to your store products and separate from your Post categories.

Once you’ve created your Custom Post Type, a new menu item will be made available in the main navigation:

Using the links available you can go ahead and set up your categories as well as add your products.

Once your products have been added to your Custom Post Type, you can view the page on the front end:

Integrating Custom Post Types into your Menu

Now that your products have been added, you’ll want to make browsing your products as easy as possible. There are a number of things you can do, the primary two being including links to your product pages within your site navigation and using your Custom Post Type taxonomy (product categories).

Menus were also a big addition to WordPress in 3.0 and the update comes in handy at this point in our PHPurchase setup. The Menus are smart enough to recognize your Product Pages and allow you to integrate them directly within your site navigation:

Using the Menus you’re able to mix and match your Product Pages, your Product Categories, as well as your WordPress Pages themselves. You can custom build any structure you wish using the menus and the available entries. By default, linking to a Product Category will direct readers to pages resembling those of your other category pages, likely using category.php from your theme. You can customize this to any degree as you would normally when developing your custom WordPress theme.

Integration with plugins

Another significant advantage to using Custom Post Types and PHPurchase to power your WordPress based e-commerce website is the direct integration with many of your favorite plugins. One of the downfalls to a number of other WordPress store plugins is a lack of attention to search engine optimization. When working with product pages powered by Custom Post Types you can continue to use the SEO plugin working to optimize the rest of your website.

Additionally, you’ll be able to use plugins that enhance your ability to make additional product assets available to readers. Plugins like Attachments will let you add multiple product images for use in a product image viewer, PDFs including additional product details, as well as any available product details that may exist.

This is just the beginning

These are just the basics of getting up and running with WordPress 3.0+, Custom Post Types, and PHPurchase in an effort to get the best possible e-commerce shop up and running quickly and easily. While it’s a bit more work to get a large volume of products added and available on your website, I really feel that PHPurchase is a great choice when considering available e-commerce solutions for WordPress.

Advertise here with BSA

What are Custom Post Types?

First and foremost we need to understand what Custom Post Types are. I’ll try to do my best to sum them up as quickly and as easily as possible in my own words.

Custom Post Types defines our new ability to better organize more advanced content structures within our WordPress sites. That is to say, using Custom Post Types will allow us to create groups of content in addition to the stock Posts and Pages. Subsequently, we’re also able to define the data fields used in each group. Further, we’re able to take advantage of many standard features built into WordPress such as creating custom taxonomies (used for categorization among other things) and more.

If I had to label one final stake in the ground that WordPress is fantastically stating that it is no longer a “blogging” platform and instead a content platform, it would be Custom Post Types.

Custom Post Types have got a ton of attention lately, and as such deserves it. I can’t emphasize how much of a game changer this is on a platform level not only for WordPress developers, but for users as well. We’re going to see a lot of changes on the theme level which in turn will spread the word about WordPress’ adaptiveness.

Where does Pods fit in?

Custom Post Types sound great, but what about Pods? If you want the short version: I love Pods and I don’t see it going anywhere anytime soon as a result of Custom Post Types.

Now for the extended version.

Pods and Custom Post Types, although they have some overlapping functionality, don’t directly compete with one another top to bottom. Custom Post Types open a lot of doors, and I plan on using those doors as often as possible. Pods, however, is functionally superior to Custom Post Types in ways that I’ve been taking advantage of on nearly every project in recent memory.

The superiority lies in the fact that instead of being a new group of Custom Posts or Pages, Pods focuses on the relationship factor by keeping the doors wide open when it comes to how the data is displayed, how users interact with it, and how you use it. Additionally, the Pods developers are super focused on performance. That’s not to say that I’ve noticed a performance problem with WordPress, but it’s great to read that they’re focused on speed and integrity to the level of creating one-off database tables every time Pods needs one for your content types.

Pods takes a different approach entirely when it comes to the database level. WordPress Custom Post Types simply append your new content groups to the Posts table and under the hood are using Custom Fields to take care of your custom data. This is nowhere near magic to anyone who has written a plugin before that accomplishes the same thing. Attachments, for example, uses that philosophy to function.

Don’t take me wrong, I don’t think that’s wrong to do, not by any means. I always try to KISS and I think Custom Post Types do the same thing. I also appreciate, though, that Pods focuses on performance at its root.

Pods also offers more when it comes to functionality offered. Custom Post Types leave things pretty open-ended for you to get done what you’d like, but I’m not sure how easy it will be to relate one Post to another, or multiple for that matter in that group. What about relating that Post to a Post from a completely different group? What if you want to limit that list of available Posts to include a certain number of Posts from one group, and more from another? Pods has you covered out of the box.

I’ve also become addicted to the way Pods UI lets you present the Pods you’ve created. You’re able to organize and group your content types in such a way that it makes perfect sense when your client needs to hop in the driver’s seat. Pods UI is founded on built-in WordPress functions and I’m not sure to what extent it can be replicated with Custom Post Types at this stage, but I’m smitten with Pods UI and hopefully that functionality can eventually find its way to Custom Post Types.

I’ve become very comfortable with the advanced features offered by Pods, especially when Pods UI comes into play, and I won’t backtrack at this point just to take advantage of built-in functionality (my personal preference by default). I think Pods still stands on its own two feet by a long shot.

Will they blend?

That said, I plan on using a combination of Custom Post Types and Pods until a new catalyst enters which will cause me to reevaluate the situation at that point. I have a set of rules that help me build sites on top of WordPress and incorporate Pods all to make things as easy as possible for my clients to use and I will continue with that school of thought now that Custom Post Types are here.

I’ve got a lot to learn about Custom Post Types and what’s technically functional, possible, and stable. You can be sure I’ll be posting my findings along the way. I feel that Pods and Custom Post Types make a good team and will continue to do so beyond the launch of WordPress 3.0.

Advertise here with BSA