Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
Tried the dev version but got the "invalid response from server" error.
Basically the title says it all - when I click "Preview" when editing content, the HS values reset back to default. They're applied just fine if I set them again before saving the node.
Comments
Comment #1
Wim LeersThe first problem should be fixed for you, or it could require this patch: #1160694: Received an Invalid Response from Server. Please start a new issue if neither of these fix the "Invalid response from server" error from you.
The title says it all indeed. Reproduced. Working on a solution.
Comment #2
Wim LeersI give up. There's some very weird stuff going on in Field API/Forms API, or both.
Either way, I spent over 3 hours on this with zero progress. My entire Sunday forenoon. Without any results. This will need either a contributed patch or some sponsoring.
Comment #3
Wim LeersAlso see this tweet plus my conversation with @fago: https://twitter.com/wimleers/status/105217706457968640
Comment #4
Wim LeersHere are fago's relevant tweets:
- https://twitter.com/#!/the_real_fago/status/105224499468828672
- https://twitter.com/#!/the_real_fago/status/105225652420087808
- https://twitter.com/#!/the_real_fago/status/105226717324521472
- https://twitter.com/#!/the_real_fago/status/105228781291180032
The annoying thing is that his tweets are actually broken: they're not linked to the tweets they reply to, hence a conversation view is impossible. So it's actually quite hard to read this if you're not looking at this through my Twitter timeline.
Comment #5
Wim LeersHere's an idea: sponsor fago to fix this :)
Comment #6
sunI'm pretty sure you could save yourself from most headaches by dropping the custom hierarchical_select_ajax() entirely and switch to a native #ajax callback instead. Core's AJAX framework already takes over the required form and form_state massaging for you.
Comment #7
Wim LeersAFAIK this is unrelated to HS' AJAX functionality, but it is strongly related to how #process works, when it is called, etc. Am I wrong here?
P.S.: thank you *very* much for providing your advice! :) It's much appreciated.
Comment #8
fagoI'm at the Drupalcon right now, followed by some days of visiting London - so I don't have much time right now :) though I'm happy to help with feedback / pointers where I can.
@#ajax: yep, if feasible that's definitely a good idea.
Comment #9
Wim LeersMuch appreciated, fago! :)
Let's talk about this after DrupalCon, then :)
Comment #10
michaelgiaimo CreditAttribution: michaelgiaimo commentedAppreciate you guys working on this. Truly remarkable module, no idea why Drupal wouldn't have something like this in core.
Comment #11
michaelgiaimo CreditAttribution: michaelgiaimo commentedAny progress on this?
Comment #12
Wim LeersI'm afraid not yet, no.
Comment #13
michaelgiaimo CreditAttribution: michaelgiaimo commentedHow do I go about sponsoring the fix?
Comment #14
Wim LeersI don't have any time left for this, I'm afraid.
Comment #15
Riyuzakki CreditAttribution: Riyuzakki commentedI fix it. Patch work for me. (7.x-3.0-alpha5)
Comment #16
RumpledElf CreditAttribution: RumpledElf commentedThat patch didn't work on the dev version ...
Comment #17
skizzo CreditAttribution: skizzo commentedpatch #15 applied to 7.x-3.0-alpha5 works for me. Note that I did not see the "invalid response from server" error, but still previewing resulted in the reset of HS values. Should the issue status be changed to "needs review"?
Comment #18
skizzo CreditAttribution: skizzo commentedOne side-effect of patch #15 applied to 7.x-3.0-alpha5 is that whenever I add/edit a taxonomy term to any vocabulary I see the following notice
Notice: Undefined index: #field_name in form_type_hierarchical_select_value() (line 827 of /var/www/drupal/sites/all/modules/hierarchical_select/hierarchical_select.module).
Comment #19
ncbezi CreditAttribution: ncbezi commentedThis patch fixed our problem and includes patch #15.
Please test it.
Comment #20
whitingx CreditAttribution: whitingx commentedThe patch in #15 worked well for me.
Thanks very much for this @Riyuzakki.
Comment #21
chriszero CreditAttribution: chriszero commentedPatch in #19 is working for me.
Comment #22
Taxoman CreditAttribution: Taxoman commentedTime to push it to -dev. With the current state/activity of this module, that will at least bring more feedback and confirmations.
Comment #23
Open Social CreditAttribution: Open Social commentedPatch from #19 works for me!
Comment #24
Nikit CreditAttribution: Nikit commentedFor patch #19 this code:
should be replaced by next for supporting 2 or more term fields in node:
Otherwise other term fields with HS will disappear...
Comment #25
seaneffel CreditAttribution: seaneffel commentedI'm escalating this issue because it both prevents users from completing tasks and it deletes users original data. The term reference fields are wiped after preview on both new nodes and old nodes. Sites with a moderation queue are likely to have moderators accidentally wiping users original term data without any warning or notice (unless the term ref fields are required).
The patch in #19 corrects the problem if there is only one term reference field using hierarchical select widget. But if there are two or more term reference fields using hierarchical select, then the second field again has its values wiped. #24 tries but does not fix it.
This issue has been open for 11 month!
Comment #26
seaneffel CreditAttribution: seaneffel commentedComment #27
viggo CreditAttribution: viggo commented#19 works for me. I have only one hs field.
Comment #28
peterx CreditAttribution: peterx commentedI applied patch in 19 and it fixed the problem with our single select in the form.
The patch also created the problem in 18 but at line 832.
I changed the if() to:
if (isset($element['#field_name']) and isset($form_state['values'][$element['#field_name']])) {
Comment #29
spcalpo CreditAttribution: spcalpo commentedI just wanted to reiterate that applying patch in #19, then manually editing to add changes from #24 (for multiple HS terms) and #28 (fix #field_name error) fixed this preview issue for me.
I am at work so no time to generate a new patch for this right at this moment, but hoping my experience may help the process of committing this fix. It's a useful one.
Comment #30
seaneffel CreditAttribution: seaneffel commentedOh boy, but it would be awesome if you could roll out a patch some time. Some of us ^^ have no ability to do that for ourselves!
Comment #31
acrollet CreditAttribution: acrollet commentedhere's a re-roll of #19 incorporating the suggestions in #24 and #28.
Comment #32
Sharique CreditAttribution: Sharique commentedHi acrollet,
I did tried tried your patch, but it is not working for me. I tried it 3.x branch.
Comment #33
hanoiiPatch in #31 doesn't work, I have serveral hierarchical select fields and once you preview them, although the values are not removed, if you change any hierarchical select fields that needs to update the hierarchy it removes every hierarchical select but one!
Comment #34
hanoiiI spent a considerable amount of time today trying to sort this and I think finally fixed it in a nice way.
Attached is a patch. This approach is completely different from the ones mentioned in this thread so it's a brand new patch, very easy to review as it only adds one condition to check if the preview button was clicked. The function that is prevented to be run from this check was clearing the data from the $form_state['input'] and that was wiping off the values for every element.
I don't think it's a bullet proof fix because the problem will still be there if the form is rebuilt by some other action, but for node's preview, this is a good enough fix.
I left this thought on the code as well:
Comment #35
hanoiiComment #36
acrollet CreditAttribution: acrollet commentedComment #37
hanoiiRight sorry, missed the proper state, needs review is what I was going for. Thanks
Comment #38
Sharique CreditAttribution: Sharique commentedThanks hanoii,
This works for me. Although this patch failed to apply, I've to manually do the change.
Comment #39
hanoiiPatch is against the 7.x-3.x-dev, it fails for 7.x-3.0-alpha5, I recommend using -dev anyway, if you looked at the commits there are a few bugfixes that better having them than not, and considering this module is not very active lately, alpha should be as good as dev.
Comment #40
zet CreditAttribution: zet commentedhanoii , strange, but it looks like there are some issues with some whitespaces on your patchfile ?
patch is applied only using "--ignore-whitespace " :
But once applied, I can confirm the node preview work as supposed, without loosing term reference values.
Thanks
Comment #41
hanoii@zen, it's a simple enough patch created with git diff -w (to ignore whitespace), have you tried to apply it against the dev version?
Comment #42
zet CreditAttribution: zet commentedYes hanoii, it's applied against latest dev version. Maybe that -w it's the problem. If you edited the file on windows u should use something like dos2unix command against the edited file, before making a diff patch.
Comment #43
hanoiiaha, well not on windows. I checked and you were right, something was off with the patch, attached is a tested one against latest codebase. This one works for alpha5 as well.
Comment #44
Aljullu CreditAttribution: Aljullu commentedPatch #43 works for me. Thank you!
Comment #45
richsky CreditAttribution: richsky commentedWell, what about revision and the view changes button (seems to act as the preview button)?
Adding
|| $form_state['triggering_element']['#value'] != t('View changes')
Doesn't do the trick...
but
&& $form_state['triggering_element']['#value'] == t('View Changes')
Does.
I guess in case of View Changes, the last submitted values apply.
Comment #46
WIStudent CreditAttribution: WIStudent commentedPatch #43 works for me too. I applied it to the current 7.x-3.x branch.
Comment #47
jessehsThis patch adds the "View changes" button as one that prevents a rebuild. This button is provided by the Diff module.
Edit: Patch at the top of the issue in the "files" section. It's not actually attached to this comment, although it's named with this comment number (47).
Edit 2: oh, well it is attached now. Funny.
Comment #48
stefan.r CreditAttribution: stefan.r commentedThis patch needs a re-roll against HEAD
Comment #49
stefan.r CreditAttribution: stefan.r commentedComment #51
stefan.r CreditAttribution: stefan.r commented