Wouldn't it be cool if you could reorder the taxonomy display using CCK's manage fields UI? Well, now you can!

This makes the ordering of items much more intuitive since it's configured with the rest of the CCK fields.
I tried to create a pseudo field to move the settings into the display fields page but failed in the allotted time. It would be great if someone could step in and do this.
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | 705806-term-display-1.patch | 3.21 KB | psynaptic |
| #1 | 705806-term-display.patch | 2.66 KB | psynaptic |
Comments
Comment #1
psynaptic commentedHere is the patch.
Comment #2
joachim commentedVery cool indeed :)
Shouldn't this stuff only get killed if content.module is present?
I'm on crack. Are you, too?
Comment #3
psynaptic commentedYes, of course. Good catch :)
New patch attached.
Comment #4
nedjoThanks for the patch!
Rather than retaining the current weight handling, I'd prefer to remove it and use CCK's instead. So we would strip out not only the current form element for setting the weight but also all code that references those weight data.
An issue is that the current weighting approach provides a distinct weight per vocabulary (applicable to all content types), while the patch looks to provide a distinct weight per content type (applicable to all vocabularies). If we're switching to CCK, what we should have is both: a distinct weight per vocabulary per content type. So the hook implementation would look like:
For that we need an update handler to move over the existing settings. Something like:
And in the update handler we need to delete the exiting weight field.
Could the duplicate call to
content_extra_field_weight($node->type, 'term_display');also go in the update handler?Comment #5
psynaptic commentedThis looks great.
Do you know of a clean way in which we could add the display options as formatter options? They seem in essence the same thing: "display options".
Comment #6
skizzo commentedsubscribing.
Patch #3 solved also an annoying problem that I had with term display: although all my Display Styles were set to Custom with null weight, some Content Types were displayed with terms AFTER the Body while other Content Types were displayed with terms BEFORE the Body. After applying the patch I have been able to relocate all Term Display fields as needed.
Comment #7
skizzo commentedI think there is a problem with patch #3: I applied it and it seems to work ok, I then created a new vocabulary and realized that I could not set the "Display style" (it would stick to "Default" even after saving the change). Temporarily reverting the patch I was able to set the Display style to "Custom", I then re-applied the patch.
Comment #8
skizzo commentedI noticed another quirk. I have a content type with two vocabularies, before applying the patch the terms (custom, comma separated) are displayed after the body with the correct vocabularies weight order
after applying the patch, I can conveniently relocate the term display before the body, but as a side effect the order is altered
Comment #9
joachim commentedVery weird. Nothing inside the fields (or pseudofields in our case) should be altered by this.
Comment #10
skizzo commentedIndeed... this problem may not be related to the patch: I deinstalled the patch and created 2 content types with two comma-separated vocabularies each: [A (weight -10), B (weight -9)] ; [C (weight -8), D (weight -7)] all with display weight reported to be 0. After creating two nodes, the vocabularies are listed in wrong order
in teasers [B,A] [D,C]
in full node [B,A] [C,D]
i.e.: for second content type the order is even different in teaser/full-node. I am therefore reporting this as a separate issue. Anyway, after applying the patch I see:
in teasers [A,B] [D,C]
in full node [A,B] [D,C]
Comment #11
Andrew Gorokhovets commentedsubscribing.
Comment #12
eric.chenchao commentedsubscribe