Bug #46446
closed
sys_file doesn't get updated
Added by Philipp Idler about 11 years ago. Updated about 8 years ago.
0%
Description
Replacing an image with different dimensions but same filename gets rendered in frontend with old dimensions of previous image.
Reproduce:
Add textpic element on a page, upload an image and save. View it frontend. Everything fine so long...
Now edit this element, delete the image and upload another image with different dimensions but same filename.
TYPO3 renders the new image in frontend with the dimensions in IMG-tag of previous image.
Files
| img-dimensions.jpg (52.9 KB) img-dimensions.jpg | Philipp Idler, 2013-03-20 08:36 |
Updated by Andreas Wolf about 11 years ago
- Status changed from New to Accepted
This is due to the fact that the old processed file records are not thrown away. Anyways, the processed files should be regenerated when the image has been changed (because of new timestamp and hash), so something is clearly broken here.
Updated by Andreas Kiessling about 11 years ago
Just had a similar effect: i had to rename a folder "externally" and my fluid template had the new path to the image file, but it generated the old path (only changed one letter to lowercase). I found two entries in sys_file and after deleting both it worked again.
Updated by Alexander Opitz almost 11 years ago
@Andreas Otto † This haven't to do with this issue, that was the upper-/lowercase filesystem/sql like statements problem, we already spoke about.
Updated by Camelia M over 10 years ago
Philipp Idler wrote:
Replacing an image with different dimensions but same filename gets rendered in frontend with old dimensions of previous image.
Reproduce:
Add textpic element on a page, upload an image and save. View it frontend. Everything fine so long...
Now edit this element, delete the image and upload another image with different dimensions but same filename.TYPO3 renders the new image in frontend with the dimensions in IMG-tag of previous image.
this problem still exists (at least in typo3 6.1.3).
Updated by Thomas Etter over 10 years ago
Problem is also existant in Typo3 6.1.5
Updated by Alexander Opitz over 10 years ago
- Project changed from 1401 to TYPO3 Core
- Category changed from Frontend to Frontend
Updated by Alexander Opitz over 10 years ago
- Category changed from Frontend to File Abstraction Layer (FAL)
- Is Regression set to No
- TYPO3 Version set to 6.0
Updated by 
Updated by Sebastian Fischer almost 10 years ago
Replacing an image with same name but different resolution resulted in a different image size in the frontend in current master. But the thumbnail still displays the old image content.
Updated by Andreas Allacher over 9 years ago
I just noticed this issue again too with 6.2.6 (as I mentioned in a related bug but that one was closed).
I guess it will not be an issue for files in fileadmin but files that are distributed via extesion public resources can still be a problem.
e.g. I just updated an image inside my extension but the sys_file record still used the old image size and therefore the image was rendered wrongly (not even ratio was correct) and in this case the image was not even resized but just rendered directly.
I was using the ImageViewHelper for the output.
I can avoid this by using uri.resource and the tag directly but that way I am losing resize functionality etc.
Maybe checking the if the original file timestamp matches the current timestamp and if not check the SHA1 value before rendering?
Updated by Frans Saris over 9 years ago
All processed files should be deleted when a file is replaced. Should be done on signal \TYPO3\CMS\Core\Resource\ResourceStorage::postFileReplace like TYPO3\CMS\Core\Resource\Processing\FileDeletionAspect
Updated by Mathias Schreiber over 9 years ago
- Target version set to 7.1 (Cleanup)
- Sprint Focus set to On Location Sprint
Updated by Michael Sollmann almost 9 years ago
When I replace an image (shown with CType "uploads" and sys_file_collection) "data = file:current:tstamp" shows the tstamp of the old image even if I clear the cache. Same problem?
Updated by Benni Mack almost 9 years ago
- Target version changed from 7.1 (Cleanup) to 7.4 (Backend)
Updated by Pierrick Caillon almost 9 years ago
- Status changed from Accepted to In Progress
- Assignee set to Pierrick Caillon
Updated by Pierrick Caillon almost 9 years ago
- Status changed from In Progress to Needs Feedback
- Assignee deleted (
Pierrick Caillon)
Using master initialized with bootstrap package, I cannot reproduce the issue.
- I created a test page. I created a testpic. Set some title and description. Selected image alignment as "In text, left" to have the image processed. Then used "Select & upload files" to upload my first test image with name 46446_test.jpg. The image is a landscape photograph. And finally saved.
- The image displays correctly in frontend. The image thumbnail in backend is as expected.
- I edited again the content. Removed the image using its "Delete record (!)" button. Used again the "Select & upload files" button to upload my second test image which I have put in a different folder to name it the same. The image is a portrait photograph. And finally saved.
- The image displays correctly in frontend. The image thumbnail in backend was as expected before and after saving.
Regarding comment 10 (#46446-10), it is linked to issue #64196.
Updated by Susanne Moog almost 9 years ago
- Sprint Focus changed from On Location Sprint to Remote Sprint
Updated by Susanne Moog over 8 years ago
- Target version changed from 7.4 (Backend) to 7.5
Updated by Alexander Opitz over 8 years ago
Hi,
does the problem still exists within newer versions of TYPO3 CMS (6.2.17 or 7.6.2)?
Updated by Riccardo De Contardi about 8 years ago
- Status changed from Needs Feedback to Closed
No feedback within the last 90 days => closing this issue.
If you think that this is the wrong decision or experience this issue again, then please write to the mailing list typo3.teams.bugs with issue number and an explanation or open a new ticket and add a relation to this ticket number.
Thank you