Displaying Custom Post Types in a Custom Taxonomy Archive

The project I was working on today required a custom post type that included a custom taxonomy. Setting this up on the back end was simple. However, when I went to the front end, all the posts in the custom post type were missing from the custom taxonomy archive. Since it took me way too long to figure out the source of this issue, I’m going to document it here.

It all comes down to this poorly named setting:


When registering a post type, this setting determines whether or not your custom post type will show up in your site’s search results. However, it also has the unexpected side effect of determining whether or not your custom post type will show up on taxonomy archive pages. If you want to include your custom post type in custom taxonomy archives, exclude_from_search must be set to false:

'exclude_from_search' => false,

Note: If the “public” setting is set to “true” then the “exclude_from_search” setting can simply be removed.

Special thanks to Pieter Goosen for mentioning this issue in this Stack Exchange thread.

This issue is also mentioned in the “exclude_from_search” section of the old WordPress Codex page for registering custom post types.

  • PublishedAugust 12, 2016
  • Posted InWordpress

Migrating WordPress Multisite to a Local Development Environment

This post is primarily a reminder to my future self. However, I don’t think I’m alone in this struggle. Migrating WordPress multisite can be quite a challenge, especially if you’re migrating from a live site to a local development environment. If you’re using http://localhost as your local development environment root with individual sites placed in subfolders like I was doing, your URL structure is most likely quite a bit different than the live site you’re trying to migrate.

Some day I may write a full tutorial on how to accomplish this, but for now I just want to highlight the missing piece that I didn’t find in any other tutorials (and that I spent a few days trying to find).


Updating a Plugin in the WordPress.org Repository

As of this writing, I have only two plugins in the WordPress.org repository. I periodically update these plugins, but not often enough to memorize all the steps required to get things right on the first try. So for my own future reference (and maybe yours as well) here are all the steps laid out in order.


Passing Arguments to Callback Functions

Let’s say you want to use add_action() to attach a function to an existing action, but you want to pass your function a few arguments. This seems to be a common problem with no good solution. Yes, you could use global variables, but that’s rather messy, especially if you want to attach the same function to a number of different actions but with different arguments each time. After running into this issue again a few weeks ago, I set out to see if there wasn’t a better way to do this. Here’s what I came up with…


Thoughts on WordPress Data Portability

Data portability within WordPress is a big deal. However, best practices regarding how to properly make data portable are hazy at best. Where should custom post types be defined? What should happen to the data when a user switches themes?

In this post I will attempt to summarize the various arguments, point out one overlooked fact, and offer a limited solution that can be implemented regardless of your particular views on data portability.

Attempted Summary: Themes vs Plugins

For the sake of simplicity, I will be discussing data portability as it applies to custom post types. It seems that the true question that everyone is trying to answer is this:

What is the most user friendly way to implement theme-related custom post types, and what should happen to the data when a user switches themes?

For example, let’s say you’re creating a portfolio theme using a custom post type to hold the portfolio items. At first glance, it appears that defining the custom post type within your theme would make the most sense, because the data is specific to your theme.

However, more and more developers are pointing out that if a user switches themes, their portfolio items will disappear, both from the front end and the back end. Obviously, this is not an ideal end-user experience, and so the suggestion is made to define the custom post type in a plugin. Now if the user switches themes, the data is visible on the back end, although it still disappears from the front end.

Is this a step in the right direction? Yes, probably. However, let’s not pretend that this is good usability. Which is more confusing, trying to figure out why your data is missing completely, or why it’s only missing on the front end? I really don’t have an answer for that. Neither of them are good options. (more…)

Change Default Media Settings on Theme Activation

Let’s face it, if you’re a developer you want to make things as simple as possible for your clients. One way to do this is to set the default media sizes when your theme is activated. Your users should never need to try to figure out the width of the content area. They shouldn’t have find where the default settings are located. They shouldn’t have to worry about any of that. When they upload an image or use an embed code, the correct sizes should already be set. Here’s how you can do that for them.


  • PublishedNovember 3, 2011
  • Posted InWordpress
  • DifficultyIntermediate

WordPress Taxonomy Tabs

Jason Schuller of Press75.com mentioned on Twitter yesterday that the taxonomy UI in the WordPress admin could use some improvement.

In regards to custom taxonomies, it would be nice to have just one tabbed box within the editor instead a separate box for each taxonomy.
Jason Schuller

I thought that sounded like a good idea, so I went about figuring out how such a change could be made. (more…)

  • PublishedNovember 1, 2011
  • Posted InWordpress
  • DifficultyIntermediate

Setting the Default Editor for a Custom Post Type

Recently I was working on a project where I was writing some PHP and HTML source code documentation and publishing it via WordPress. As you may know, the WordPress visual editor isn’t ideal when it comes to handling such code. Consequently, I went looking for a way to set the default editor to HTML rather than Visual. However, I didn’t want to cause the HTML editor to be the default across the entire site, so I created a custom post type for my code documentation. Then I changed the default editor for only that post type with the following piece of code:

add_filter('wp_default_editor', 'set_default_editor');

function set_default_editor( $type ) {
    global $post_type;
    if('code-doc' == $post_type) 
        return 'html';
    return $type;

All you need to do to use this piece of code is change “code-doc” to reflect the name of your custom post type.

  • PublishedOctober 7, 2011
  • Posted InWordpress
  • DifficultyIntermediate
  • Tested With3.2.1

The WordPress “More” Tag

Those of you who know WordPress like the back of your hand, please feel free to skip this post. It is simply an explanation of the “More” tag used by WordPress post editor. The “More” tag is used to let WordPress know just how much of each post should be displayed on multiple post pages (for example: the home page, category pages, tag pages, search pages, etc. where you might not want to display the entire post). WordPress will start at the beginning of a post and display everything until it runs into the “More” tag. When it reaches the “More” tag, it will insert a “Continue Reading…” link and move on to the next post. Just below this paragraph there is a screen shot of the “More” tag in action. The upper circle is surrounding the “More” button, while the lower circle is demonstrating the visible result of the “More” button from within the post editor. To use the more tag, simply place your cursor at the desired location and click the “More” button. Easy as that!

Please note: In newer versions of WordPress, the “More” button looks a little different.

  • PublishedJune 10, 2011
  • Posted InBlogging, Wordpress
  • DifficultyBegginer
  • Tested With3.0 - 3.2

Sackcloth Studios Redesign

It’s been a few years since I first launched sackclothstudios.com (my business site) and it was beginning to show it’s age. The newest post on the blog was over a year old and the site just needed a little love. I figured while I was at it, I might as well document the process.


« Older Entries