Posted by joachim on April 14, 2008 at 4:08pm
Jump to:
| Project: | FileField |
| Version: | 6.x-3.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Issue Summary
CCK: 5.x-1.6-1
Imagefield: 5.x-1.1
I had one image field on my site, set on one content type.
I deleted the field.
I expected the image files uploaded to this field to be deleted from my server's directory, but they are still there.
Comments
#1
Yeah CCK doesn't let modules know this is happening... CCK will have to be updated upstream I can probably put something in place after the 6.x ports are done.
#2
We can now do this with CCK 2.x in Drupal 6. Here's the relevant code from content_field_instance_delete():
<?php// Invoke hook_content_fieldapi().
module_invoke_all('content_fieldapi', 'delete instance', $field);
?>
Moving to FileField since it controls storing the files.
#3
subscribing
#4
Just upgraded from the Alpha version of this today to 6.x-3.2. In the alpha version if a file was removed, it was also deleted from the server as well. This is not the case with the latest module. This is causing problems with the View I set up. The file should be deleted from the view (like it was in the Alpha version) but it is not.
#5
subscribing. is this still an issue ?
#6
Yes, this has not been fixed yet afaik.
#7
Subscribing. Have a client that doesn't want to leave orphaned files cluttering up server space...any updates?
#8
Not fixed after 2 years? Subscribing
#9
yan_nick: Are you volunteering?
#10
Cannot fix the problem.
#11
$5 donation for the fix ;D
#12
Subscribing.
Having the same problem. I deleted an image field where hundreds of images had already been uploaded, and all the files are still on the server now, wasting space.
#13
Subscribe. In the broader context of an ongoing Drupal site:
How do you know that something like filefield_sources hasn't been in use (and possibly later uninstalled) and the relevant files haven't also been added to other filefields elsewhere? Check all filefield instances, not just the one that has been deleted?
Can you be sure that some other non-CCK module hasn't been getting and referencing existing file ids somewhere, somehow?
"Is this file still used" isn't such an easy question ... ?
#14
The Rules module could do that process, if there is a way to designate the path and file to delete. Would there be a Filefield Token for the path and the file?
Trigger: When node is deleted
Condition: if content_type="x" or you could use if my-cck-field="whatever"
Action: delete "path/to/file"
Is there a way to make the node id the Filefield path? I do not see the node id listed in the Replacement Tokens list for the Filefield settings. Somewhere during my version upgrades, many of the tokens that I used to use are no longer in the list.
/files/[nid]/file-1.pdf
/files/[nid]/file-2.pdf
--------------------------------------
Update. Just found this. See http://drupal.org/project/filefield_paths
I was determined with the new site to use as few modules as possible. My list is already getting very long, but the things the modules will do seems like a necessity.
------------------------------------------------------------------
Later in same day.
Reading more on image management as I am setting up a new site. What I have gathered from today's reading...use IMCE to store files permanently; use CCK FileFields for files that will be deleted when the node is deleted.
Sorry. I now realize that I misunderstood the discussion here and my suggestions are of no use. If I could delete my post I would.
#15
Here is what happened: I created a content type (let's call it 'content_type') and an imagefield CCK field (let's call it 'field_images') and after uploading hundread of files, I realize that I actually don't need that field. I delete the field but the files and references in the DB are still there, orphaned. I want to clean this mess.
I found a way to delete all of these files and clean the database.
I can execute these SQL statements in phpMyAdmin to get a list of all the files I need to manually delete:
SELECT filepath FROM `files` WHERE fid IN (SELECT field_images_fid FROM `content_field_images` as a LEFT JOIN node as b ON a.nid = b.nid WHERE b.type = 'content_type');Of course you might want to replace the word 'images' with the name of your field, and 'content_type' with the machine readable name of the content type where you deleted the CCK filefield.
Now don't forget also that all of these images have a thumbnail as well, located in the 'imagefield_thumbs' folder, with the same path. You can put a LIMIT 0,99999 at the end of the query to get all path on one page and save it as a reference.
When you are ready to actually clean the database, you can use these SQL queries:
DELETE FROM `files` WHERE fid IN (SELECT field_images_fid FROM `content_field_images` as a LEFT JOIN node as b ON a.nid = b.nid WHERE b.type = 'content_type');DELETE FROM `content_field_images` WHERE nid IN (SELECT nid FROM `node` WHERE type = 'content_type');These queries MUST be executed in that order. The first one will clean the Drupal files table. The second one will clean the imagefield table. After that you can delete all files with the path that you got with the SELECT query. Your Drupal system should now be clean. Just clear the cache to be sure to get rid of old data.
Hope this helps.
#16
At first I thought it was a feature to prevent the file from being deleted in the case of accidentally removing a field from a content type but if you re-add the field, files are NOT re-added to each node. All file being orphaned instantly after you remove the field so I'm sure it is more a bug than a feature, and from what I can read, a previous Alpha version was able to work correctly and remove the files to it seems that it's possible to do that. Marking it as a bug.
#17
Just to be clear, I don't really plan on fixing this bug (but yes it is really a bug). It does not affect me (or users) enough for me to consider it a problem. As far as I know, no version of FileField has ever handled this problem as it was never even possible before CCK added the necessary hooks to handle this.
Patches to solve this problem will be given a chance for review of course and I'd be happy to see the problem fixed. I'm just not going to spend the time to implement this because I consider it to be a minor inconvenience in comparison to all the ways that it could go wrong.
#18
Yeah, would be cool if there is an option "Delete file if node was deleted".
Yannick
#19
Files are already deleted when nodes are deleted (if the file is not in use elsewhere). That's not what this issue is about. This issue is about deleting ALL the files that have been uploaded into a field site-wide when the *field* is deleted.
#20
Oh, then that's another issue I have. Will post it.