Forcing a Single Term in a WordPress Taxonomy

Taxonomies in WordPress are a wonderful thing. Their purpose is to facilitate relationships among posts (not just Posts) and they do a great job with it. In my client work there have been many times where a taxonomy was appropriate but I only wanted to allow a single term to be associated to each post.

Unfortunately the taxonomy UI wasn’t built in such a way, nor should it have been. Taxonomies don’t necessarily have that inherent restriction, but I wanted to take advantage of the underlying performance gains instead of (mis)using a Custom Field to achieve the same result. While postmeta (Custom Fields) are great, the database table used isn’t set up to handle relationship queries as effectively as a taxonomy.

Lucky for me Web Dev Studios had the same situation come up and took the time to build and release their solution. This was awesome!

Unfortunately for me though, this project would have had quite a few taxonomy terms which meant a really tall meta box. I also thought it’d be great if you could add a new term inline without having to leave the post edit screen, add a term using the taxonomy edit screen, and then resume by editing the draft of your post.

Enter open source collaboration

I took some time to fork their project, stand on their giant shoulders, and apply a couple of changes that satisfied my use case. It involved (more or less) the following:

• Avoid super tall meta boxes by allowing you to specify either a radio input or select box
• Generalize the naming (e.g. switch mentions of ‘radio’ to ‘single term’ where applicable)
• Implement the ability to add new terms inline via AJAX so as to not disrupt workflow

I did this and here’s how it came out:

I wasn’t sure if this was too much of a departure from the original intention of WDS, but wanted to ping Justin Sternberg to hear his thoughts and hopefully contribute back to this code that was exactly what I wanted and that saved me a ton of time.

@jchristopher dude, let’s do it. Is the adder functionality optional? because for many use-cases, we don’t want it.

— Justin Sternberg (@Jtsternberg) August 30, 2014

Sweet! I made a couple of changes, Justin cleaned things up and made it even better, and then Justin Sainton swooped in with even more awesomeness like he always does.

WordPress, open source, it’s all awesome

I find myself needing something like this on nearly all of my projects. I elaborate on it quite a bit in ClientWP Second Edition and I’m anxious to expand upon it even more as I wrap up that chapter. This whole cycle is one instance of the open source (and in this case specifically WordPress) community in action:

• Finding existing code written by a shop I have a big respect for who chose to freely make it available
• Being able to make my own copy, roll in changes I want, and in turn make it freely available
• The original author being super receptive to outsider contributions
• Another contributor seeing the conversation take place and taking the time to contribute
• The whole thing get merged together and all parties benefit

What’s not to like about that? Keep coding!