I am happy to see that so many people have found this plugin useful. I’ve had many feature requests, a couple code contributions, and plenty of bug reports. I appreciate it all.
It’s been over a year since there was an update to the Media Categories plugin, so I’ve been hard at work this past week adding a ton of new features. I’ve taken to heart as many feature requests and bug reports as I could handle.
Heres a detailed list of what you can expect in this new and improved version of Media Categories:
Improved Category Metabox: Filter terms as you type
Back in WordPress 3.4 and earlier, there were no metaboxes for taxonomy on attachments, so I had to roll my own fake metaboxes (“metafauxes”, I’ve started calling them). With the big push in WordPress 3.5 to improve the media modal, the need for that metafaux on the main editor page went away – but with it went one of everyone’s favorite features of this plugin. The “Searchable Categories” field, the input box that let users filter the categories that were showing, making the metabox easier to use.
In Media Categories 1.6, I’ve created a new set of custom metaboxes that bring back this feature! You can now type the name of the term your interested in and the list of terms in the metabox will filter as you type.
Drop-downs Filters in the Media Library & Media Modal
One of the most frequent feature requests made for this plugin has been the ability to filter items in the Media Library by taxonomy, just like you can on the Posts admin list. We’ll I’ve done that, so now you’ll have a separate drop-down for each taxonomy assigned to work with Media Categories.
Somewhat less frequent of a feature request, but still a great idea, has been to have the same ability to filter by taxonomy, but from within the Media Modal. This would be useful for obvious reasons to anyone with a large collection of images – especially for folks who’s website might happen to focus around imagery.
Media Categories 1.6 will include both of these new drop-down filters.
Sortable Columns in Media Library
Simple enhancement, but a frequent request. Click the header of the taxonomy columns to sort them by taxonomy. Not much to say about it except that getting it to work alongside the drop-down filters was pretty challenging.
Improved Media Modal “Metafauxes”
As I mentioned above, a metafaux is what I call a fake metabox - just a simplified version of the metabox meant to be used in places where the WordPress metabox framework doesn’t normally work. When WordPress 3.5 was released, it introduced the Media Modal/Media Manager. As a matter of chance, a bug was introduced. There was no way to distinguish between the media editor in sidebar of the Media Modal, and the main media editor in the Media Library. So my metafauxes were showing up in the modal, but they weren’t working.
I reported the bug, and they got it patched up quickly, but instead of taking out the metafauxes, I made them work – in the modal. However, they were kinda buggy.
I’ve fixed them up now, they look a little nicer, and they work a lot better – and just as before, they collapse to save space on the small modal sidebar, and you can filter as you type!
Gallery Shortcode Compatibility
To be honest, I should have known better. It was back in Media Categories 1.2 that I added the ability to select a taxonomy when using the “gallery” shortcode. This was very cool, and I think it became another big draw for people to use the plugin.
There was a terrible secret here though (thunder!), to make this work, I had to override the default WordPress shortcode (shreak!). This was bound to cause problems, and it did. I’ve received multiple reports of other plugins also interacting with the “gallery” shortcode, and when those plugins are on at the same time as this one – they don’t get along.
I figure most people dont have the conflicts (i think?) – so this plugin by default continues to modify the default “gallery” shortcode for the sake of not breaking people’s websites who already use it this way. However, it also creates a secondary shortcode called [media_gallery]
To stop the conflicts with other plugins, paste two line snippet of PHP into function.php file. This sets a property in the Media Categories object to false which stops my plugin from messing with the default gallery.
See the documentation for exact details on how this will work. I know its annoying that it requires code – but just you wait. An options page is coming.
Bulk Editing – its the one feature request that I really wanted to get into this release, but it turned out to me more work than I had time for. I’ll try to make this feature a top priority on the next major release.
Options/Settings Page – I want to eventually eliminate the need for people to drop lines of code into functions.php to control how this plugin works. I want this settings page to simply let users pick from a list of all available taxonomies, and select which ones should be made to work with attachments.
Code Cleanup/Refactor - Given that the scope of this plugin has changed, I also want to reevaluate how it is written. It is currently a lot clunkier than I’d like it to be.
This plugin was originally meant to only be a tool for developers, to let them easily turn on metaboxes and associate taxonomies with attachments. It’s become more than that, and the users aren’t all developers anymore. That said, I’ll keep intact the control developers already have. I’ll probably even make it so the settings page can be completely disabled by defining some property in functions.php
Can’t wait? Wanna help?
If you’d like to beta test the plugin, please do so. Its available in the master branch of its GitHub repository here: Media Categories 1.6 Beta
If you have a bug to report, I always prefer that you do so on GitHub Issues, since its so much better than the WordPress.org forums.
In the past I’ve mentioned a very complex plugin named “WidgetPress”, which I built and is the underlying foundation of the Sears Community and Kmart Community sites. What WidgetPress does is complex, and the short time I had did not allow me to really clean it up the way I would have liked to. This is why I have not released it publicly.
However, the lessons learned from WidgetPress are many, and some of the ideas and solutions that led to its completion can be feathered out of the bulky plugin into their own stand-alone plugins. Thats exactly what I am trying to do now. The specific functionality I’m working on right now is the idea of using custom post types and taxonomies in such a way that they are no longer independent. It will take some explaining to show how this is useful so I will start by explaining how it is used in WidgetPress.
WidgetPress, at the end of the day just lets admin’s create “Section Fronts” based on category or a Page – define their layout, and drop widgets into them to determine the entire contents of that layout. The widgets themselves make up as much of the page as the theme developer likes – for our purposes, everything between the top navigation and the button navigation is entirely composed of widgets on almost every single page on the site.
For WidgetPress to work, I actually had to completely deconstruct and reengineer the way WordPress handles widgets internally. I completely bypass WP_Widget_Factory, I ignore all those horrible global arrays, and hijack the whole widget registration process. I built my own entire structure for handling widgets, while still allowing (most) normal WordPress widgets to function without a hitch. I could write a whole book about the reasons I had to rebuilt all this but I’ll skip that. In my implementation Widgets are actually a post type, and sidebars are constructed using a custom post type AND a custom taxonomy working together – not in the typical way posts and categories work together – instead the post type and taxonomy function as a single entity. When an admin creates a sidebar, in the background it creates a new post of that post type, and a new term for that taxonomy.
The flexibility this allows is not immediately obvious. Widgets being a post type mean that they exist independent of their actual sidebar. Sidebars being a taxonomy means widgets can be placed into any number of sidebars, and sidebars can be associated with any number of “Pages”, “Posts” or other post types registered for that taxonomy. Sidebars, being a taxonomy and a post type, means that although they are used primarily as a taxonomy – each term can actually store meta data! This is the functionality that today I am building into a separate component.
The project I’m doing this is completely different from WidgetPress, its actually for an in-house products plugin – the intention being that any bit of data about each product can easily be made to be meta data and/or a taxonomy term.
The working name for this is WP_Node. I realize “node” has all sorts of existing meanings and connotations. However, given the way this merges content and relationships, blending them into a single idea – I find it difficult to think of a term that fits it better while remaining as abstract as it should be.
Hopefully in the coming months I’ll be able to release WP_Node (or whatever I end up calling it), as an independent library or plugin. There are also several other very interesting things I’d like to pull out of WidgetPress – maybe at the end of all this I can rebuild WidgetPress using the separate components (each of which will be better thought out and better written).
A user of the Incorrect Datetime Bug Fix plugin submitted a bug report last week. While the plugin was turned on the user was getting an error about improper usage of wpdb::prepare() in WordPress 3.5.
Warning: Missing argument 2 for wpdb::prepare()
This threw me for a loop, since its such a simple plugin that I’ve never had to change, I assumed that something changed in the new version of WordPress 3.5. I was all ready to submit a new trac ticket. As it turns out, it was my usage of wpdb::prepare() that had always been incorrect, if you are a developer and are interested in knowing more about the problem, read Andrew Nacin’s article on the subject. In the past WordPress simply wasn’t throwing out an error and that’s what was changed in WordPress 3.5. I found this by using git’s “bisect” feature, which is really great and I might write a blog post about it in the future.
As always I greatly appreciate but reports, idea submissions for my plugins, and any other feedback regarding the plugins I maintain. It is whats great about Open Source and it helps me validate its usage in the corporate world. The new version is now available for download. Please update to avoid these errors from being reported.
Last week I finally released Media Categories 1.5, but I neglected to write a post about it. Most of the UI issues have been resolved with the Media Modal, however due tot time constraints I could only ensure the plugins compatibility as far back as WordPress 3.3. It doesn’t break the site earlier than that, but selected taxonomy terms dont save properly. As of now, I have no plans to extend support to 3.2.x or before.
I do intend however on adding a few more features that I think are missing from WordPress 3.5 as soon as I have the time. The most obvious of which I will also try to get committed to core. Said enhancements include:
- Fixing the counter on the right of the attachment table – its supposed to indicate the number of media items per category but it does not count accurately.
- Adding a taxonomy filter to the attachments page – for most post types with a taxonomy enabled, the post types admin page shows a ‘View all categories’ drop down. This is missing from media in WordPress 3.5. I would also try to work some similar filtering ability into the Media Modal.
- There seem to still be some UI issues in the Media Modal when multiple taxonomies are assigned to a post type.
- I may create an admin interface in the settings area to allow admins to simply check from a list of checkboxes, which taxonomies (of all available taxonomies) they would like to enable for media.
- I may also include some simple functions for retrieving attachments by taxonomy. Although these would essentially be a simple wrappers of WP_Query or one of its wrapper functions, I believe it would serve as an example to developers on how to get started.
Take a look at how great attachments with taxonomies look in WordPress 3.5 by downloading Media Categories 1.5. Look out for some of these improvements I mentioned above in the next version, Media Categories 1.6.
One additional note: At some point in the near future I will update the plugins pages on this site,… I promise. However, please understand that the pages on this site are meant to contain the same information as the WordPress plugin repository does, mostly in the ‘Other Notes’ tab.
I have solved the UI problem in the modal that was holding up the release of Media Categories 1.5. However due to an additional bug reported to me on GitHub Issues, I did not get a chance to test the plugin in earlier version of WordPress.
I believe Media Categories 1.5 should be fully functional for WordPress 3.5 at this point, but I wont release until I get a chance to test all aspects of it are backward compatible. If you would like to download Media Categories 1.5 Beta 2 ( zip / tar.gz ) now you can get by downloading the version specific tag in GitHub or you can get whatever is the most recent right off the master branch.
This week WordPress 3.5 was released, and the core team has made a some great improvements to the way media is handled in the UI. I managed to get my name in the credits for a measly few lines I contributed in a couple of patches – nonetheless I’m proud to be a part of it.
The reason I created the Media Categories plugin is because of how neglected the interface for media was. Especially with regard for anyone wanting to add support for taxonomy. In 3.5 media still comes without any taxonomy enabled out of the box (as it should be) – but for those who those who do the custom work of enabling one, the interface is now much improved.
In the past, if you simply enabled any taxonomy for media, the editor would get a simple text field into which users would need to manually enter the slugs from memory. The interface for media was unique from that of any other post type. What they’ve done in WordPress 3.5 is simply make the Media interface behave more like every other post type.
So now when a taxonomy is added to media, you automatically get a built-in metabox, you get a column on the Media Library listing the taxonomy terms applied to each item, and you get a taxonomy page specifically for media. They have also greatly improved the modal window for managing media – even adding the ability to edit the details (title, caption, description) right there in the modal.
So what good is the Media Categories plugin now?
On the surface it seems as though my plugin is mostly useless now. It could be stripped down to a few lines to just enable the taxonomy and be done. Thats not the case. First of all, 3.5 still doesn’t support filtering by taxonomy in the “Gallery” shortcode. Also, since a couple of weeks before WordPress 3.5 was released, I have been working to fill in the gaps where I see some room for improvement.
Whats new in Media Categories 1.5?
The new Media modal window has at once, made it easier for me to allow users to edit the taxonomy of an image from the modal screen, while also making the default behavior problematic enough that it merited an overhaul of my plugin to address this problem.
I’ve added a collapsible version of the metabox, along with the filterable search box to the modal media editor.
I’m not releasing it yet, because I’ve run up against a quirk in how the new modal saves data – it causes the collapsable section to immediately collapse when the auto-save kicks in. Getting the auto-save to work at all with checkboxes was a challenge.
When will Media Categories be released?
Once this auto-collapsing behavior is solved, I’ll probably be satisfied enough to release 1.5. However I do still need to test in 3.4.x and 3.3.x to make sure the plugin still works correctly in those versions. I have a vested interest in making it backward compatible because I use this plugin at work, and many of our sites are on several out dated version of WordPress (shh).
I will continue to work on it, and work with the core team to make this happen as soon as possible. However if you would like to take a look at this new version feel free to download it from the master branch on GitHub.
Update: Media Categories 1.5 Beta 2
For the last few months I’ve been neglecting this blog and my publicly available plugins. Thats because 200% of my time has been tied of in this very large projects – the mySears Community and myKmart Community for Sears Holdings Corporation. This matching pair of Q&A style customer service sites have been migrated from a third-party host known as Viewpoints, and onto a self-hosted WordPress Multi-Site installation.
Today I’m happy to say that we’ve launched both.
While I’ve taken part in countless migrations to WordPress from other systems, including one from Viewpoints – this project was truely like no other – not only in the number of hours worked, but also in its technical challenges. Due to fuzzy requirements at the start of the project, the end product turned out different from what we expected on day 1 of development. If I were able to solution this project over again knowing what I know now, I would have chosen a much simpler approach. However it resulted in the development of some very interesting tools.
Of the parts I got to work on, there are 3 plugins that I’m proud of and that I think will be useful to the WordPress community – Custom Comment Type, Section Fronts, and WidgetPress. I won’t go into too much detail in this post, but heres a brief description of those three.
- Custom Comment Type – create Custom Commeny Types much the same way developers already create Custom Post Types.
- Section Fronts – A custom post type called ‘section’ that can be chosen to represent a category, post type archive, or even an intersection between the two. Similar to the way admins can already select a ‘page’ to represent the front page.
- WidgetPress – A layout management tool based on the existing Widgets API infrastructure. Overhauled to work off two custom post types and a custom taxonomy – sidebars (referred to as dropzones) can be sized and created on the fly on a page-by-page basis leveraging a css grid framework on the front end. This – especially when used in conjunction with Section Fronts – has by far the greatest potential to make an impact, and opens up a whole host of possibiities for how WordPress is used.
I’ll try to write more about each plugin in the weeks to come. For now, none of them are clean enough for me to release them publicly. I’d like the opportunity to rewrite each one from scratch and do things the right way now that I know how it all needs to work – but I dont think I’ll have that much time so I’ll have to settle for something in the middle.
I’ll also throw up some screenshots for some of these, and at some point I’ll probably create a demo video of WidgetPress in action.