Iain Urquhart


Taxonomy v1.2 released, some notes & handy tips…


Just pushed an update to the Taxonomy module and thought I’d write a post to outline some of the new features and also share a couple of development tips.

I keep surprising myself with how flexible it really is on some pretty complex builds I’m working on. It’s ‘play nice’ approach with the EE pages module is really making it something special.

Taxonomy is now entry status aware

Previous versions of Taxonomy would output whatever nodes you had on your tree, regardless of the status a particular entry that was attached to a node. Version 1.2 brings some nice functionality to have nodes & entire branches hide/show depending on entry status.

In the control panel you now get indicators which show if an entry attached to a node has a status other than Open. (Hat tip to @brandonkelly for setting the standard on the Playa UI.)

Status Indicators

The taxonomy:nav tag now has an entry_status parameter which allows you to restrict the menu output based on the statuses you specify. Handy stuff really, especially since you don’t have to delete an entire branch if you want a section of your menu hidden temporarily.

Getting fancy

Another new feature is the new node_active_class parameter for the nav tag. At first this might seem trivial, but the reasons behind it might be an eye opener for folks using Taxonomy.

Here’s an example of a menu I’ve recently implemented.

{exp:taxonomy:nav tree_id="2" node_active_class="active_parent" entry_id="580" depth="1"}
<a href="{node_url}">{node_title}</a>
{if node_entry_id == "580"}
{exp:channel:categories channel="tnz_activity_operators" parent_only="yes" style="linear"}
<li{if segment_4 == category_url_title} class="active"{/if}><a href="{path=things-to-do/activities}">{category_name}</a></li>

You’ll see here I’m actually outputting an EE categories list, within my Taxonomy tree, pretty cool stuff right?

By using a simple conditional in the tag pair, I’m checking for the node attached to entry_id 580, and then outputting the native EE categories tag.

I’m using the node_active_class parameter to apply an ‘active_parent’ class to the active node instead of the default ‘active’ -  my css / active states are inline with other areas of the Taxononomy tree that have children…

Taxonomy Custom Fields

I recently helped someone on Devot:ee who was asking how to create virtual nodes in the tree. Nodes which don’t contain hyperlinks but are simply output in the nav as the labels wrapped in spans.

This was pretty straight forward using Node Custom Fields. I suggested a new custom field of a checkbox type, with a short name of is_virtual. Then in the nav tag, simply check for the virtual value and disco, virtual nodes are added to the tree:

{exp:taxonomy:nav tree_id="1" entry_id="{entry_id}"}
    {if is_virtual}
<a href="{node_url}">{node_title}</a>

It’s surprisingly simple once you know how :)

Pages module integration

Whilst this is not a new feature for Taxonomy - I’m finding that we’re using Taxonomy’s pages module integration more and more. The way Taxonomy handles this has proven to be extremely useful. I’ve recorded a quick screencast below to show how the module interface responds to entries that have page uris associated with them.

And yep, when you select ‘Use Pages Module URI’, Taxonomy will keep itself up to date if you change a pages URI, or rename a template etc.

Saying that, if you want to display entries the ‘native’ way through url_titles too, Taxonomy handles that really well. Take a look at my software section, you’ll notice all the sub pages are being piped through the /software/docs/ template - with each entry displayed via the entry’s url_title.

The taxonomy:nav docs is a good example of Taxonomy handling tiered static content several levels deep - check out that page’s breadcrumbs and dynamic navigation :)

Next up

Next item on the to-do list is user permissions within Taxonomy. As you may know, access to the Taxonomy module is an all or nothing affair. I’m planning on introducing member group controls to trees, and tree preferences so you can sleep easy at night knowing your pesky client isn’t fiddling where they shouldn’t be fiddling.

I’m still fleshing this part out in my head, got a fair idea of what areas need permissions applied but feel free to chime in the comments and let me know your ideas.

Wygwam integration is also coming, look out for a new extension coming to a Devot:ee near you :)

Comments for this entry

Nuno Albuquerque
2011 02 27

Outstanding work Iain, this is the one thing that kept me from using this extension in fear of confusing clients. Thank you!

Nuno Albuquerque
2011 02 27

Do you have any plans of doing the reverse syncing with the pages module? So when the Taxonomy tree is reordered it updates the entry’s pages_uri automatically?

2011 02 27

I don’t have any plans to go there, it would be quite a complex task to pull apart the serialised array of site pages and start tweaking the segments. I think the results also might lead to more complications than it’s worth.

Personally, I get clients to enter segment_1/segment_2 as the page_uri regardless of how deep an entry is in the tree. For example /about/foo could be 5 levels down.

This way if a page is moved we don’t have to worry about having a bunch of new urls and losing page rank etc. Folks tout having urls that fully represent where a user is in the tree as an seo benefit - while that might be true, what happens when a branch is moved? All those old urls are gone and there won’t be 301s in place unless a developer manually creates them.

The key benefits of doing it this way are nice and short urls which don’t change + keeping it simple for the client when entering the uri. There’s lots of room for user error once you start going past a second segment with the pages module.

↑ Back to top