Posted by chrisirhc on July 17, 2009 at 5:46pm
Jump to:
| Project: | File (Field) Paths |
| Version: | 6.x-1.3 |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
Issue Summary
Somehow, for certain images that have names like "dsc_0076 (2).jpg", the cropped image is renamed with tokens but the uncropped image is left with the same filename.
I solved this by processing the $file['filename']['new'] first then processing the $file['filepath']['new'] without $file['field']['filename'] then appending the $file['filename']['new'] to it.
Is there a reason why the code is structured such that the file path is processed first then the file name?
I didn't find the exact bug behind it but I worked around by rearranging the order of processing.
Didn't post a patch because I'm currently really busy. Just wanted to point out something. Not sure if it's only on my side.
Comments
#1
Images with simple filenames like "7.jpg" rename fine with no changes. (forgot to include that line above)
#2
Hi chrisirhc,
I tested using the filename you suggested but was unable to confirm the issue.
Can you provide me with with the replacement patterns you used?
Cheers,
Deciphered.
#3
Hi,
While I was unable to reproduce this issue exactly, I have an inkling that it is the same issue as #494506: Using Imagefield Crop Cannot Re-Crop Image if Pathauto is Used For File Name Cleanup, though that issue only occurred when the filename contained an uppercase character, which according to your information above it did not.
While I didn't track down the exact cause of these issues, I'm confident enough with this particular change as it is a very logical change and I can not think of any particular reason why it wasn't in that order to begin with.
Fix will be in the next development release.
Cheers,
Deciphered.
#4
Fix committed to DRUPAL-6--1 and DRUPAL-5.
Cheers,
Deciphered.
#5