custom post types

I’m pretty excited about this update and multisite compatibility is the reason why! As someone who manages a pretty vast multisite network, I think WordPress multisite is awesome and hope others find this new functionality useful as well.

But version 1.3 didn’t present itself solely bearing the fruits of multisite. Here’s the full list of improvements:

Before, you were pretty much stuck with “{post type}/tax/{term slug}” (which is still the default) but now, via the settings panel, you can use your own keywords with a little help from the variables $post_type, $term_slug and $term_id. Don’t forget to flush/reset your rewrite rules once you’re finished!

Tell the CPT-onomy tag cloud widget whether you want the terms to link to their archive page or to their custom post type post page

When you’re using wp_get_object_terms() to request term information, you can now specify term ids to exclude from your results

The CPT-onomy class has a new function! Introducing get_term_ancestors(). I think it’s a little self-explanatory =)

CPT-onomies now supports Internationalization (can’t believe it took me so long!)

I also tweaked the UI and fixed a few bugs

I hope everyone enjoys the update as much as I do. Sorry it took me so long. My life has been a little crazy but I’m glad to be on the other side of the hiatus!

Please let me know if you have any questions or find any bugs! Thanks for being such awesome users!!

This is an interesting WordPress problem that could span several scenarios. But let’s say you have a custom post type named ‘songs’ and you defined its slug as ‘songs’ so its archive page URL is http://www.mysite.com/songs.

This is fine and all but a slug used for a custom post type archive page, i.e. ‘songs’, is not saved in the database and is, therefore, not available when you’re creating/editing posts to tell WordPress “NO! The slug ‘songs’ is taken!”. With that said, a user could come along and create a post (or page) with the slug ‘songs’ which would therefore have the same URL as your custom post type archive page: http://www.mysite.com/songs.

So how do you keep users on your site from creating posts with particular slugs, a.k.a. reserve slugs?

It’s pretty simple, actually. Use one, or both, of the following two filters. They hook into WordPress when it’s checking a post’s slug, allowing you to return “true” which tells WordPress that the post slug is bad. If you return “true”, WordPress adds on a suffix, just like it would do if you were trying to use a slug that is already taken.

The first filter, ‘wp_unique_post_slug_is_bad_hierarchical_slug’, is for hierarchical posts and the second filter, ‘wp_unique_post_slug_is_bad_flat_slug’, is for non-hierarchical posts. While both filters provide the post’s $slug and $post_type, the hierarchical filter also provides the ID for the post parent so if the $post_parent is 0, you know this is a “base” post.

CPT-onomies is a WordPress plugin that allows you to create, and use, taxonomies powered by your custom post types, using the post titles as the taxonomy terms. The best part about CPT-onomies is that they work just like regular taxonomies and therefore use the same functions!

Unfortunately, not every taxonomy function works right now but don’t worry, I’ve created CPT-onomy functions to help bridge the gap between WordPress and the plugin. The CPT-onomy functions even mirror the WordPress functions, using the same parameters and return values.

Use the CPT-onomies Documentation to see which WordPress taxonomy functions work and when you’ll need to use a CPT-onomy function. The documentation also includes function parameters, return values, examples, and other helpful information.

If you notice a mistake, or have a function request, feel free to leave a comment or contact me.

If you’ve ever used a WordPress custom post type or taxonomy, you know that they can be powerful tools for creating and organizing content. But what if I told you that you could take these features a step further and create relationships between your post types, using your post titles to assign taxonomy relationships?

Humble beginnings

When I was first building http://eng.ua.edu, I knew that custom post types would play a huge role (and basically take over my life). With numerous post types, I wanted to establish a dynamic “People” directory that would connect each person to the “Departments” they worked for, the “Buildings” they worked in, the “Capstone Engineers” they were featured in (our research magazine), and any other content available.

In came custom taxonomies. I created taxonomies that “mirrored” each custom post type (using the post title as terms) and, voila, a dynamic and easily filtered people directory was born! But while managing the “Buildings” taxonomy was easy (buildings don’t exactly come and go on a daily basis), imagine managing a list of 200+ people and having to make sure the “People” taxonomy always matched the “People” custom post type. It’s more than just managing the titles, you have to make sure the slugs match too! Let’s just say that system didn’t last long.

From Idea to Plugin

While the premise of being able to use custom post types as taxonomies, and not having to duplicate information, was always the root of the project, “CPT-onomies” has taken several forms. At first, it wasn’t even a plugin, it was in my theme. When it progressed to a plugin, it was just for personal use and was very rough around the edges, using all kinds of WordPress hacks in a devil-may-care manner. To give me some credit, I had only been using WordPress for a few months and was on a strict redesign schedule. “Behind the scenes” was not a high priority.

But the website launched, my WordPress skills grew, and before I knew it I was saying things like “I bet I’m not the only one who could use this setup” and “This system of using custom post types as taxonomies would make a great plugin”. Little did I know how much fun I would have over the next few weeks.

Developing CPT-onomies

It wasn’t until I started development that I came up with the idea to hook into WordPress core and register the custom post type taxonomies as actual taxonomies. Once this decision was made, the project grew tenfold but, boy, was it worth it. Not only did it make the plugin stronger but it kept the user from having to learn or implement new code. That, in itself, was worth every minute of development. Tack on an extensive custom post type manager, so the user can manage their custom post types within the admin, and you’ve got yourself a pretty powerful plugin. Is CPT-onomy an official WordPress term? No. It’s just a fun word I made up. =)

Using CPT-onomies

One of the best features of the CPT-onomies plugin is that you don’t have to create CPT-onomies to put the plugin to good use. Featuring a full-fledged interface, CPT-onomies allows you to create custom post types, and manage them, without touching one line of code! If you’re already using a plugin, or theme, that creates custom post types, don’t worry, CPT-onomies is all-inclusive. Any registered custom post type can be used as a CPT-onomy.