I use hierarchical select ("HS") as widget for content taxonomy fields on nodes. I found that behavior, that HS "forgets" complete term path when editing an existing node.
Settings of hs are: "save term path linege" and "force deepest item"

For example: when I create a new node, I save "termA-level1 | termB-level2 | termC-level3".
When I edit that node later, the widget displays only "termA-level1" and there is no option of choosing deeper term-childs. If I choose another term at first level, I can choose deeper childs. Trying to save the node gives an error, as deepest term level is mandatory but HS only selects first level.

As a workaround I have to change level1-term. After that I can choose my original level1-term and than HS offers me children to choose from that term.

I tried both upgrade to HS 7.x-3.x-dev and I not to force deepest level. It is still the same behaviour. The danger of not forcing deepest level is that you forget your tagging information as drupal saves node only with first level tagged.

Has anybody got an idea?

Thanks in advance,

Members fund testing for the Drupal project. Drupal Association Learn more


beanluc’s picture

I second this, though in my case it's more like "HS forgets taxonomy term completely".

When opening a node for editing, the HS widget has no memory at all of whatever term, parents, whatever, might have been set in a previous save. The only thing that keeps my site from losing data is that this term is a required field, so, users are prompted to re-set the term every time they edit.

Memoskins’s picture

I have the same issue, anyone found how to solve this problem?

stBorchert’s picture

Version: 7.x-3.0-alpha5 » 7.x-3.x-dev
Status: Active » Needs review
7.05 KB

While working on the 7.x-release for Multistep Nodeform I ran into a similar problem. When restoring the form part containing the hs-element, its term path was lost.
I was able to fix this by doing a tiny change to _hierarchical_select_process_calculate_selections() as well as to _hs_process_determine_hsid() (see attached patch).
Maybe this fixes your problems here, too.

SteffenR’s picture

Status: Needs review » Reviewed & tested by the community

Hi stborchert - i just checked your patch / tested it on a site and it worked as expected.


Kars-T’s picture

+1 for the patch.

Wim Leers’s picture

Status: Reviewed & tested by the community » Needs work

Lots and lots of whitespace changes in this patch that make it harder to review than necessary.

rogerpfaff’s picture

correcting whitespace issues is as important as fixing bugs. it's just to keep up with coding standards I think.

Kars-T’s picture

Status: Needs work » Needs review
2.1 KB

Even if I support the whitespace changes I want this to be fixed and added a version without white spaces.

rooby’s picture

Issue summary: View changes
Status: Needs review » Needs work
+++ b/hierarchical_select.module
@@ -349,12 +349,18 @@ function _hs_process_determine_hsid($element, &$form_state) {
+    // Do we have a default value?
+    if (!empty($element['#default_value'])) {
+      $hsid = array_shift($element['#default_value']);
+    }
+    else {
     if (!isset($form_state['storage']['hs']['last_hsid'])) {
       $form_state['storage']['hs']['last_hsid'] = -1;
     $hsid = $form_state['storage']['hs']['last_hsid'];
+  }

In this case though the code in the else should be indented. We don't want to fix unrelated whitespace issues but we also don't want to introduce new ones.

Other than that it looks good, and from my testing it fixes the bug where hierarchical select field values are seemingly lost on edit.

rooby’s picture

Also, this patch introduces an error message on the widget settings edit form:

Warning: array_shift() expects parameter 1 to be array, integer given in _hs_process_determine_hsid() (line 354 of hierarchical_select/hierarchical_select.module).

Because of

+    if (!empty($element['#default_value'])) {
+      $hsid = array_shift($element['#default_value']);
+    }

$element['#default_value'] is not necessarily an array (or is it ever an array? I'm not sure).

rooby’s picture

1.85 KB

Also, the 3rd hunk in the patch in #8 is unrelated to this issue.

This patch fixes the issues mentioned in #9 & #10 and removes the extra hunk.

rooby’s picture

Status: Needs work » Needs review
Leeteq’s picture

Priority: Normal » Critical

Dataloss = Critical.

  • stefan.r committed 1e6ac93 on 7.x-3.x authored by rooby
    Issue #1585824 by rooby, Kars-T, stBorchert: when editing node HS...
stefan.r’s picture

Status: Needs review » Fixed

Committed, thanks!

stefan.r’s picture

Status: Fixed » Needs work

The patches in this issue break hs_menu. Reverting this commit for now.

  • stefan.r committed fa292fa on 7.x-3.x
    Revert "Issue #1585824 by rooby, Kars-T, stBorchert: when editing node...
stefan.r’s picture

Status: Needs work » Needs review
1.9 KB
stefan.r’s picture

Status: Needs review » Fixed

  • stefan.r committed 9656052 on 7.x-3.x
    Issue #1585824 by rooby, stefan.r, Kars-T, stBorchert: when editing node...

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.