When multiple HS widgets exist on the same page, and #process order != displayed order: Drupal's JS setting handling breaks HS

Does this problem also occur when you *don't* use that 'Field_conditional_states' module?

Yep, issue is present here. In addition, if you try select an item in this spooky repeat of taxonomy 1, you can no longer save or delete the node. This may be another issue. Will check into this.

Moving to active. I don't believe we are using the field_conditional_states module. I am also reclassifying this as 'major' as being able to use multiple vocabs on a node seems like reasonably important functionality.

I am also having this issue.
I also get a mysterious 'update' button appearing.

This issue is still present in the latest dev release.

As stated previously: with multiple HS widgets A, B, C, D... upon selecting a term in A, A becomes a duplicate of B.
Attached screenshots illustrate the progression.

(I partially don't believe my eyes, but I did get this to work w/o this set of errors once. Have not been able to reproduce)

I'm afraid I can't reproduce this. See the attached screencasts. The first is with one dropbox, the second is with two dropboxes (as that's the set-up that both both pearlbear and jenpasch have shown to be problematic).

Could you please export your HS configs, which will hopefully help to reproduce this problem? I doubt the HS config could cause this though, it's more likely there's an incompatibility with some other module. To export your config, you will need to track the head of the 7.x-3.x branch, or apply the following patch: http://drupal.org/node/1230972#comment-4787382.

Additionally, could you both post a full list of all modules that you're using? By intersecting these lists, we should be able to find the culprit (well, HS may well be the culprit here).

#1200522: Add Content: Hierarchical Select boxes change / disappear was a duplicate of this issue.

Subscribing (not confirming)

Doing a test conversion of a D6 installation with multiple HS widgets on a page (5+). I have seen instance where when trying to change one of the HS widgets for a node, it disappears completely from form while trying to select a level-2....

[edit] it then shows duplicate of a total different HS widget...

[edit2]
I am using the latest 7.x-3.x-dev of 2011-08-02
So issue is consistent with earlier postings on this thread e.g.#5, #7 etc.

screencast of the issue: http://dl.dropbox.com/u/2331397/HS_screen.mp4 (begins with some other weirdness that I encountered in config area)

I am working on getting an export of my HS config

@jenpasch:

1) "export" link not working: this was fixed a long time ago: http://drupalcode.org/project/hierarchical_select.git/commit/a38c390, as I already mentioned in follow-up #8. Please make sure that your menus are rebuilt.

2) "edit" link not working: this has always worked in D7 for me. Could you tell me what URL it links to? (Your screencast omits the address and status bars, so there's no way to tell.)

3) It looks like there's some module conflicting with Hierarchical Select. Because I *really* can't reproduce this. You've not provided *any* information that can potentially help with solving this problem. I've just created a screencast to show you that it really *is* working correctly here. Unfortunately, this screencast was pointless because it was largely the same as the one I already created for #8. (I remembered creating a screencast before, but I couldn't imagine that you didn't provide a screencast without any new information, so I started creating a new one that addressed all points of your screencast, to show that it works here.)
There are four ways to narrow down this problem:
- if we're lucky, disabling one of the tree module groups below fixes the problem (see bottom of this comment)
- zeezhao also posts a full list of modules he's using, we intersect them and can narrow down the likely culprits (I've pinged zeezhao for this)
- you reproduce this on a vanilla Drupal 7 install with only Hierarchical Select (and probably add modules until you've added the problematic module that conflicts with HS)
- you give me access to your D7 development site (including access to the code), so I can start debugging it in your environment, where the bug is actually reproducible
As long as I can't reproduce this, I can't solve this.

4) From the screenshot you provided, it seems you're still using alpha 2? The listed version numbers suggest this, as well as the fact that HS Menu and HS Taxonomy Views can be enabled. Attached is the screenshot of what it *should* look like. If you're still using alpha 2, then you didn't follow the instructions posted in #8. Even worse, you're using code that has known bugs that have been fixed since alpha 2.

Please update to the latest code, give it another try, and if it doesn't work, provide all requested information. This was unfortunately counterproductive.

