Using FileFields Paths makes default image to get attached to node same way as if they were uploaded to the node when no image is uplaoded. So, when image from node is deleted (to upload the right one) default iamge file is deleted. This only happens when using two image fields.

Steps to reproduce:

1) Set up a content type with two image fields with just one value each (so you only can upload one image per field) using a default image that is uploaded when content type is created (one image for each field).

2) Create a new node of that content type without uploading any image. When node is accessed the default images are shown.

3) Edit that new node. the two iamge fields are empty. Upload an image in one field, leaving the second field empty. When node is accessed first field shows the uploaded image and second field shows the default image. All right for now.

4) Edit again that node. The first field shows the uploaded image, but the second image field is not empty, it shows the default image just as the same way if it that image was uploaded to this node (what it hasn't been done)

5) Push delete button to upload the right image for this node to substitute the default image. But this action makes the original default image file to be deleted.

Disabling FileField Paths works as expected: in 4) the second field is empty, so you can upload your new image withuot problems.

I didn't have time enought to check code or look deeper, any new info will be posted here.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Brummbar’s picture

I have found the same problem with default images.
After checking the code, I've found the lines where the image fields are populated with the default image data, that leads to the unwanted behaviour reported.
In filefield_paths/filefield_paths.module, at row 712:
$full = token_get_values($type, $object, TRUE);
Before that line, the $object has the correct data, but not after.
Tracked down a bit more, I ended up with:
cck/includes/content.token.inc at row 36:
content_view($node);
Same as before, before this call the $node object is ok.
Actually I didn't understand the reasons, because these object are being cloned and shouldn't be modified. I'll post more if I can figure out more.

DeFr’s picture

Version: 6.x-1.4 » 6.x-1.x-dev
Status: Active » Needs review
FileSize
607 bytes

I've hit the same issues on a project I've been working on, attached patch seems to fix it (at least on PHP 5.2 and 5.3).

It looks like looping on the items and explicitely taking a reference changes PHP behavior for the whole request, and somehow manages to make token's drupal_clone call in token_get_values inefficient.

Deciphered’s picture

Status: Needs review » Closed (won't fix)

No longer supporting Drupal 6 issues for this module.