The page appears to be a mashup (do people still use that term) taken form wordpress.org plugin repository. The ranking on the page appears to be based on plugin downloads. Still out of 1000 plugin authors it’s nice to be in the top half. Though would be grateful to placement anywhere on the list. Thanks W-Shadow.
by Paul Menard·Comments Off on Media-Tags 3.0 plugin for WordPress Released
I’m proud to say I’ve finally released Media-Tags 3.0 to the general public and it is available via the WordPress plugin repository http://wordpress.org/extend/plugins/media-tags/. Thanks to all who contributed ideas, bug reports and support in this milestone development. And my apologies for taking so long to get this out.
This plugin contains many new features. Some highlighted items are:
Bulk Administration of media items This feature on both the Media > Library and Media Upload popup for the Post admin screen allow you to assign/remove Media-Tags to a selected group of media items. In previous versions you would need to edit each media item.
Roles management Under the Media-Tags Settings panel is a new Roles management panel. This panel allows you to fine tune the access by individual users.
Internationalization This is a much needed and requested features. Now all text handled by the plugin are using the WordPress i18n hooks to support translation into other languages.
Removed over 1000 lines of custom code This old code was used to provide basic functionality for the tagging and URL rewrites. Since WordPress core functions have progressed over the last two years this custom code is no longer needed. This means the plugin will run cleaner and is more stable than previous releases.
Better support for WordPress standard Taxonomy templates In the past the plugin has supported a custom theme template, mediatag.php. The plugin now support the more standard WordPress templates taxonomy-media-tags.php.
A new Help section This new Help section provides many topics from general use to shortcodes tricks to template files support questions. Check it out.
Many other features have been added. Too many to mention here.
This is part 2 of a series on digging deeper into the new WordPress Custom Taxonomies. In the previous article, “Custom Meta for new Taxonomies in WordPress 3.0“, I walked you through setting up the custom meta tables and the Taxonomy term editor form. In this part of the series I’ll show you how to add your new taxonomy meta fields to the taxonomy listing page.
Background
To bring everyone up to speed on the project I’m developing a simple product management system (e-Commerce) for a client. I wanted to take advantage of the new Custom Post Types and Taxonomies in the WordPress 3.0 system. I setup a new Post Type ‘Products’. As part of Products I’m defining a new Taxonomy ‘Product Packages’. A ‘Package’ is how a product is sold to the user. Think of threadless.com or some product site where you must select options like size or color. In our case each package has a number of extra ‘meta’ fields associated with it. In the case of my product packages some of these meta fields are unit price, shipping price, package active.
The goal of this article is to modify the default columns displayed on the taxonomy listing. These default columns are Name, Description and Slug. While these are sufficient for other taxonomies like post categories or post tags they don’t exactly work for my product package needs. What we will be building is some more like the following which includes meta field from part I. The column headers we will be added are ‘Active’ to show when a Product Package is on or off and the column header ‘Price’ which is the unit Price for a given package. These columns were chosen because the let the administrator visually see the information in the table form without needing to access each package detail.
WordPress Taxonomy meta listing
So lets get started.
Adding Taxonomy Column Headers
We will start with adding the filter to modify the column headers. When I click on the ‘Product Packages’ I noted that URL for the taxonomy listing is
After doing some digging I found that the edit-tags.php code calls a number of functions to build out the page structure. One of these function is ‘get_column_headers()’ The get_column_headers function is located in the /wp-admin/includes/template.php file line 674. Inside this function there are various checks to see if we are dealing with a normal build-in screen like for post categories or post tags. If not the logic falls down to line 761 there a filter is executed. The filename key or name is dynamic and is based on the taxonomy name. The filter key is ‘manage_’ . $screen->id . ‘_columns’. The screen->id value is the taxonomy name we used ‘product_packages’. The filter we will be setting up will be ‘manage_product_packages_columns’. So in our code’s init function we to subscribe to this filter and add a function to handle the processing. Below is the code. The init function you may recognize from part I.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
This should get the new columns added to the display table. You can save your code and verify. The table headers will be displayed. But the row content will be empty.
Adding Taxonomy Column Data
The table row content is added using another filter hook. Again, once of the function called from within edit_tags.php is the core function tag_rows(); This function in turn calls other functions. Eventually, the flow ends up in _tag_row() in template.php line 398. Much like the header logic various checks are made to see if we are dealing with a built-in taxonomy. If not then a dynamic filter hook is executed at line 483. This dynamic filter like the header filter uses the taxonomy to name the filter key unique. The filter key is
‘manage_${taxonomy}_custom_column’. Again placing in our taxonomy key ‘product_packages’ the complete filter key will be ‘manage_product_packages_custom_column’.
So back to our code we add another add_filter command to out init function. Then we add a new function to process the filter request.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
I’ve been playing around with the new options in WordPress 3.0 like the new Menu system and Custom Post types. These are fantastic additions to the WordPress engine. The guys who work on WordPress core really deserve a big hand.
One other item which gets less attention are Taxonomies. When you initiate a new Taxonomy you are basically cloning the existing Post Category or Post Tags logic. With Post Categories you are provided an additional field for parent because post categories are hierarchal. But what if you want to add additional fields to the interface? This is what I intent to disclose in this article. Continue reading
I have to really tip my hat to the guys that work hard on the core WordPress code at Automatic. In the last 12 months they taken the system to new heights with a complete redo of the admin interface. Adding many features to extend the core so that developers like myself can extend things even further.
Take for example the nice little number displayed on the Plugins menu item when some of your installed plugins are out of date. What a nice little feature. There is also an update display on the actual Plugins page the little yellow-ish box below a plugin row to indicate there is an update and the user needs to take action. From a usability stand point I think this sort of forward thinking is the reason I keep hacking in WordPress instead of other CMS-type systems like Drupal, Joomla, eZ Publish, etc.
But I do have a major annoyance with this ‘feature’. Like many other WordPress users I have man plugins installed. At any given time I will have a third of the plugins disabled maybe because I was testing things or maybe I deactivated the plugin but didn’t want to uninstall it. My annoyance is that the plugin update indicators work on all plugins even those you don’t have active. Not good. Worse on the client sites I support I really don’t want the client to need to worry about updating inactive plugins.
Sure I know there are at least half a dozen plugins that will completely turn off the plugin and WordPress core update nag indicators. But I really don’t want that. I just don’t want to see update nag on those plugins I’m not currently using.
So I did some research on this lazy Sunday afternoon and figured out how to hide the update indicator on those inactive plugins. The code below will hide these inactive plugin from the update counter. When the plugin is re-activated the plugin update indicator will once again show in the sidebar menu and on the plugins listing.
The Code
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
A note on the ‘add_filter’ lines just above. Seems there are two different hooks depending your the WordPress version. If you are running version 2.8.x or newer you should be safe to use the first add_filter line. If however you are still using 2.7.x then comment out the first add_filter an use the second one.
Installation
I really don’t plan to turn this into an official plugin for WordPress. So the simplest method of installation is to add it to your theme’s functions.php file.
You must be logged in to post a comment.