I see that you're using Chaos Tools. Try disabling all of them for a minute, to see if that helps. Apply the same procedure to the "E Source" and "ES Event Center" groups of modules. After that, the obvious question is: what other modules are you using that execute JS code on the node/add/article page?

Updated August 8, 2011, 16:17 CET: some corrections.

Modules used so far on drupal 7.4 & 7.7, with HS 7.x-3.x-dev of 2011-08-02 are:
acl entity realname
faq references
advanced_help field_collection
auto_nodetitle field_group simplemenu
calendar tablefield
cck format_number
computed_field hierarchical_select token
content_access ldap views
content_taxonomy messaging views_bulk_operations
ctools nodehierarchy views_php
date notifications
diff
All are mostly latest 7.x dev versions.

We've now updated the code of the HS module on the development site, rebuilt the menus, and cleared the JS cache (JS caching was not enabled, however, so I don't think that was necessary).

The issue with multiple HS widgets on the Article content type is not occurring for me now, in Chrome, but is occurring still in Firefox, and a co-worker reported still seeing in Chrome (Chromium, to be specific). So we are not sure what are the precise circumstances triggering it.

As for the issue of the missing paths, it looks like it is because we have an Activity entity type which has a different admin path than what is assumed by the HS module: /admin/structure/types/manage/activity/fields/field_pubtype/widget-type is wrong, /admin/structure/event/activity/manage/fields/field_pubtype/widget-type is right. HS should look at the hook_entity_info() implementations when building the paths in hook_menu(). But that is a separate issue, so I will post it as such.

Also, it seems like the HS configs are not showing up on the config screen as being on the Node entity, just on the Activity entity. That also is a separate issue that I would have to look at another time, but probably not significant, since it doesn't seem to affect the functioning of the module.

I'll let you know when I've done more testing to see what are the particular circumstances under which this bug occurs.

I've attached the exports that I was able to get. One of the widgets didn't export - "Page not found".

While working on a follow-up patch for #1068366: Port "save lineage" functionality to D7 + support for multiple parent taxonomies, I accidentally managed to reproduce this problem for the very first time.

Apparently, the problem can only be reproduced in a very specific circumstance: when there are multiple Hierarchical Selects on the same page and the order in which they're processed (i.e. by Forms API's #process callbacks) differs from the final order on the page, because Drupal 7's new way of sending JS settings actually *erases* array keys, if array keys are specifically set (which HS does).

It's easily fixed by not using numerical identifiers, and simply switching to a string identifier, e.g. 1 becomes "hs-1". It's that simple.

Commit: http://drupalcode.org/project/hierarchical_select.git/commit/6d78d2c. If this doesn't fix it, then there must be another possible cause for this.

@EvanDonovan: regarding the incorrect links, please continue in #1127022: admin/config/content/hierarchical_select/configs generates incorrect links (should use field_info_bundles()) :)

Wim - thanks for your update and work to fix the issue.

I tried the new version of 2011-08-09 a couple of days, and it appears to fix issue. Will need to test properly once I have some more time. However, the other issue I noted as a side effect of this change is that if there is a validation error during node edit, or you do a preview during node edit, the js gets messed up and HS starts showing the "Update" button for each widget, which normally never shows - hence will be an issue with users..

Found another spot where the old setting key appeared, but this one is used only rarely, so it didn't affect most people. Fixed: http://drupalcode.org/project/hierarchical_select.git/commit/db03104.

Now using alpha3; appears this is fixed for us (PingV). I'll let you know if there are further issues.

Hurray :)

(Also: I didn't know you're working for PingV :))

Hi Wim, excellent workaround here.

I am experiencing a problem with couple of register block on a same page , where this register blocks of different profiles are on tabs , i am using madmatter module - http://drupal.org/project/profile2_regpath.

We are using hierarchical select for a field that is on 2 of 6 profiles on the register , when i activate hierarchical select widget on the field of one profile and also activate it on the field of the other profile, the hierarchies are not working on the two fields, it keeps loading the widget on the field, probably is because the js is handling on user_register_form and there are 6 user user register forms on tabs on the same page, so probably there is a problem with the numerical identifiers.

I have a test enviroment up.