Media Categories 1.4 – Limitless Taxonomy

Yesterday a co-worker expressed a need to use the Media Categories plugin with not just a custom taxonomy, but with multiple taxonomies. So I spent last night at the office until around 9:45PM working on Media Categories 1.4.

Not to get bogged down in overly technical talk here, since I know that a lot of the users of this plugin are not developers. The main change in this release is that the class is instantiated as an object rather than called statically. All (except a few) references within the class have been changed from static references to objective references.

If you don’t know what the heck I’m talking about, thats ok. All it means is that developers can new create any number of instances of Media Categories checkboxes, for any number of taxonomies.


Lets say you already use Media Categories for the “Category” taxonomy, but now find yourself needing to apply a new custom taxonomy – lets call it ‘genre’. All a developer needs to do is create a new object, and pass ‘genre’ as the parameter.

$genre = new Media_Categories('genre');

Thats it! As long as that taxonomy exists, and has all the proper “labels” set up, Media Categories 1.4 will add a second metabox to media with all the proper labels for pluralization and context.

Filtering a Taxonomy

Since the release of Media Categories 1.3, which was less than a month ago – developers have been able to change the taxonomy being applied to media by making use of the `mc_taxonomy` filter. This is still the case, but theres to it now that there might be any number of taxonomies applied to attachments.

If you simply return ‘your_taxonomy’ to the filter without any conditions, you will over ride all instances of Media Categories in use – so to avoid that, developers need to check the value of the current taxonomy before modifying it.

