I have a form with a field which can handle unlimited values. ( the one with 'Add another item' button )
When I add another item, the magic ajax of HS content taxonomy field works no longer :(

When I select to create new term, nothing happens.
When I click Add button to add a term to the list the error is:

warning: Invalid argument supplied for foreach() in C:\xampp\htdocs\sites\all\modules\cck\modules\content_multigroup\content_multigroup.node_form.inc on line 376.

This line appears in about 30 the same lines..

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

benone’s picture

I tried it again on clean and fresh Drupal 6.14 installation.

I have only 3 modules:

CCK 6.x-2.6
Content Taxonomy 6.x-1.0-rc2
Hierarchical Select 6.x-3.x-dev

I created 2 fields in new content type:

1) Simple CCK text field with Number of values: Unlimited
2) HS Content Taxonomy field with "Allow creation of new terms" option.

What's happening:

When I want to create new item in HS select field everything works fine. But if before that I ADD ANOTHER ITEM (next text field) in simple text field and after that want to create new item in HS field - nothing is happening. Small white window is not appearing anymore. I need to refresh the page to get it working again.

I didn't find similiar topic here so I once again checked everything and created this one.
If there is already a solution for this bug please put a link here.
Sorry if I duplicated the subject.

Wim Leers’s picture

Title: Creating new terms not working after adding another field to the form » Creating new terms not working after adding another field to the form through AHAH
Component: Miscellaneous » Code
Assigned: Unassigned » Wim Leers
Priority: Normal » Critical

Reproduced.

danylevskyi’s picture

Same problem. :(

jfolwarski’s picture

Is there any progress on what's causing this issue? I just ran into the same thing.

benone’s picture

Yeah, I use 29 conditional fields right now (Conditional Fields module) instead of one simple HS field just because of this bug.
Would be great to know if its going to be patched...
Thx

jfolwarski’s picture

Version: 6.x-3.x-dev » 6.x-3.3

I just realized this was set to 6.x-3.x-dev. I'm getting this on version 6.x-3.3.
Correct me if I wrong in changing this.

TonyK’s picture

Version: 6.x-3.3 » 6.x-3.x-dev

Subscribing. The problem still exists in the latest dev version.

rconstantine’s picture

This may or may not be related to my work here: http://drupal.org/node/677582#comment-3458336

I'm finding that when I add a new multigroup line, the first row no longer works. Were you folks getting any error messages?

DeFr’s picture

Status: Active » Needs review
FileSize
8.93 KB

I'm attaching a patch we've been using for some time to solve this bug and that I've just updated to make it apply to HS 3.5 and that seems to wokr fine.

High-level summary of what's going on, from what I remember (really should have posted the patch long ago when all this was still fresh, but well, better late than never I guess): the root of the problem is the numeric key index in the Drupal.settings.HieararchicalSelect.settings object ; when the ahah answers from CCK came back, there's something that tries to merge the current values with the one that are in the callback, and the fact that they are numeric makes the merger thinks that they're in fact anonymous, and then goes on and break the ids. That's why the patch includes those change to prefix them with the string 'hs-', which makes them string, and changes the merge behaviors.

There's also the bit about finding back the hsid from the posted value, that helped but still wasn't 100% quite right from what I remember, as it was called two times during in the ahah callback, and was thus both keeping our old element working, but also adding a new element that in fact wasn't on the page.

All in all, I don't think it's a perfect patch yet, but it's at least a step in the right direction. I'll try to find some time to polish it, but if someone's want to beats me to it, you're more than welcome :-)

Wim Leers’s picture

Could you please work on polishing this? It's a relatively big change.

And this most definitely needs reviews :)

Wim Leers’s picture

Status: Needs review » Needs work
Wim Leers’s picture

Status: Needs work » Closed (won't fix)

Closing due to lack of response.

DeFr’s picture

Assigned: Wim Leers » DeFr
Status: Closed (won't fix) » Needs work

Back to needs work...

I'll look into cleaning up the patch a bit, but honestly, even if the patch ends up not being on the right track, and unless the incompatibility between CCK's unlimited cardinality field and HS got somehow resolved another way in 3.7 (which doesn't seems to be the case according to a quick test), that issue should at least be active.

(It's not only the term creation that's broken, it's also the term selection that stops working.)

DeFr’s picture

Status: Needs work » Needs review
FileSize
1.54 KB

There you go for a patch that's hopefully easier to review. Now with 300% more comments explaining what's going on.

I'm not a fan of the early return $element, but I don't have much better for now.

borys’s picture

Hi! Thanks for the patch, that's partly fixed the problem.
But there is a problem with such earlier return $element;
if this code is present:
if (isset($_POST['hs_form_build_id']) && !isset($edit['hsid'])) {
return $element;
}
the new HS field don't adding throw AHAH (returns emtpy div) in my CTools Multistep Form.
If i remove that code, the HS element is added, but if i try to change the select value "Invalid response from the server" error is occurred. (previous HS field on the form is still working)
Have you any thought how to fix that?
Thanks!

stefan.r’s picture

Issue summary: View changes
Status: Needs review » Closed (won't fix)

6.x issue without activity for over 3 years, closing.

Please reopen if this is still an issue in 7.x.