Bug #46446
sys_file doesn't get updated
| Status: | Needs Feedback | Start date: | 2013-03-20 | |
|---|---|---|---|---|
| Priority: | Must have | Due date: | ||
| Assigned To: | - | % Done: | 0% |
|
| Category: | File Abstraction Layer (FAL) | Spent time: | - | |
| Target version: | 7.4 (Backend) | |||
| TYPO3 Version: | 6.0 | Is Regression: | No | |
| PHP Version: | Sprint Focus: | Remote Sprint | ||
| Complexity: |
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.
Related issues
History
#1 Updated by Andreas Wolf over 2 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.
#2 Updated by Andreas Kiessling over 2 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.
#3 Updated by Alexander Opitz about 2 years ago
@Andreas This haven't to do with this issue, that was the upper-/lowercase filesystem/sql like statements problem, we already spoke about.
#4 Updated by Camelia M almost 2 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).
#5 Updated by Thomas Etter almost 2 years ago
Problem is also existant in Typo3 6.1.5
#6 Updated by Alexander Opitz over 1 year ago
- Project changed from File Abstraction Layer to Core
- Category changed from Frontend to Frontend
#7 Updated by Alexander Opitz over 1 year ago
- Category changed from Frontend to File Abstraction Layer (FAL)
- Is Regression set to No
- TYPO3 Version set to 6.0
#8 Updated by Markus Klein over 1 year ago
Is this still an issue on 6.2?
#9 Updated by Sebastian Fischer about 1 year 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.
#10 Updated by Andreas Allacher 9 months 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?
#11 Updated by Frans Saris 7 months 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
#12 Updated by Mathias Schreiber 7 months ago
- Target version set to 7.1 (Cleanup)
- Sprint Focus set to On Location Sprint
#13 Updated by Michael Sollmann 2 months 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?
#14 Updated by Benjamin Mack about 1 month ago
- Target version changed from 7.1 (Cleanup) to 7.4 (Backend)
#15 Updated by Pierrick Caillon about 1 month ago
- Status changed from Accepted to In Progress
- Assigned To set to Pierrick Caillon
#16 Updated by Pierrick Caillon about 1 month ago
- Status changed from In Progress to Needs Feedback
- Assigned To 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), it is linked to issue #64196.
#17 Updated by Susanne Moog 17 days ago
- Sprint Focus changed from On Location Sprint to Remote Sprint