issues with cck form [#207514]

I see various issues when using autosave with complex cck form; will try to post more info as i debug but for now just issues list:

GOOD: all fields seem to be captured in the autosave table correctly

Issues when coming back to edit a previously saved node:

- VIEW: some fields do not show the values from the table; they show as blank

- VIEW->IGNORE: or
- VIEW->RESET->IGNORE: somehow the value of one of the integer fields seems to get picked up as the new form_id and a new entry is now written to table with this integer value as the form_id (very strange).

more to follow

Comment	File	Size	Author
#2	autosave_cck_fields.patch	737 bytes	edmund.kwok

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Comment #1

liquidcms CreditAttribution: liquidcms commented 8 January 2008 at 04:47

behavior noted above is different for IE7 / FF.

- when VIEW and some of the fields do not show; more fields are blank under IE7 than FF

- when VIEW->IGNORE, only FF has issue of creating new bad entry in autosave table

Comment #2

edmund.kwok CreditAttribution: edmund.kwok commented 8 January 2008 at 05:16

Status:

Active

» Needs review

File	Size
autosave_cck_fields.patch	737 bytes

Hi Peter,

Try the attached patch; it resets the value variable that is used to recursively go through the autosaved form hash variable to obtain a autosave cck field's value.

It would be good if you can export the cck content type you are using so I can test it and debug as well.

Edmund

Comment #3

liquidcms CreditAttribution: liquidcms commented 8 January 2008 at 05:24

Status:

Needs review

» Active

more info.

I would guess the issues here are with the formHash function in jquery.field.js.

Using FF i observe 2 input fields on my form. the HTML for this looks like:

<div style="display: inline; float: left; margin-right: 15px;"><div class="form-item">
 	<label for="edit-field-word-count-0-value">Word count: </label>
	 <span class="field-prefix"></span>

	<input maxlength="11" name="field_word_count[0][value]" id="edit-field-word-count-0-value" size="10" value="716" class="form-text number" readonly="readonly" type="text">

	<span class="field-suffix"></span>
</div></div>

<div style="display: inline;"><div class="form-item">
 	<label for="edit-field-character-count-0-value">Character count: </label>
 	<span class="field-prefix"></span>

	<input maxlength="11" name="field_character_count[0][value]" id="edit-field-character-count-0-value" size="14" value="4380" class="form-text number" readonly="readonly" type="text">

	<span class="field-suffix"></span>
</div></div>

As i flip between VIEW and RESET Firebug does not show this html changing; however the first field (word count) flips between blank and having the correct value in it.

Also of note, the return value $this from the formHash function is different for these 2 values.

Word Count field: defaultValue=716, value=""
Char Count field: both defaultValue and Value field = 4380

Also of note, in $this at end of formHash $tis->form_id.value = 4380 (which is the value of character count field and is the form_id that get falsely used to create a new entry in autosave table.

so - certainly looks like issues with the formHash function - but at least it narrows down these issues quite a bit.

Comment #4

liquidcms CreditAttribution: liquidcms commented 8 January 2008 at 06:26

lol.. ok.. i didnt see your post above with patch.. and i just emailed you the same solution... i set to null rather than ""; but same effect.

thanks, i'll do some more tests.. do you still want the cck export.. not sure how well that will work since 1. not sure i can export cck node defs (although that would be a useful thing to be able to do) and 2. the fields in question are dynamically calculated so without rest of code in place they won't work.

Comment #5

edmund.kwok CreditAttribution: edmund.kwok commented 8 January 2008 at 11:36

Status:

Active

» Fixed

ptalindstrom and I have corresponded via email and confirm that the patch above does solve the problem. It is committed; feel free to reopen this issue if there are further testing indicates that the problem is not fixed.