First, I'd like to congratulate your work. It's almost unbelievable the progress that we had in 2 days of your dedication on this module. Thank you very much!

Now a request (and I really don't know if I have to put it as a bug or a feature, since it's working but not in a good way)...

When displaying the node, the values of field are not ordering like the tree I planned before. Got bizarre orderings like 1-3-2 or 2-3-1 for a 3-level taxonomy tree, I don't know what is the standard (if there is one). Would it be possible to orderer the output to something like 1-2-3 or 3-2-1?

Thanks again!


Wim Leers’s picture

Status: Active » Postponed (maintainer needs more info)

I'm not sure what you mean here… I think you're talking about term weights? If that's the case: yes, the weights are respected and that will not change.

Please clarify using one of the trees listed at the bottom of this page:

Vuds’s picture

No, it's really about the tree ordering. A example using your vocabulary:

Aston Martin
-Vanquish S
-3 series
-7 series

Let's say I choose BMW -> 3 series -> 325i (saving the lineage) and send it. When I go to view the node (display, whatever, but not editing), it shows me something like that:

3 series (2nd level)
BMW (1st level)
325i (3rd level)

I think that a common sense to be expected to display the data would be:

BMW (1st level)
3 series (2nd level)
325i (3rd level)

If I put the dropbox to choose multiple lineages, it mess all between lineages too!

Wim Leers’s picture

Status: Postponed (maintainer needs more info) » Closed (won't fix)

The display of that data is un-hierarchical by default. It just orders them alphabetically... You'll have to fix that in the theming layer, I'm afraid. Or use a content_taxonomy CCK field and write a new (better) formatter.

Vuds’s picture

Hmmmm ok :/

Just a correction, it may not to be alphabetical... in one test of mine, a location field, I'm getting "Buenos Aires" (2nd level) displayed before "Argentina" (1st level).

I started thinking about a solution using computed field... If I get any conclusion, I'll post here.


Wim Leers’s picture

That's probably the term weight kicking in.

Using the computed field to solve it would be the wrong place to fix it, IMO, but I can understand you prefer that.