If a content type has a field with an unlimited number of values, you lose the node reference when you save.

I'm having the same issue. When you don't make the reference a required field, it just saves the node without the reference. It's a bug I guess

Edit: The same thing happens when you have an image field and click the "upload" button. The reference is still displayed after uploading the image, but it isn't saved

Having the same issue. I was about to post it myself, but I finally found this thread. To elaborate on the issue, I'm seeing the problem when I upload an image to the node before saving it. When I do save it, the reference is lost. If I save it without uploading an image, the reference is saved and all is fine.

I hope someone can find a solution soon. Thanks in advance :-)

Edit: For me it does not matter if the image field mentioned can contain an unlimited or a limited number of images.

This was caused by the same issue as #1125988: Editing a node leads to a wrong reference when the fallback behavior is enabled . With it fixed, this issue also seemed to resolve.

Hi Quicksketch

I just did a quick test, but the issue is still there with the new version.

I can confirm that this issue is still present. It seems to be caused by a different bug, probably something AJAX related

Hrm, sure enough. Sorry guys. Unfortunately this is proving a bit puzzling. I'm not sure how other modules maintain their values during AJAX requests. The File module includes what looks like a hack (reading directly from $form_state['input']), which would work for us too, but it just doesn't feel right. This may require some more investigation. Any takers out there interested in looking I wouldn't mind a second set of eyes on what's causing this.

Well I poked around for a long time and this is the best solution I can come up with. Normally pulling stuff from $form_state['input'] is frowned upon, but at least we check that the input is valid before accepting it into the field, so we're not opening up any kind of injection attacks or allowing invalid references.

If you guys can review this that would be stellar. I totally forgot that I need to get out a security fix anyway, and tomorrow would be a good time (security fixes are always released on Wednesdays).

This patch also prevents the "Preview" button from from reverting to the fallback widget.

It seems the problem has been fixed with the patch. Did some testing with creating new nodes and uploading and removing images to the nodes, and the reference was retained.

One thing I did notice though: When you edit a node, the reference field becomes editable. This is not a problem to me, but I seem to remember that the reference field was locked before I applied the patch.

Quicksketch, thanks for the quick fix. It is really appreciated!

One thing I did notice though: When you edit a node, the reference field becomes editable. This is not a problem to me, but I seem to remember that the reference field was locked before I applied the patch.

Thanks, another great catch. I thought I had tested that adequately but these changes caused a regression. I fixed the incorrect statement and committed that also.

The new security release (1.10) also includes these fixes. Let's hope we got Drupal 7 nailed down this time. :)