Yes, it’s only been a short while since I released the first version of the Custom Taxonomies Menu Widget, but thanks to some great enhancement suggestions from a user (read the relevant WordPress forum post), I thought I would strike whilst the iron was hot and put out an upgrade.
Version 1.1 adds a couple of new options to the widget control panel, which you will see when you open up the Custom Taxonomies Menu Widget Control panel in the Dashboard > Widgets screen.
One new option allows you to suppress the Taxonomy name from being shown above the list of its Terms. The other new option allows you to select whether or not to show the list of Terms in their hierarchy.
Version 1.1 Information
Requirements
- Requires WordPress version: 2.9
- Tested up to WordPress version: 3.0.1
Changelog
- Released 5 November 2010
- Feature: Added option to hide Taxonomy title
- Feature: Added option to select whether or not to display terms as a hierarchy
Resources
And finally…
If you need support, please post a question on my forum. I rarely monitor the WordPress.org forums, so you are guaranteed a quicker response by posting your question on my site. Thanks!
Hi,
Love this widget but, it would be even better if you could enable it in some way so that al child taxonomies were automatically selected when selecting a parent taxonomy. This would/ could mean then that if you added a new child, this would automatically get added to the output of the widget?
I am using it to list places in a region to walk from and if it was automatic i would not have to remember (or keep forgetting as the truth is!) to tick the box in the widget.
Can you help?
Many thanks
Mark
Hi Mark,
Thanks for the comment.
You’re quite right – it’s irritating having to go back and check new child terms, etc. Fixing this is on my to do list.
Actually, Mark, now that I’ve spent time working on this, I’m not sure it’s a correct approach – despite my initial enthusiasm for it.
A few reasons:
It will introduce a few more database queries which will have a performance impact on the front end. (Not a huge impact, admittedly, but I like that this type of plugin has a light footprint.)
There will be a synchronisation issue between the menu on the front end and the checked list of terms in the widget option form. This is partly due to the fact that the plugin would need to differentiate between newly added terms that the user wants to consider as “checked”, as opposed to existing terms which the user has already decided should be unchecked.
For example, let’s say a user has one custom taxonomy with three terms. The user selects the various options in the widget control panel, including checking the taxonomy box and the checkboxes for the three terms, then clicks Save. As expected, the user will see the three terms in the widget in the sidebar (for example). Now, let’s say the user then creates a new term in the Dashboard, but doesn’t visit the widget page. When the front end is loaded, the plugin would need to compare the actual number of terms in the database with the terms that were “known” about when the widget page was last visited, and then add the “missing” term to the front end menu. Ok, all well and good…
However, when the user next visits the widget form, the new term will appear unchecked. It cannot appear checked because the front end display pulls stuff from the database (ie the widget’s options/settings), it doesn’t update the database. At this point the user is probably rather confused – “Do I want to check this term, or not? Or is there a bug?”. I, for one, would expect that if it is visible on the front end it should be checked in the widget form, and many users will probably agree with me.
A further consideration is this: not all users will want to have a new term automatically added to the menu. Many people use custom taxonomies as an internal cataloguing system, rather than a way to publicly view a term archive, for example. These people would definitely hate any automatic system!
So, on balance, I’m probably going to leave the existing functionality as is. However, having spent a lot of time working up the code to do automatic term inclusion, I may add the code and provide users an option to use it or not from within the widget form. We’ll see…
Anyway, thanks for raising the whole issue. A few people have made the same request as you in the past, but this is the first time I’ve sat down and spent time looking at how to do it. Now that I have, and even though I’m against adding in this functionality, it was a useful exercise nonetheless!
Happy New Year!
Scratch everything! I decided to implement the auto “add new terms” after all.
See Version 1.2 which has just been released.