Hey,

I’ve been plodding away the last week or so on a new module called Taxonomy which I’d like to throw out to any folks that are interested.

Basically, its a navigation building tool which uses nested sets to control hierarchy. The class used is straight from the CI community (MPTtree) and that does most of the heavy lifting.

Unlike the Pages Module, uri’s are using regular template/url_title paths - so the uri /about/whatever/ could represent something 10+levels deep in the Taxonomy module.

This is an early release, tested in a narrow environment, there will be bugs and some munty code around; I’m using this to learn PHP & CI development so if any devs want to lend a hand - feel free!

Screencast of module interface (updated 3rd June 2010)

Documentation & Download is here

Changelog

GitHub Repository

Iain,

I just took a look at the screencast and like the concept very much. Do you have any plans of introducing a dedicated tab in the Publish Entry page to improve the workflow?

Looks cool keep up the good work.

Nice work, this looks really promising!

This is one of the times when site admins will want to give this its own tab in the main menu. Very nice work!

so good, exactly what I’ve been needing! Great work!

Danny Tam (mr_dimsum) - 12 April 2010 03:59 PM

IDo you have any plans of introducing a dedicated tab in the Publish Entry page to improve the workflow?

Yeah, it’s on the todo list.

I’ve actually got a version of the tab file which does work, it offers 3 fields: Menu Label, Parent, and template.

The issue here is, that trees can be made from entries derived from multiple weblogs… and you can have multiple trees!

So options are to create a fieldtype which will have some sort of tabbed interface that lets the user insert the node into whatever trees are available, or introduce a setting for ‘primary weblog’ per tree and have the tab function only available from that weblog.

Its a tricky one to explain, and I’m still figuring out the best approach. Any ideas/suggestions welcome!

Thanks for the interest in the module

Just updated to V0.2, couple of new tags added,

exp:taxonomy:node_url Outputs the url of the node as defined by Taxonomy.

exp:taxonomy:get_children_ids Outputs entry_ids of the immediate children of the specified node, and seperates them with a pipe for passing through to channel:entries tags.

All parameters are required.

Hey Iain,

I’m playing around with your module and wondered if on line 2323 of mpttree.php you might want to test for the existence of $data[‘url_title’] and if not present, use $data[‘label’] instead (but obviously modified to replace spaces with underscores and lowercase it etc etc)? That way if my node is just a template and not a template and an entry i still get a unique classname for my menu item.

Anyway it seems pretty cool thanks, i’m having a good play with it and it’s pretty sweet. It’s certainly a nice way to build menus and i think having a tab would be a great addition to this module and make it easy and logical for end users to build menus (certainly something i haven’t felt any other solution does satisfactorily)

I look forward to future releases!!

Thanks @audiopleb, I’ll add that for the next release.

Just incase anyone is having the same issue as me when displaying children nodes using the exp:taxonomy:get_children_ids method described in the docs example, it looks like EE2 bugs out with an sql query error if you pass an empty fixed_order=”” parameter to exp:channel:entries

You need to run a conditional to make sure the id’s exist before calling exp:channel:entries to workaround for now.

UPDATE: The issue has been fixed for the next release of EE

Iain, No problem, i think you’ll want to use the url_title() function from the url helper on the label to make it css class friendly! (if you didn’t already know that of course!)

Also i think another thing that would be cool is if the output could be modified, for example if someone wanted a different type of html output they would have to modify the class directly. I know this is easier said than done but perhaps it might be something for the future!

Anyway, great work, it’s a real peach of a module for me.

New version is up with your request @audiopleb for unique classes when no url_title is present.

also, new tag for fetching sibling entry_ids, and the documentation is getting more complete.

iain.co.nz/taxonomy

I just tried to install this and got the following error

I’ve put my system folder above my public root folder, so that may be the cause somehow.

Hi Craig,

Sorry I can’t be of much help on this as I’ve never configured EE to be above the root, and given that this is a beta product being tested on a beta platform, I’d say the chances of getting a fix/workaround soon are pretty slim…

There’s images and javascript in the module that will need their path references updated if you’re going to be doing that, I’m planning on adding a preference to set where they are retrieved from so maybe after that’s established, I’ll look at the issue above…

That is unless any other developers chime in on what’s needed to get what you need,

cheers.

Thanks iain.

I see also that the notes on EE202 suggest that any modules dependant on the pages module may have issues that will need to be addressed by addon developers. Hope that doesn’t mess things up for you too much.

Craig

Craig Allen - 16 April 2010 09:00 AM

I see also that the notes on EE202 suggest that any modules dependant on the pages module may have issues that will need to be addressed by addon developers. Hope that doesn’t mess things up for you too much.

Not at all Taxonomy doesn’t use page uri’s the same way the Pages module does, it uses regular template/template_group/url_titles so it’s unaffected.

I have had a feature request to have the uri’s stored using the Pages method, but I’m yet to be convinced of the benefits. I’m not getting too hung up on the uri not reflecting how deep the user is in the site at all. It’s more the interface’s job to communicate this to the user in my opinion.

From experience with the pages module, in some sites I built the uris have gotten ridiculously long.

Plus, this way it’s more ‘native’ allowing you to pass extra segments without breaking the url and having to use workarounds. And, moving a node doesn’t change its uri, and won’t result in broken links on your site.

Any thoughts?