Problem:
Using preview resets the HS-taxonomy field.
Detail:
Preview uses form rebuild ($form_state[rebuild] = true). If form rebuild is activated, the function "form_hierarchical_select_process" is called twice. First time calling hierarchy is drupal_process_form > form_builder > form_hierarchical_select_process (-> $element is generated correctly). Second time calling hierarchy is drupal_rebuild_form > form_builder > form_hierarchical_select_process (-> $element is generated with empty default values). Second call overwrites first call, therefore the generated element is empty.
Is there anybody who can confirm this? Or is there any related issue I didn't saw?
Comments
Comment #1
spcalpo CreditAttribution: spcalpo commentedI can confirm this is occurring with latest version of Hierarchical Select.
At least now I know why it's happening!
Comment #2
robinvdvleuten CreditAttribution: robinvdvleuten commentedI can confirm this too. Is there already a solution found for this?
Comment #3
robinvdvleuten CreditAttribution: robinvdvleuten commentedDoes it maybe has something to do with the caching on the javascript side?
Comment #4
robinvdvleuten CreditAttribution: robinvdvleuten commentedI found out that I can fix it with an own process function called before 'form_hierarchical_select_process', where I unset the #value property of the element array.
Comment #5
skizzo CreditAttribution: skizzo commented@robinvdvleuten: could you please post a patch to that purpose?
Comment #6
robinvdvleuten CreditAttribution: robinvdvleuten commentedIt isn't a patch for the module itself. I wrote a function for my form where I unset the values;
The function is added in the config array of my hierarchical select like this;
It looks like the module is tricked and thinks that it has to re-render the hierarchical select dropdowns.
Comment #7
sokrplare CreditAttribution: sokrplare commentedThanks @robinvdvleuten - I was able to use your answer to help solve a different issue I was running into. Documented in #1843722: Form rebuild doesn't preserve input values or #default_value.
Comment #8
robinvdvleuten CreditAttribution: robinvdvleuten commented@covenantd Good to hear :) Does it also help for solving this issue?
Comment #9
operinko CreditAttribution: operinko commentedWe had this same issue when used with EntityConnect module.
When returning from a "child" node form, the values were reverted to none.
Commenting out the [code]drupal_array_set_nested_value($form_state['input'], $element['#array_parents'], array());[/code] in hierarchical_select.module (line 808) seems to fix the issue when used with EntityConnect.
I haven't noticed any adverse effects from commenting it out (yet).
If the maintainer could clarify why is that command needed in the code, or provide an alternative fix, I'd be happy.
Comment #10
Wim Leers#9:
Well, the clarification why that specific line is needed is just above the line that you commented out ;) It's a pretty extensive explanation; more than most other Form API black magic.
It's nice that this solves the problem for you, but that doesn't imply this is a structural solution. To come to a structural solution, you'd need to test whether this adversely affects other HS API implementations (especially the most used one: Taxonomy), in different configurations (i.e. with and without
save_lineage
, with and withoutenforce_deepest
; at least those 4 combinations). Besides that, you would need to research why this behavior was necessary in Drupal 7 and is no longer needed in Drupal 8.I know, that's a lot to ask for. But this is a deceivingly complex module on the inside, because Form API is not well-designed enough to support as complex form elements as Hierarchical Select. It's also the only way to prevent us from fixing one (narrow) use case and at the same time breaking many others.
Comment #11
operinko CreditAttribution: operinko commentedOk, we did run into some issues with that patch.
Occasionally, when deleting items from Dropbox, HS would decide to clear that specific dropbox completely.
To combat that, I made a new patch that makes sure the drupal_array_set_nested_values gets called on ajax requests only (when adding/removing items from dropbox).
It should be possible to make some extra checks for when JS is disabled, but Dropbox doesn't seem to work without javascript anyway (well, adding items atleast).
Comment #12
operinko CreditAttribution: operinko commentedRerolling patch, caused Undefined index warnings (why can't PHP just gracefully check for isset when calling for something..).
Comment #13
pjmuszynski CreditAttribution: pjmuszynski commentedNice and great patch. Especially if we need to use a Entity Connect module (or something similar). Thanks ;)
Comment #14
Wim LeersI don't understand why the weird checks in #12 would be necessary. If they truly are necessary, they need docs at the very least.
Comment #15
operinko CreditAttribution: operinko commentedAh, yes. The "weird checks" are indeed necessary.
The form gets rebuilt twice without those checks if used in conjunction with Entity Connect when adding/editing/removing entity references with Entity Connect, which effectively wipes out anything that would've happened to live inside the HS dropbox.
Now, if we do the form cleanup when HS Dropbox actually needs it (that is, when we're handling an ajax call from the dropbox), we can avoid a whole bunch of issues that arise with other modules.
Granted, there may be a better way to do that.
Comment #16
GoldIt's been 5 years since this was last worked on.
Is it still relevant?
If so, could someone;
Updated to Postponed until the "is it still relevant" question is answered.