Using Hierarchical Select/Content Taxonomy field in a Multigroup

HS does everything as right as it possibly could, AFAIK at least. So I'm assuming this is a limitation in Multigroup. If not, the Multigroup developer should provide an explanation for a work-around and move it back to the HS issue queue.

Hm … "To be deleted. To get Content Multigroup, go to the CCK project page, and wait for CCK3."

And you mention CCK 3.0. Moving to the CCK issue queue.

The module that implements the widget, if this widget manages their own multiple value fields, then the multigroup module requires the module to implement a couple of hooks. This is necessary because the widget itself could not be compatible with multigroups. Incompatibilites could arise due to the way the widget is implemented, or maybe because it does not really support form elements to manage single values, which is required in multigroups because each subgroup of fields needs a single value element in the form. The multigroup cannot store multiple dimensions of values, only one, which is keyed by delta, as any other multiple value field. The storage of fields in multigroups does not change.

For example, you cannot put checkboxes in multigroups. Well, yes, but the multigroup will switch them to be radios, because it is not possible to store more than one value per delta.

Here's an issue in the Content Taxonomy queue, which is where these multigroups where implemented for widgets on that module:

- #350669: Add support for the content multigroup module?

In summary, try to implement the multigroup hooks and check if everything works. If ok, then commit the hooks. If not, then let's look at which are the problems.

In any case, I think this is something that should be resolved under the context of the module that implements this widget. And I would say this is mostly a feature request, not a bug.

[EDIT] These multigroup hooks are documented in the README of the content multigroup module, part of CCK3.

Problem is HS supports both single and multiple values, while to be able to insert HS widget in a Multigroup row, it should support only single one. So proper patch to HS should consist of 2 steps:
1) Check that widget configured to single value
2) On success, implement multigroup hooks

It's also worth noting #520956: Add a new storage method for fields in multigroups. Once it will be implemented, this issue will become obsolete because Multigroup will support multiple value fields in a single row.

Well, I don't know which module/concept is really causing the problem (CCK Multigroups, Taxonomy, HS, or something else), but to me this sounds pretty annoying.

Multiple values are necessary to be able to store a term lineage. To support multigroups, HS' UI would have to be adapted to indicate that saving the term lineage will *not* be possible when using multigroups. Which will inevitably result in a boatload of support requests.

The issue crea refers to (#520956: Add a new storage method for fields in multigroups) seems to fix all these concerns. Hence I'd vote for waiting until that patch has gone in before making HS Content Taxonomy support Multigroups.

P.S.: I also don't think this is used very often, since this is the first time I've heard about it while it has apparently been developed at the end of 2008/beginning of 2009 … so all the more reason to wait for that patch to provide a consistent experience :)

@Wim Ofcourse #520956: Add a new storage method for fields in multigroups would be best solution for all. But there is one "small" problem: adding external storage method for a field is very complex task, probably impenetratable for any user who doesn't have deep knowlegde of CCK inner workings. Tbh, I doubt it will be implemented unless markus_petrux (who is CCK maintainer) himself works on it. So it could be implemented in a several months, in a year or not implemented at all. It's good target to follow, but in the meantime HS could have own solution.

Sure, it could. But I'm not going to maintain it. Yet another tiny feature that decreases usability, easy maintenance and overall code quality. Sorry, I got cynical over time.
Just having fixed #687170: HS + Taxonomy Defaults compatibility doesn't help in trusting CCK/Content Taxonomy developers more (just look at the diff …). Pity :(

Subscribing. It would be nice to have this feature.

Wim - I am willing to sponsor this. Please let me know what it would take to get it done. Thanks.

edit:
Still interested in this, in case anyone wants to be paid to develop it.

This is also very needed by me (http://drupal.org/node/877834#comment-3305578). I to am willing to give a bounty for the fix. Maybe zeezhao and i could combine the bounty?

@lasac I'm already in contact with zeezhao and he is no longer interested in sponsoring this feature, because he has no need for it anymore. If you're still interested in sponsoring this, please contact me directly. :)

subscribe.

For me the same error.

