Jump to:
| Project: | Taxonomy Super Select (TSS) |
| Version: | 6.x-1.1 |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | sethcohn |
| Status: | closed (fixed) |
Issue Summary
Primary_Term works just fine. But if I add TSS, the "Primary Category" label and a drop-down select box are displayed -- except that the select box has no primary term categories displayed. It is empty.
Primary_Term works somewhat with the Formtweaker module. With Formtweaker, the Primary Categories appear as a filled select box (not empty, as with TSS), but not as checkboxes.
I need to use Primary_Term, but neither TSS nor Formtweaker appear to change the Primary Categories to checkboxes.
I can't tell if this is a PT issue or something else with those other modules, but it would be great if they all played well together. I'd appreciate any pointers on where to look, what to do, because my content form is very messy without TSS or Formtweaker :(
Comments
#1
On a suggestion that these modules are loading out of sequence, I played with their weights in the System table, but did not have any luck. PT still has the same behavior -- empty select box with TSS, and a filled select box that isn't recognized and modified into checkboxes by Formtweaker.
#2
I noticed this issue has been here for nearly a year and not even answered.
Is there any intention of fixing this issue?
Thanks
#3
In version 6.x, with Taxonomy Super Select the Primary Term select is empty.
And with #588166: Pending Patches for Primary Term module and TSS, it doesn't work, the select is empty.
any solution?
#4
I've attached a patch to http://drupal.org/node/588166
That will let it play nice with Taxonomy Super select. I haven't had time to look at formtweaker yet.
#5
That patch is bundled into a zip file at http://drupal.org/node/588166#comment-2389240
Can we pull the specific changes out into a true patch, so that code is reviewable separately?
#6
The patch for this was setting the weight lower then Taxonomy Super Select, which will be a problem because of #472668: primary_term needs to run after i18ntaxonomy.
#7
If that's the best solution, then this might need to be a joint fix with Taxonomy Super Select fix, which I'm thinking should have to run after i18taxonomy, for the same reasoning.
(Yes, we could just adjust their weight too... but that's rude without asking.)
TSS doesn't look like it's had an update in the while, though. Anyone home?
Moving this issue to that Project, and looking for someone to either say
"Yes, we'll do a similar fix for TSS for use with i18ntaxonomy like #472668: primary_term needs to run after i18ntaxonomy (and pick a slightly higher weight, so the weighting order is i18nT, then PT, then TSS)"
OR
Silence from TSS maintainers, in which I'll just make PT look for TSS being installed and adjust the weight if need be.
#8
I'll be glad to commit if someone submits a patch.
#9
I'll get you a patch... have to review and pull that code out.
#10
@sethcohn, We can just work together so we can each have a weight that works with each module.
So we can set Taxonomy Super Select to have a weight of 2.
And then primary term can have a weight of 1
#11
Just a thought... I wonder if there is value in creating a utility module that handles module weights, where you can set dependencies.
For instance, we can say 'module A has to run after module B', perhaps in hook_install(), or hook_update(). The new module would then shuffle the module weights accordingly, provided there are no circular dependencies.
Using this, we could make TSS depend on PT, while in turn PT depends on i18ntaxonomy and a few other modules it needs to run after.
#12
I believe this problem is solved with the new release of Primary Term. The reason it happened was because PT used to depend on generating it's widget option list from $form['taxonomy'] in the node forms. However, too many modules (Hierarchical Select, Content Taxonomy, and now TSS) alter that form element.
In the new 6.x-1.1 release, PT generates the option list from the database now, rather than depending on an existing form element that other modules like to play with or remove altogether. :)
I'm marking this as fixed from our end; re-open if anyone can still reproduce.
#13
Automatically closed -- issue fixed for 2 weeks with no activity.