I am using the patch in #1694940: Edit individual fields for a node in a block. to expose editable field forms via formblocks.
The issue I am running into is that if I expose multiple editable fields, specifically textareas, I run into some strange behavior if I edit two textareas without refreshing the page.
To reproduce create a node with two textareas and expose this with formblock & editablefields.
- Edit one textarea and click outside the textarea
- The text is properly updated
- Edit the second textarea and click outside the textarea
- The text in the first textarea is reverted prior to edits in step 1, the changes to text area 2 are save
- Regardless of steps the changes for textarea 1, will constantly be reverted.
This procedure can be reversed to edit textarea 2 first and the behavior is the same, with the exception that none of the edits for textarea 2 will be saved.
This appears to be a result of the $entity as saved to form_state['editablefields_entities'][$element['#entity_type']][$element['#entity_id']]
and used in editablefields_form_submit().
The attached patch resolves the issue for us and results in both textarea's edits being saved properly.
Comment | File | Size | Author |
---|---|---|---|
editablefields-stale-entity-in-form-state.patch | 623 bytes | jgraham |
Comments
Comment #1
jgraham CreditAttribution: jgraham commentedI just double checked on editable fields without using the afforementioned formblock patch and this error manifests itself if you repeat the process by making two textareas editable and then repeating steps 1-5 in the initial ticket.
Comment #2
bradjones1Elegant one-line fix, and it works for me. I think it's ready for RTBC, but don't want to step on maintainers' toes...
Comment #3
MegaChriz CreditAttribution: MegaChriz commentedI've posted a similar patch for this problem in #1784160-10: Browser-side caching of ajax callback values in Firefox causes inaccurate display of values.. That patch checks if the entity ID is known (you don't want to (re)load an entity if it doesn't have an ID).
I'm not sure if this issue or the other should be closed as a duplicate, because the initial problem described in the other issue could be different.
Comment #4
Taesto CreditAttribution: Taesto commentedThanks for the patch, looks like you solved my issue
http://drupal.org/node/1872256
Why is this not committed yet?
It was very strange when field changes were mysteriously disappearing.
Comment #5
lklimek CreditAttribution: lklimek commentedPatch #1784160-15: Browser-side caching of ajax callback values in Firefox causes inaccurate display of values. looks a bit better than the one here, but essentially addresses the same issue.
Comment #6
joelpittetWhile applying this patch I realized we've committed a similar fix in another issue. Closing this one. Thank you for your patch and testing this issue.