image_file_move() flushes new URI not source URI.

I have the same problem here when editing a node and deleting the node image.

When adding a file image, the thumbnail filename is not being created using the Filefield Paths name – it keeps the original filename.

When you then edit that node, the imagecache system creates another image with the Filefield Paths filename. This adds a second file with the correct Filefield Paths name.

If you then delete the file, it only deletes the Filefield Paths image name and not the orphan image that has the original filename.

To see more clearly, simply watch the folder “thumbnails/public/YOURPATH” when content is being uploaded/deleted.

Cheers

Is this still a bug in 7.4? I seem to remember looking at this briefly with D7.2, but now that I'm trying to reproduce under D7.4 it's working as expected.

Hi,

Re-tested with Drupal 7.7 and latest FFP Dev on another hosting system to be sure. The thumbnail is still being kept (even by simply editing the node and removing the file image):

e.g. files/styles/thumbnail/public <--- the 'removed' file is still in this folder after deletion (as per #1 point 7).

** after more testing...

It seems the problem goes away if you specify the folder path BEFORE enabling FFP in the image field setting. Then when enabling FFP specify the file path again and should work ok. There appears to be two fields being used for file paths (?), so both must be set. If you do not specify one before enabling the FFP you will get files left over as I experienced in the post above. The two MUST be at least set and in sync.

Cheers.
Tim

Marking as fixed.

I have re-tested with new site using latest dev and Drupal 7.8. The problem is now returned despite what i wrote in #3.

The thumbnail filename is not being created using the Filefield Paths name – it keeps the original filename.

The image is being renamed as e.g. [node:title]_[node:nid].[file:ffp-extension-original] fine.

But in the folder files\styles\thumbnail\public\images it has the original filename set and this file was not renamed.

I am using: 'images' as the 'File path' name.

I don't know if FileField Paths should be expected to delete an unnecessary Image Style image, given that FileField Paths is invoking file_move() I would assume that the Image module should be implementing hook_file_move() to handle the deletion of any moved and unnecessary cached Image Style images.

Moving to Drupal Core for the time being.

@#6 The thumbnail filename is not being created using the Filefield Paths name. For me, this was the problem – on creation (it keeps the original filename), which i think is later causing the problem of non-deletion (maybe trying to be deleted with the updated name?). The filenames have become confused.

Also looking at #3: "There appears to be two fields being used for file paths (?)" .. this would be useful to understand as there are two paths in the DB being kept for the single file source?

Thanks!

Tim,

The file is not renamed until you save the node/entity, as the node/entity specific tokens can't be known until you have saved it, therefore when the thumbnail is first created it uses the filename that it is aware of, which is the unprocessed filename. Once you save the node/entity the original file is processed and moved via file_move(), which triggers implementations of hook_file_move() which should be used by the Image module to to handle and no longer useful cached Image Style images.

That is what the core issue is here and once/if that is resolved the issues you are having with FileField Paths will be resolved.

Cheers,
Deciphered.

Looked into the Image module and it appears to be flushing all Image derivatives of the $file->uri, which is the new location, instead it should be flush derivatives of $source->uri.

Confusion likely comes from the fact that file_move() takes the arguments in the order of 'old', 'new', whereas hook_file_move() uses the reverse order.

Updated issue summary.

At first glance it looks like @Deciphered is correct here. As usual, this would probably benefit from a test though :\

>The file is not renamed until you save the node/entity..

Yes, agreed. This was my point #1 - I had to save the node in order to edit it, which is where I noticed the problem.

Can do testing on this and report back.

Cheers for now,
Tim.

@Deciphered - have tested #9 and confirmed it works: It moves the original filename to new filename with new folder path as expected.

Re-tested #9 patch on core without Filefield Paths module enabled and verified everything working as expected.

Thanks for looking at this. Will be testing this on another system this week to double check etc.

Cheers! Tim

Just a quick update, due to the drastic changes in D8 with the new /core directory my Aegir based development environment no longer allows me to dev on D8 so therefore I have not yet been able to write the tests.

I hope to get this resolved ASAP or atleast resort to a temporary dev environment, but I have not yet had time to do so.

Cheers,
Deciphered.

Added test to fail and prove need for patch at comment #9.

Patch with Test and Fix.

Forgot to mark as 'Needs Review'

Updated patch after IRC review by XJM.

Looks great now, thanks @Deciphered!

Committed to 8.x and backported to 7.x. Thanks.