This may be a duplicate of http://drupal.org/node/43273, however it has a different symptom.
In their issue, the image field is showing the same for two when it's suppose to be one for each content type
My issue is I keep losing a default image field file .

cck 2.4
image field 6.0
Default settings for image field other than default
755 perm for the default image directory

I'm ATM trying to set multiple default images for already existing content types on one field (field_icon).

I add the field, field_icon to contenttype1 and set the default image. It works
I add field_icon to ct2. it shows the image for ct1, i upload my image for ct2. It works. But the image for content type1 has been REMOVED, gone completely from the file directory (settings are still there).
Go back and readd the image and it eventually sticks to ct1.
When I go to ct3 and add the field_icon it shows the image for ct1 under default image . I upload my image, works fine, but ct1's image has been destroyed again.

Looks like the issue is that imagefield(filefield?) needs to check before deleting a file so not to blow up other field's default image. I haven't dug into the code though so can't be certain(filefield scares me a lot).

Comments

quicksketch’s picture

Thanks for the great bug report. Seems like a likely problem to occur in the circumstances you described.

quicksketch’s picture

I've confirmed this problem exists. No easy solution to fix it though... we'll need to do some kind of loop through all instances of a field and check that the same image isn't being used elsewhere.

cristianparvu’s picture

This is an issue that would be nice to patch. Why? Well because I think you can do a lot of stuff with it.

Let me explain. In the process of implementing a new website, I found myself in the situation to have different content types with same imagefield but with different default images.
What I am trying to do is to use this imagefield values in a view block, that uses Arguments (Node: Nid -> Provide default argument -> Node ID from URL). I don't know how to do this without using templates, but I think is a nice feature.

For example you can have an the same imagefield for all the content types, but with different default values, and use this image to change the header image (maybe it's a stupid example, but it can be done).

Or maybe I am so stupid, that I did not found another solution using only the CCK ImageField and Views.

hefox’s picture

(It's annoying, but ya can reupload the deleted images to the imagecache default folder as the setting to use em is still there. It would be nice to fix XD)

cristianparvu’s picture

I am not a newbie in PHP, but I have a lot to learn about Drupal. quicksketch suggested at #2 to check all instances to see if the image is used by any other node type.

This can be done (I guess) in the method _imagefield_widget_settings_default_validate() in imagefiled_widget.inc file.

I know how to do that in PHP, but not how to do it using Drupal methods. Basically we need to loop through table content_node_field_instance rows and check the column widget_setting to see if the image we want to delete is used by any other node type.

I believe that someone with more experience in Drupal development can do that pretty fast. If not I will eventually figure it out :)

Anyway, thank you to Drupal and the community for making my life easier!

quicksketch’s picture

Title: incorrect default image deletion » Default image incorrectly deleted when replaced on a shared content type
Status: Active » Fixed
StatusFileSize
new2.23 KB

This patch corrects the problem by utilizing hook_file_references() to keep track of when files are deleted. While we could accurately return if a file is in use by ImageField, the current implementation only does the check when the "imagefield_content_type" flag is present for efficiency. The chances that an ImageField default image would be re-used anywhere else within Drupal is pretty much non-existent, so doing this check on deletion of any file seems like a waste of resources.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.