This change is not allowed. The field University / Institute handles multiple values differently than the Content module. Making this change could result in the loss of data.

Is there a reason that lineage couldn't just be serialized into one delta? I think I'm going to look at that approach. It might be easier to handle the storage and display of a serialized set of TIDs and automatically get multigroup support after implementing its required hooks. The HS module is huge, so I'm hoping it won't take me too long to figure out where all of this takes place. Or is the storage handed off to the content_taxonomy module? If storage and display are both handled by HS, then it shouldn't be too much of a pain to modify.

I have a client paying for this solution if I can find the answers in a timely manner. Wish me luck.

On further research, it looks like if one uses the "As hierarchical text" formatter, then one only needs to store the deepest term and not the whole lineage. At least, that is all my client needs since we'll be writing another module which processes the stored term and we can use HS's own functions to get the other terms in the lineage if needed.

So I think all I need to do is implement the hooks for multigroups and make sure that the 'save whole lineage' option is removed while in a multigroup. We'll see if there is anything else or not.

If a full lineage must be stored, it looks like content_taxonomy itself must be changed. Currently, it stores one value, an int, per delta. This would need to be changed to a text field. Fortunately, since PHP is loosely typed, it might be that most of the existing code can remain in tact. In other words, by simply changing the column type and nothing else, maybe the current functionality would all work. If so, then only additions and minor changes would be needed to add serialization storage. In fact, so long as the data that CT expects is the same, it could be that HS wouldn't even need to change, just add the multigroup hooks. Actually, if I implement the above idea, then someone later does this serialization idea, the only change needed to HS would be to take out my hiding of the 'save whole lineage' option.

Thoughts? I know I ramble when I work out a problem while doing a post. Sorry about that.

In any case, I might not get around to the serialization stuff if I can get my client up and going without it.

rconstantine,
I am not yet good enough in Drupal/PHP to understand everything and help somehow (except testing), but I wish you good luck for your solution/patch!

For me displaying all hierarchy but saving of at least deepest term would be also something affordable, anyway it would be better than nothing ))

I'm stuck on the AJAX stuff. I can add a new multigroup row. Inspecting the html, I see that the old row's HS element retains its original hsid, which is good. On the new row, the new HS element gets its own hsid. Also, the first row works as normal until you mess with the second row.

What doesn't work is this:

1) Immediately after the second row is added, the first row is given the 'nojs' div, or rather, the 'nojs' div is not removed. I've tracked this down to Drupal.settings.HierarchicalSelect.settings[hsid] being undefined for the first row after the second row is added. I'm not sure what to do about that.

2) The second row's HS element sometimes has the 'grabbie', but not usually. I'm not sure why.

3) The second row's HS element doesn't work at all. Any change to the first drop down results in the 'Received an invalid response from the server.' message. The API suggests that PHP files not being included during the callback are to blame, so I wonder if all three of these issues mean that some HS routines aren't being run when multigroup adds a row which need to be.

I suck at jQuery/JavaScript when it gets this complicated so any help anyone can provide would be great.

As a side note, in order for this to work at all, lineages cannot be saved, but multiple values need to be. I set multiple to 1 but set save_lineage to 0. Anyway, I think if this module were to be configured such that a user without multigroups could have standard multiple values - i.e. the 'add more values' button at the top level of the node form - then i wonder if the multigroup issue would go away. In other words, I suspect the issues I'm having have to do with cck's ahah calls bypassing HS, not necessarily anything to do with multigroup specifically.

I'm attaching my whole module as a zip if anyone wants to try and help out. I'm also attaching patches to the two files I changed.

One more note -

My other idea to get regular multiple values working would need a change similar to what I did in hs_content_taxonomy.admin.inc. If you look at the patch, you'll see that I check to see if the field is inside a multigroup. If it is, I set $multiple_values to 1. One would just have to 'undisable' the normal CCK multiple values drop down, then check to see if it is set to more than 1 and similarly set $multiple_values.

So far, I didn't code anything to prevent people from selecting to save the full lineage, but I added a note to the field description. See the first change in the patch for hs_content_taxonomy.module. I figured since I know it has to be set to 'deepest only' I'd just be careful until I got this all to work, then go back and do a form_alter to enforce it. In other words, if "you" try your hand at this, don't worry about that setting for now. Just make sure you set it correctly.

