These type of modules do not work at all well with Taxonomy Treemenu. They offer to display the Taxonomy Treemenu generated menus, but the results look broken, render none of Treeemenu's options, and the links do not work, being addressed to an enigmatic URL '?q=ttprnts/%'.
Aside from some specialised rendering, Treemenu offers most of the possibilites of these kinds of modules within it's generalised functionality. For example a designer can put a menu into a block, page a menu like this ?q=ttm/[menu-name] and so forth.
For the committed or interested user.
Treemenus base menus have links that look like this,
router_path: ttprnts/%
link_path: ttprnts/[tid]/[tid]/[tid] (describing the path to a term)
This is gobbledegook/nonsense to the Drupal menu system.
The module contains no 'loader' (handler) that could deal with such a link_path.
Niether could one be easily built
(in a conceptual sense, this is what the treebuilding part of the module does - read on...)
What is happening is that the link is being used to carry the vital data of the taxonomy hierarchy. Taxonomy Menu does much the same thing, but they carry the data in the Menu Router table, so using that module a user will never be offered the menus by accident - though of course, we have reasons for using our method, and they have reasons for their method (and I'm sure this issue is one of them).
Both modules, in their way, then reconstruct menus from this base data. Taxonomy Menu can use a couple of little tricks - historically, the module used hooks, but for some reason (performance? Lack of flexibiilty for user override?) they've cleared them out - a long job, I understand. Taxonomy Treemenu has here always taken the constructive route - it contains it's own clean and refined tree builder.
Anyway, that's why, if you see a Taxonomy Treemenu generated menu being offered for display through another module, e.g. SiteMap or Menu Block, the result will look bizzare and be unusable. The so-called 'menu' is data, and not intended as a functioning menu tree.
(Why doesn't Treemenu tag the links table with a new field to carry the data? Thus allowing the residual menu to have working menu data in the fields? To be honest, it's an unexplored option, and we might try that sometime. But this action is close to tampering with core, for one thing, which is against the grain of the module's principles, which are to bypass core when necessary, not tamper. And we'd want to do extensive performance testing to assure the maintainers there is no performance impact elsewhere in Drupal. There are also some complex, though interesting, conceptual issues and potential - see the module Taxonomy Lineage for a working demonstration of a feature with different ends yet a broadly similar approach.)
If you want to push term links through to custom items, without the fuss of a template, this does the job very nicely.
*** Warning 6x-1.3. It works well when you do it, but you can't go backwards! If you try to switch redirects off, you'll find any extended URL menus will keep reverting to stock URLs. You'll need SQL I'm afraid, some variant of,
UPDATE vocabulary SET module='taxonomy';or I think you can do the same thing through PHPAdmin ***
Here's the punchline. If you try taking the redirects OFF an extended URL menu, the URLs will revert to stock URLs. Unless you do the SQL fix above.
We claim to be blameless for this...