NOTE: THIS IS A BETA VERSION AND SHOULD NOT BE USED ON A PRODUCTION SITE. PLEASE ONLY TEST ON A DEVELOPMENT SITE. YOU HAVE BEEN WARNED

Some interesting points regarding the new 2.0 release:

1. The plugin has been rewritten from the ground up. This means the old crappy code from 3 years ago have been replaced with newer crappy code.
2. Taxonomies and Post Types. The prior version of the plugin only supported the built-in Taxonomies and Post Types. The new version supports any Taxonomy and Post Type. Some Post Types like nav menus and links are purposely excluded. Oh My!
3. New interfaces. In the prior version of the plugin I build screens for each supported Taxonomy and Post Type. Over the years I had reports that when the site contains 3000 tags loading the Tag Exclude screen would take forever. Well good news. All those screens are history. In the new version of the plugin I’ve added columns to the Taxonomy, Post Type and User listing to allow management within a more natural interface.
4. I’ve updated the Settings/Options screen to by a simply listing of the Taxonomies and Post Types and what actions you are allowed to filter on.
5. I’ve removed support for third-party plugins. In the previous version of the plugin I supported integration with two plugins, Google XML Sitemaps an Search Unleashed. Over the years these plugins have changed such that my backdoor method of interfacing with them kept breaking. This became a headache. So decided to drop the support. Sorry for anyone who relies on this.
6. Finally all those who have tried to use this plugin to Exclude Pages now will have a working solution. The new version of this plugin now properly filters Pages on Search. Also, I’ve added support for the WordPress Pages Widget.
7. I’ve compiled a Help panel to assit those having trouble or just needing to get unstuck

Still todo. I need to make sure this new code works under a Multisite installation. I’ve tested on my local development site using the default WordPress theme and settings. From what I can tell it works. But would really like to get someone who is heavy into Multisite give it a review.

Download Simply Exclude version 2.0 Beta 1

So I jumped to the Microsoft site. Found the Windows 7 part of the site. I was looking for some quick comparison between the three different versions of the operating system. But was not able to find anything. This really makes me appreciate OS X which is really just one version. And damn cheaper!

So I decided to Google for more information. Found the BestBuy.com site. As this will probably be the store I make the purchase from I drilled through to the website page. The BestBuy.com site does have a nice popup comparison chart on the differences between Home Premium, Professional and Ultimate version of Windows 7.

Chart from BestBuy.com showing differences between Windows 7 versions

What I find really strange (and the reason I’m taking the time to write this) is some of the descriptions. Like the first line “Manage the things you do every day with improved desktop navigation”. Um, I’m sorry but should’t that actually be a given? Or the 5th line “Easy to create a home network and connect your PCs to a printer with HomeGroup”. Again I’m stunned. No thanks I would like the other version of your operating system which does not make setting up a home network easy. Thank You sir, Can I have another?

Give me a break. Maybe I’m just a Apple snob (don’t call me a fanboy). Over the last 6 years I’ve really come to appreciate the streamline marketing done for Apple. No hype and no marketing double-speak.

Case in point the newly released Apple iPhone 4S. For weeks and months I’ve been pretty much spammed by repeated speculation on the upcoming new iPhone 4S/5 but most of the tech centric media engines. Plus, as is standard acceptable form these days, a story posted on one tech media site will be pilfered and repeated verbatim by another source as new news. Hate the fact that my feed reader think these are separate stories.

Now the day has come that Apple has finally revealed the new iPhone 4S. Hooray! Now, acting like petulant children the day after Christmas, you seem fit to slam Apple that they have lost their innovative edge. Really? Let me see you actually produce something you F*CKS. Really in my own opinion Apple couple have gone the path of lesser companies and given you a newly designed package so it is at least different than the previous iPhone 4 model and not change a thing about the internals of the device. But no Apple did the right thing and kept the outside aesthetics of the device the same but upgrade and improved the internals making it a step better than the current model. Boo for you that you speculation and constant spinning of lies didn’t pan out.

For the record I’m not disappointed in the new iPhone 4S. Will I upgrade to the new device? Probably not since I just upgraded to the iPhone 4 this past summer due to my contract cycle.

Well, readers here is the simple solutions. There are basically 2 hooks. One is a filter. The other an action. Below are examples of how to setup these hooks. I explain the details below the code listing.

So what are these filters/actions function?