add_filter('mc_taxonomy', 'custom_taxonomy_metabox');
function custom_taxonomy_metabox($taxonomy){
if($taxonomy == 'category'){
$taxonomy = 'custom_taxonomy';
return $taxonomy;
Thats all, nothing too bad - just be sure to conditionally check for the specific taxonomy you want to replace.
Please let me know how this works for everyone. Enjoy!

Media Categories 1.3.1 & a Trac Ticket with Patch

I didn’t have a chance to post about this, but last week I quietly released Media Categories 1.3.1, to workaround a problem which was reported to me on the support forums in the WordPress Plugin directory.

A user of the Media Categories plugin explained that some under certain circumstances, categorized media would not save properly. Here are the steps to reproduce the problem:

  1. Create two categories with the same name, but different slugs.
  2. Open up an attachment while Media Categories 1.3 or below are turned on. (download that version here)
  3. Select the two same-name categories, and click save. WordPress will take you back to the Media Library.
  4. Open the same attachment again, and click save, without having changed anything.
  5. Open that attachment once more. You will find that one of the categories that had a duplicate name, is no longer selected.

The first thing I did was turn off the styling on my plugin, which hides a text field that WordPress creates when an attachment has taxonomy support and watched what it did as I went through each of the steps above. This field will take term ID’s, slugs, and names – it can take any number of terms, each separated by commas – but requires the user to manually enter them from memory, which I why I built my plugin.

Once the user has selected and saved their terms, upon re-opening the attachment, that field will always be populated by the categories name. When names are used in that field, WordPress simply tried search for that category by name,  which as we know can be non-unique. This results in WordPress chosing the first term with that name it comes across, for both instances of the name – resulting in the later on being lost. The next time you open that attachment, there’s only one instance because both were saved as the same term.

I figure this has gone unnoticed because WordPress does not natively support taxonomy for attachments, and few people use plugins that turn on that support. It’s easy to see how the original developer of the built-in text field would have thought that using the term name would be easier for end-users to deal with – however it clearly causes problems when in use.

I opened a ticket in WordPress Trac, and submitted a very modest patch that changes one line in core so that is spits out the slug instead of the name. However who knows when that ticket will be  dealt with, and we are very close to WordPress 3.4 being released, so I don’t have much hope of it being part of that release.

With that in mind I developed a fairly simple workaround which accomplishes the same goal, but by effectively re-doing what WordPress does when saving an attachment. I released it last week over the holiday weekend as Media Categories 1.3.1, and I suggest anyone using this plugin upgrade, or risk losing some of their saved data.

Thanks for reading, and thanks for the bug reports.

Update:  My patch was accepted and will be released in WordPress 3.5. As small and simple as it might be, and even though I’ve been working with WordPress professionally for over 3 years – this is the first time one of my contributions to core has been committed. Yay me.

Media Categories 1.3

On the heals of release of Media Categories 1.2, which added Gallery Shortcode support, I’m releasing Media Categories 1.3 which allows developers to change which taxonomy is being used. If you’re not a developer, this update won’t be of much use to you, as you won’t be able to write the necessary code to change the taxonomy. Thats not the case if you happen to be a developer making use of this plugin.

Developers can use the new ‘mc_taxonomy’ filter to change the taxonomy very easily. Take a look here, as I use this filter to change the plugin so that it used the Tags taxonomy rather than Categories.

add_filter('mc_taxonomy', 'mc_filter_taxonomy');
function mc_filter_taxonomy(){
return 'post_tag';

Of course, your free to use any Taxonomy, including Custom Taxonomies. So that sort of means this plugin is no longer really ‘Media Categories’, but rather ‘Media Taxonomies’ would be more appropriate.

Please report any bugs you find with this. There are plenty if ways that people configure their custom taxonomies and some bugs may crop up under certain circumstances. If they do, please report it here or in the WordPress plugin directory  forum for this plugin.

As a final note, I’d like to point out that just like the Gallery Shortcode feature in Media Categories 1.2, this new feature in 1.3 was suggested by a developer in the WordPress Plugin Directory forum for this plugin. I value the feedback I get from other developers and users, and so far I’ve received pretty much all positive, constructive feedback. Thanks to all.


Media Categories 1.2, Now Supports Gallery Shortcode

A few months ago I received suggested it might be a good idea to allow the gallery shortcode to retrieve attachments from a category as part of my Media Categories plugin.

So here it is, Media Categories 1.2 extends the native WordPress Gallery Shortcode to allow you to select a category to display via a newly added ‘category’ parameter which can take either a term_id OR a slug.

[gallery category='slug']

Normally the gallery shortcode only shows you images that have been attached to the current post, or a post id passed as an argument. This normal behavior is preserved with Media Categories 1.2, however when invoking the ‘categories parameter, the current post is ignored, unless its id is explicitly passed.

[gallery category='slug' id='12']

In the example above, the gallery shortcode will create a gallery of any images that in the category called ‘slug’ AND are attached to post id 12. If the id is not explicitly passed, then it will simply return all images from the category.

As I’ve stated, if you don’t invoke the category parameter, the gallery shortcode will behave as normal, so this plugin will not interfere with how galleries already in use will behave.

I have a few additional updates coming soon for this plugin, per another request I received via the plugin directory forums, version 1.3 will include a filter so that developers can change the taxonomy at will.

Thanks for using the plugin, as always I appreciate bug reports and feature requests, I hope you find good use for this new feature.

Plugin Update: Category Template Hierarchy

Download Category Template Hierarchy Version from the WordPress Plugin Repository

This plugin has seen a flurry of bug fixes and updates since 1.3 was released and we’re now on version I am really sorry for having so many updates back-to-back.

Everything since 1.3 is bug fixes, here is a summery of what was fixed.

  • `category.php` templates were not being loaded (somewhere down the line I must have removed it by mistake)
  • In cases where the current category was neither parent nor child, the plugin would fail to load anything from the hierarchy other
  • Lastly, I screwed up a commit, and the changes for 1.3.2 didn’t go out, hence

I really appreciate the feedback I’ve received from people using this plugin. These bug reports not only help me make my plugin better for you guys, but also for myself and my job  – where every one of my publicly released plugins is being used on production websites. These bug reports and public feedback really help to justify releasing our code publicly when we can, and open source as a whole.
Thanks you all!

Download Category Template Hierarchy Version from the WordPress Plugin Repository

Plugin Update: Simple Hook Widget 2.0

Download Simple Hook Widget from the WordPress Plugin Repository

The Simple Hook Widget just got a little bit less simple.

Since I released this originally, it seems people have a hard time understanding what this plugin could possibly be good for. I can understand that given the vague nature of it being a  plugin for hooks.

Additionally, there is a signficant security problem in having this plugin turned on for a server where other non-developers have access to the widgets panel – primarily thats because this plugin lets you do ANYTHING !! Including the use of hooks that are part of core, and could cause serious problems if they are run at the wrong time (such as in the sidebar.

This update introduces the ability for developers to provide an array of hooks, and have those hooks show up as a drop down menu in the widget. Additionally, there is another hook which allows for a default value for that hook.

There is also a complete example packaged with this plugin, for how to setup your own list of hooks, how to set a default, and an exceedingly simple example of how to actually do something with a chosen hook.

Have fun, and please please please be CAREFUL using this plugin.

Download Simple Hook Widget from the WordPress Plugin Repository

Plugin Update: Category Template Hierarchy 1.3

Download Category Template Hierarchy Version 1.3 from the WordPress Plugin Repository

I’ve release an update to the Category Template Hierarchy plugin, a particular bug report prompted the update but there are a couple of other changes as well.

I use this plugin for three sites I’ve worked on for Sears / Kmart, so over time I make  minor changes to resolve issues I notice or improve how it works, but I don’t always have time to release those changes publicly.

A recent bug report forced to release a fix, and gave me an opportunity to update the plugin. Some of these changes effect how the plugin behaves, so it could impact your site if you depend on this plugin to keep your theme working. Here are the changes

  1. Improved performance be removing completely unnecessary logic to determine current category while building the list of potential templates to use. (No behavioral effect)
  2. Changed the filter used by the plugin. Before it used the very broad and general ‘template_redirect’ filter, but that caused obvious problem with other parts of the hierarchy, so not it uses the ‘category_template’.
  3. In addition to changing which filter is being used, the plugin used to `include()` the `get_query_template()` function, but now returns `locate_template`. This should resolve a bug where global variables such as $post were not available from within the loop.
  4. Logic in the `is_child_of_category()` and `is_parent_of_category()` has changed to check `!isset($child_category->parent) || !isset($parent_category)` instead of `empty($child_category) || empty($parent_category)`. This could effect your code if you use these conditional tags for anything in your theme.

The only item that does not effect any behavior is #1. Items #2 and #3 change the way the template hierarchy effect other parts of the native Template Hierarchy, so if you’ve seen strange behavior with non-category templates then you’ll definitely benefit from these changes. Item #4 is important as well, since it simply makes the conditional results much more accurate.

I don’t know how often people use the conditional functions, or how many of the couple thousand people who’ve downloaded this plugin actually use it at all – but I really appreciate the bug reports and any feedback. As I’ve said, I use these plugins myself on productions sites – so the public QA is always appreciated.

Download Category Template Hierarchy Version 1.3 from the WordPress Plugin Repository