Simply Exclude plugin version 2.0…finally!
Filed Under: Tags: Beta, plugin, Simply Exclude, WordPress
I’m formally announcing the release of the first best of the popular Simply-Exclude plugin. You can download the beta version plugin from this site below.
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:
- 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.
- 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!
- 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.
- 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.
- 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.
- 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.
- 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.
Pages-Children 1.5 released
Filed Under: Tags: hierarchical, plugin, post types, taxonomies, WordPress
Over the last week I’ve released 3 versions of my popular Pages-Children plugin.
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
Out of 1000 WordPress plugin developers I’m now ranked 372!
Filed Under: Tags: plugin, ranking, WordPress
Thanks to W-Shadow for putting together this nice page, http://w-shadow.com/files/top-1000-plugin-authors.html.
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.
Adding Custom Meta Headers To Taxonomy Table Columns in WordPress 3.0
Filed Under: Tags: headers, meta, plugin, taxonomy, WordPress
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.
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.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 | add_action( 'init', 'product_init' ); function product_init() { register_taxonomy( 'product_packages', 'products', array( 'hierarchical' => true, 'label' => __('Product Packages'), 'query_var' => false ) ); // Added from Part II. // This filter sets up a call to your function which will handle // adding (and removing) items from the columns array. This // filter passes up only one argument. The array of default headers. add_filter( 'manage_product_packages_columns', 'admin_product_packages_column_headers, 10, 1); } // Add this to your code's init function. This filter passes up // only one argument. The array of default headers. add_filter( 'manage_product_packages_columns', 'admin_product_packages_column_headers, 10, 1); // Add this function somewhere else in your plugin or functions file. function admin_product_packages_column_headers($columns) { // We are going to create a new array to hold the headers. // Below we take the checkbox column and the name column // and add to the new column array. Removing unwanted columns // and adding new one is trivial. The below method has // room form much improvement. $columns_local = array(); if (isset($columns['cb'])) { $columns_local['cb'] = $columns['cb']; unset($columns['cb']); } if (isset($columns['name'])) { $columns_local['name'] = $columns['name']; unset($columns['name']); } // We add the Package Active to the second column if (!isset($columns_local['product_package_active'])) $columns_local['product_package_active'] = "Active"; if (isset($columns['posts'])) $columns['posts'] = "Used"; $columns_local = array_merge($columns_local, $columns); if (!isset($columns_local['product_package_unit_price'])) $columns_local['product_package_unit_price'] = "Price"; return array_merge($columns_local, $columns); } |
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.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 | add_action( 'init', 'product_init' ); function product_init() { // From Part I register_taxonomy( 'product_packages', 'products', array( 'hierarchical' => true, 'label' => __('Product Packages'), 'query_var' => false ) ); // Added from Part II. // This filter sets up a call to your function which will handle adding (and removing) items // from the columns array. This filter passes up only one argument. The array of default headers. add_filter( 'manage_product_packages_columns', 'admin_product_packages_column_headers, 10, 1); // This filter sets up a call to display the contents of a Product Package row column. // The filter passes up 3 argument. We only use the second and third arguments. add_filter( 'manage_product_packages_custom_column', 'admin_product_packages_column_row', 10, 3 ); } // This function we check the column name then pull in the row data using get_metadata() function admin_product_packages_column_row( $row_content, $column_name, $term_id ) { switch($column_name) { case 'product_package_active': $product_package_active = get_metadata('product_packages', $term_id, 'product_package_active', true); if (!$product_package_active) $product_package_active = "yes"; return ucfirst($product_package_active); break; case 'product_package_unit_price': return get_metadata('product_packages', $term_id, 'product_package_unit_price', true); break; default: break; } } |
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.
Disable WordPress Plugins update indicator for inactive plugins
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
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 | function update_active_plugins($value = '') { /* The $value array passed in contains the list of plugins with time marks when the last time the groups was checked for version match The $value->reponse node contains an array of the items that are out of date. This response node is use by the 'Plugins' menu for example to indicate there are updates. Also on the actual plugins listing to provide the yellow box below a given plugin to indicate action is needed by the user. */ if ((isset($value->response)) && (count($value->response))) { // Get the list cut current active plugins $active_plugins = get_option('active_plugins'); if ($active_plugins) { // Here we start to compare the $value->response // items checking each against the active plugins list. foreach($value->response as $plugin_idx => $plugin_item) { // If the response item is not an active plugin then remove it. // This will prevent WordPress from indicating the plugin needs update actions. if (!in_array($plugin_idx, $active_plugins)) unset($value->response[$plugin_idx]); } } else { // If no active plugins then ignore the inactive out of date ones. foreach($value->response as $plugin_idx => $plugin_item) { unset($value->response); } } } return $value; } add_filter('transient_update_plugins', 'update_active_plugins'); // Hook for 2.8.x //add_filter( 'option_update_plugins', 'update_active_plugins'); // Hook for 2.7.x |
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.





