CCK fields set to "allow unlimited" disappear when 'Add another option' is selected.

I can confirm this as an issue in at least Firefox (my version is 3.6.12 running on my mac). This works as expected in IE7 (7.0.6001.18000). no testing in IE6

The steps are even simpler than listed above (but i've added a few for clarity)

1) in a fresh install of drupal 6.19 ,enable "autosave" and cck's "content" and "text" modules
2) create a new content type. set it to autosave every 5sec
3) add a cck text field. set the number of values to unlimited
4) create a new node of that type.
5) put something in the 2 textboxes for the field you defined defined
6) wait for autosave to run.
7) click "add another item"
8) try to find that field on the screen (its gone)

This is clearly a bug of some sort in autosave's jquery. if i had any jquery chops I'd take a stab at it, but I'm pretty useless on this one.
-Chris

I'm able to duplicate the problem with Drupal core 6.20, Autosave 6.x-2.9 and CCK 6.x-2.8.

I'm seeing this behavior only with a specific set of steps:

1) Create and save a node.
2) Refresh node edit page
3) When "This form was autosaved.." bar pops up, click View.
4) At this point, a click to the "Add another item" button will result in the the content of the child div of the #field-FIELDNAME-items div being emptied. You do not have to click on Reset/Ignore/Keep.

I've duplicated this behavior with both Firefox 3.6.13 and Chrome 8.0.552.224 and Safari 5.0.2 (6533.18.5) on mac.

I think I've narrowed this down to form_build_id not being set in the "Add another item" callback after the Autosave state is viewed.

Post before viewing Autosave state:

  body	
  changed	1292516011
  date	2010-12-16 10:20:42 -0500
  field_nested[0][value]	asdasdadasd
  field_texttest[0][_weight...	-1
  field_texttest[0][value]	
  field_texttest[1][_weight...	1
  field_texttest[1][value]	
  field_texttest_add_more	Add another item
  form_build_id	form-0d069ac318adafa99414f93872a5b90f
  form_id	test_node_form
  form_token	e9a03d22bed9b7099457c19735ff7428
  format	2
  log	
  menu[link_title]	Bar
  menu[parent]	primary-links:0
  menu[weight]	0
  name	Admin
  promote	1
  status	1
  teaser_include	1
  title	Test two

Post after:

  Parametersapplication/x-www-form-urlencoded
  body	
  changed	1292516011
  comment	2
  date	2010-12-16 10:20:42 -0500
  field_nested[0][value]	asdasdadasd
  field_texttest[0][_weight...	-1
  field_texttest[0][value]	
  field_texttest[1][_weight...	-1
  field_texttest[1][value]	
  field_texttest_add_more	Add another item
  form_build_id	
  form_id	test_node_form
  form_token	e9a03d22bed9b7099457c19735ff7428
  format	1
  log	
  menu[link_title]	Bar
  menu[parent]	primary-links:0
  menu[weight]	0
  name	Admin
  promote	1
  status	1
  teaser_include	1
  title	Test two

Found that autosave_save() is explicitly unsetting the form_build_id ... and since the CCK AHAH depends on this to properly reset the form, CCK generates an empty data object when it doesn't see the ID, thus emptying out the div containing the form elements.

Line 132 of autosave.module:

  unset($_POST['q'], $_POST['op'], $_POST['form_build_id']);

Can be changed to

  unset($_POST['q'], $_POST['op']);

and this issue seems to go away, but I don't know if this will cause further regression if/when the form_build_id changes.

@chrisyates. I was 100% convinced that this was a front end ui problem/conflict, but applying that fix corrected the problem!

I've attached a patch with the changes you've outlined. thanks again!
-Chris (porter)

one last thing to note,

The patch above interferes with the strongarm patch found elsewhere. for those who need both pieces of functionality, the patch below corrects this issue once the strongarm patch has been applied.

#6 works with cck-3.x-dev (2011-Mar-17) Thanks!

I'd be a lot more comfortable with this patch if I knew *why* autosave_save was explicitly unsetting form_build_id, and why it's okay to leave it there now.

All I know is that the comments say "for Drupal 6 version need to remove op and form_build_id". Why?

On the other hand, this patch *does* appear to work...