The first line, add_filter( ‘manage_edit-post_columns’… sets up a filter. This filter adds the new column to the listing. This filter is called only once when the page is loaded. Since this is a Filter WordPress will call our function ‘admin_post_header_columns’ and pass in a parameter. In this case the parameter is an array of columns. As part of our function we can change/add/delete items from the array then we MUST return the array. In our simple example all we are doing is adding an item to the array for our ‘Notes’ columns. As with any PHP array we assign a key to be ‘note’ and the column label ‘Notes’. Then return the array back to WP.

A note about the filter name. Notice we setup the filter as using the first parameter ‘manage_edit-post_columns’. Keep in mind this filter is specific to Posts. If you wanted to do this same thing for Pages you would instead use ‘manage_pages_columns’. Or if you were using a custom post type the value would be ‘manage_{$post_type}_posts_columns’ where ‘{$post_type}’ is your post_type. For example if we register a new post_type Products with the key ‘products’ then the filter would use the parameter of ‘manage_products_posts_columns’. On to the second hook. The action.

The second line of our code registers an action. While the previous filter added the column to the listing. This action gets called for each row of the displayed posts to display the contents in the row cell for that column. In WordPress an action is different than a filter in that your function may be passed some optional parameters but you are not expected to return any values. For our purpose we setup an action to the hook ‘manage_posts_custom_column’ which will call our function ‘admin_post_data_row’.

Inside our function we setup a case statement to switch on the column name. In our instance we only want to effect the ‘note’ column. This ‘note’ value is the array ‘key’ we defined in our previous filter function.

Back to the action hook registration. Notice the third and fourth parameters on this action registration call. The third parameter tells WordPress the priority of this hook o when to process it in relation to other hooks. A lower number means sooner a higher number means later. We set this to ’10′ which is a default value. The fourth parameter tells WordPress how many arguments to pass to our function. By default there will be only one argument, the column name. But since each row (post item) will have different values we need the second parameter which in this case is the ID of the post so we can look up the related custom field.

Also, like the filter hook where we setup the column there are different filters to call based on if you are using this on Pages, Posts or some custom post_type. In our case we are adding the column to the Posts listing so the first parameter of our hook is ‘manage_posts_custom_column’. If we were adding a column to Pages the parameter would instead be ‘manage_pages_custom_column’. And if we were adding this column to a custom post_type the parameter would be ‘manage_{$post->post_type}_posts_custom_column’ where ‘{$post->post_type}’ is the key to our registered post_type.

I hope this helps with a deeper understanding of WordPress and an appreciation of the wonderful world of WordPress actions and filters.

Here is a breakdown of the changes.

1.3.1 – Fixed issues is plugin which were effecting the Media Library listing. As far as I can tell this was related to the update in WordPress 3.1.3

1.4 – Added support for any hierarchical post type. Previous versions of the plugin only worked for the default Pages. Now if you have any custom post type defined hierarchical you can have better formatting of the output.

1. 5 – In the previous version (1.4) I added support for custom post types. In this latest version I’ve added support for hierarchical taxonomies as well. Here is an example of a terms listing showing the breadcrumbs and navigation to ‘children’.

To comment or report an issue regarding this plugin please see the main project page for Pages-Children

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.

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.

Please leave all comments on the Media-Tags project 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

http://local.localsite.com/wp-admin/edit-tags.php?taxonomy=product_packages&post_type=products

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 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.

And that is it. At this point you should now see your taxonomy custom meta fields display in new column when listing your taxonomy items.

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.

Before we get into the code example let me provide some background. I’m working on a custom shopping cart for a client. I intent to support the shopping cart system using a Custom Post Type and 3 Custom Taxonomies. The Custom Post Type will be called ‘Products’. Within Product we have at least 3 new Taxonomies. These are ‘Product Categories’, ‘Product Tags’ and ‘Product Packages’. The ‘Product Categories’ and ‘Product Tags’ function similar to the Post Categories and Post Tags but are used for the Products. The third Taxonomy, ‘Product Packages’, is a little more special. A ‘Package’ in terms of the shopping cart functionality will contain information related to the product configurations. For the client a Product is a photograph and is sold in different formats as in 8 x 10 Print, 8 x 10 Matted and Framed Print, Xmas Cards, etc. You may be thinking these are are just categories and you would be correct. The WordPress Taxonomies support 4 basic fields of information Name, Slug, Parent and Description. For the ‘Product Packages’ Taxonomy I also need to store extra fields such as Active status, Unit Sale Price, Unit Ship Price and Unit Quantity.

Here is a screenshot of the actual Product Package detail.

WordPress Taxonomy Meta fields

Here is the simple code to define the new Taxonomy ‘Product Packages’. I’ve wrapped this in my init function to make it easier to use.

Now we want to hook into some actions created by WordPress when the new Taxonomy is registered. The first action is used to insert extra fields to the Taxonomy item edit form. Note that all Taxonomies offer the quick edit and the full edit form. This is for the full edit form only.

Let’s break down the code some. The ‘add_action’ is a built-in WordPress function. The first parameter ‘product_packages_edit_form_fields’ is a dynamic action key which is created based on the Taxonomy key + ‘_edit_form_fields’. In our case the Taxonomy key is ‘product_packages’. This action is executed from the WordPress file wp-admin/edit-tag-form.php line 68. There is also another action on line 67 which is more generic ‘edit_tag_form_fields’. But we are only concerned with the edits for our Taxonomy. From edit-tag-form.php line 68 you can see the action will pass your function two argument the Tag being edited and the Taxonomy. So our function ‘edit_product_package’ also supports two arguments passed into it. Though we really don’t need or do anything with the second argument since we know this is our specific Taxonomy ‘product_packages’.

Inside the function we call the new WordPress function ‘get_metadata’ to load in the meta items we will be adding to the bottom of the item edit form. This function replaces the get_post_meta function. Actually if you review the get_post_meta function in wp-includes/post.php line 1196 you will see if calls the get_metadata function. The new get_metadata function takes the same basic arguments. The big difference is the first parameter which needs to be a valid Taxonomy. In our case we pass in the Taxonomy ‘product_packages’. Once we have loaded all the item meta information we then display the table row which contain our new form fields. PRetty simply.

Next we add another action hook. This one will activate when the user saves the Taxonomy item. Here is the action code.

This action is similar to the previous action we discussed. But one gets initiated from wp-includes/taxonomy.php line 1970 and is called after the Taxonomy item has been updated in the database. The action key ‘edited_product_packages’ is again made up of ‘edited_’ + our Taxonomy key ‘product_packages’. Also like the previous action we tell the action we want to accept the maximum two arguments though we only really care about the first on. Inside the function ‘save_product_packages’ we check to make sure the ‘term_id’ was not empty. The rest of the function code simple checked if the $_POST variable was passed in from the form. And if it was the WordPress function ‘update_metadata’ is called with the Taxonomy key ‘product_packages’ and the updated value. Again the function ‘update_metadata’ replaced the function and works similar to ‘update_post_meta’.

That is pretty much it for the WordPress coding part. (keep reading)

Not quite. There is one other important topic to discuss. We need to create a new database table to contain out ‘product_packages’ term meta information. Let me explain why. You might have a guess that our ‘update_metadata’ function would store the fields into the wp_postmeta table. Well you would be a close guess but wrong. The function ‘get_metadata’ and ‘update’metadata’ use the Taxonomy key provided via the first function argument to interact with a specific database table. The name of the database is again determined based on the name of the Taxonomy from the first argument. In our case the table name will be something like ‘wp_product_packagesmeta’. Note this depends on your table prefix as defined in your site’s wp_config.php. See the similarity in the tables ‘wp_postmeta’ and our table named ‘wp_product_packagesmeta’? It is simply ‘wp_’ + Taxonomy key + ‘meta’. Again the ‘wp_’ table prefix will be different depending on your settings in your wp_config.php file for the variable ‘$table_prefix’.

Next we need to define the table structure. Again there is a similar pattern for the column names. If you examine the wp_postmeta table columns you will see the 4 columns meta_id, post_id, meta_key and meta_value. For our table the only change is the name of the second column. Instead of ‘post_id’ our column will be named ‘product_packages_id’. See the pattern? Taxonomy key + ‘_id’.

Instead of providing the exact SQL CREATE TABLE command I am only going to suggest you copy the wp_postmeta table of your current site.

My reasoning for not providing the SQL CREATE TABLE command are I don’t want some people to take this literal SQL command and breaking their system then blaming me.

Copy the table structure only and name the copy ‘wp_product_packagesmeta’. Then edit the table structure and rename the second column from ‘post_id’ to ‘product_packages_id’. Once you have the table created and ready you need to tell WordPress where to use it. In the init function ‘product_init’ we need to make two changes. At the top inside the function add the line ‘global $wpdb;’. Then at the very bottom of the function add the line ‘$wpdb->product_packagesmeta = $wpdb->prefix.”product_packagesmeta”;’. your final ‘product_init’ function should look like this

Hope you enjoy this little tip. I’m already working on the next article which will build upon this one. The next article will show you how to customize the table list column when you list out the Product Packages items (see image below). Look for it soon.

WordPress Taxonomy meta listing

You can download all the code used in the article below:
codehooligans_wordpress_taxonomy_meta.zip

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

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.