Closed (fixed)
Project:
Multiselect
Version:
7.x-1.x-dev
Component:
User interface
Priority:
Major
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
8 Mar 2012 at 05:50 UTC
Updated:
1 Dec 2012 at 14:20 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
okeedoak commentedI'm having the same problem.
Comment #2
okeedoak commentedThis seem to be the same as Widget broken when form validations fails
Comment #3
acolyte26 commentedI managed to get the widget broken issue fixed apply the supplied patch but still getting this issue.
Comment #4
spadxiii commentedThis doesn't seem to be a duplicate of #1101264: Widget broken when form validations fails which is about missing css/js. This issue is about losing the selected options.
I'm running into this issue right now and am looking for a (possible) solution.
Comment #5
spadxiii commentedI've made a little fix to get it working. Added an after-build where the html is rebuilt with the correct selection.
Not sure if this is the most optimal way
Comment #6
pierrepaul commentedPatch in #5 worked for me. Had to apply it by hand, but it might be a mistake on my side or because I had already another patch for multiselect.
Thanks!
Comment #7
alexweber commentedThanks for the great work! This has been committed in 8e8bedc.
Comment #9
tobiberlinJust a hint for people who may use this widget within a profile2 entity: profile2 fields are nested into an array named "profile_PROFILE_NAME" within the form_state array. So to make this work I changed the function in the above patch:
Comment #10
mwesthof commentedNote that the suggested patch breaks any hook_form_alter() or hook_field_widget_form_alter() implementations where the #prefix is also modified. As the patch causes the #prefix value to be refilled after the form post.
As this module 'relies' heavily on the form element's #prefix value, I'm unsure how to cleanly fix the addressed problem without being in the way of other modules wanting to add something to the #prefix value.