Note that the main stuff that got this to the point I am now was all done in hs_content_taxonomy.module. In particular, in the function that builds the form element, I changed the references to $form to $element. This way we just build the element, and not the whole form again. And of course, the bottom of that file has the multigroup hooks.

@wim leers - if you read this, is there any way i might be able to get a flow chart from you on how hs works? Like I said, I think some functions don't fire when CCK does it's AHAH call, but I can't figure out which ones. If I knew the order things were supposed to fire off, that might help. Otherwise, I'm just going to have to stare at all of the code until it absorbs enough. I also wonder if you would know immediately upon trying my patch what to do to fix it. Please help if you can.

BTW, why save the lineage at all since you have the formatter that shows the lineage even when you haven't saved it? Doesn't that make the feature redundant, or is there a use case for it? I mean, HS has functions for finding the lineage's terms, so any third-party modules could use them if they need to know them, right? If lineage saving is truly redundant, then you could add multiple value support with and without multigroups. Alternatively, we could try and get content_taxonomy to store a serialized string instead of ints.

rconstantine,

after applying your patches, I confirm for me the same error:

"You don't have Javascript enabled. Hover for more information! But don't worry: you can still use this web site! You have two options:

* enable Javascript in your browser and then refresh this page, for a much enhanced experience.
* click the Update button every time you want to update the selection."

It appears after HS deepest term in the first multigroup.

I hope that Wim Leers would give you a hint to advance.

i tested the case i mentioned without multigroup involved. essentially it just means changing it so that multiple values is handled by cck core. i get the same behavior as i've outlined that i get with multigroups. so... i'm not sure what to even look at next. all this ajaxy stuff spins my head. i guess wim isn't around to chime in. i think i just need to know what fires off during a normal page load that isn't fired off when multigroup adds a row.

frustrating.

marking as active since i'm working on it.

i wonder if this might be similar: http://drupal.org/node/626260

another very similar thread is
"Combo field - group different fields into one": http://drupal.org/node/119102?page=1

@clashar - that's the thread that got multigroup to where it is now. that thread IS multigroup as found in cck 3.x. that's what i'm trying to get this to work with.

Subscriing. I have the same problem in exposed block:
Views 6.x-2.10
Content Construction Kit (CCK) 6.x-3.x-dev (2010-Jan-26)
Please find attached picture.
Because I use HS on front page, maybe I should replace HS with something simplier?
Thank you for reply.

@adpo: Any particular reason for not using the latest dev of CCK 3.x-dev (August 26, 2010) Adrian? Also, since you are using/testing the 3.x series of CCK, why not also use the latest 3.x-dev series of Views?

Care to try them and report back if you still have the same issue?

I have just disabled block caching under performance. So far so good. I will keep eye on this website. When this problem happen again I will update whole website. Unfortunately, this website is live, and everything is working ok, except this issue. Thank you for reply.

cck 3.x is good, i also use it in production. But views i would not use, modules that use views are not yet all converted so not all work.

I know that (thankfully not first-hand), but if we don't test end report to module developers so they can fix things and add support for Views 3, then it'll take a really long time before we move forward.

that's your point, i didn't read the whole topic.

did someone find any workaround?

I just thought if these issues could help:
http://drupal.org/node/812956
http://drupal.org/node/411074
but it actually would be without HS and even not sure if it would work with Multigroup

Lowering priority.

For HS to work in a multigroup, a separate widget (a clone of HS) will be needed, cause you can't move 'multiple values' setting dynamically between CONTENT_HANDLE_MODULE and CONTENT_HANDLE_CORE.
Please correct me if I'm wrong though..

See the updated project page:

Note: the Content Taxonomy module integration is no longer supported. Patches are accepted and committed, but the maintainer does no longer want to fix bugs with this integration. The reason is simple. It's a nightmare. It makes one suicidal. Content Taxonomy is rotten. It needs to die. Thank god it won't be necessary to port this functionality to Drupal 7