Project

General

Profile

Actions

Bug #46446

closed

sys_file doesn't get updated

Added by Philipp Idler over 11 years ago. Updated over 8 years ago.

Status:
Closed
Priority:
Must have
Assignee:
-
Category:
File Abstraction Layer (FAL)
Target version:
-
Start date:
2013-03-20
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
6.0
PHP Version:
Tags:
Complexity:
Is Regression:
No
Sprint Focus:
Remote Sprint

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

Related issues 6 (0 open6 closed)

Related to TYPO3 Core - Bug #46482: cached image sizes (sys_file) are not updated when replacing a fileClosed2013-03-21

Actions
Related to TYPO3 Core - Bug #50392: Specifying size in ImageViewHelper does nothingClosed2013-07-24

Actions
Related to TYPO3 Core - Bug #62400: Lot of entries in sys_file_processed with name=NULL and identifier emptyRejectedAndreas Wolf2014-10-22

Actions
Related to TYPO3 Core - Bug #59216: Image dimensions (width/height) are 0 when not scaledClosed2014-05-30

Actions
Related to TYPO3 Core - Bug #61181: FAL: file maxW and maxH are ignoredRejected2014-08-25

Actions
Has duplicate TYPO3 Core - Bug #44105: Image size does not get updatedClosed2012-12-19

Actions
Actions #1

Updated by Andreas Wolf over 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.

Actions #2

Updated by Andreas Kießling over 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.

Actions #3

Updated by Alexander Opitz over 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.

Actions #4

Updated by Camelia M about 11 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).

Actions #5

Updated by Thomas Etter about 11 years ago

Problem is also existant in Typo3 6.1.5

Actions #6

Updated by Alexander Opitz almost 11 years ago

  • Project changed from 1401 to TYPO3 Core
  • Category changed from Frontend to Frontend
Actions #7

Updated by Alexander Opitz almost 11 years ago

  • Category changed from Frontend to File Abstraction Layer (FAL)
  • Is Regression set to No
  • TYPO3 Version set to 6.0
Actions #8

Updated by Markus Klein over 10 years ago

Is this still an issue on 6.2?

Actions #9

Updated by Sebastian Fischer over 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.

Actions #10

Updated by Andreas Allacher about 10 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?

Actions #11

Updated by Frans Saris almost 10 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

Actions #12

Updated by Mathias Schreiber almost 10 years ago

  • Target version set to 7.1 (Cleanup)
  • Sprint Focus set to On Location Sprint
Actions #13

Updated by Michael Sollmann over 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?

Actions #14

Updated by Benni Mack over 9 years ago

  • Target version changed from 7.1 (Cleanup) to 7.4 (Backend)
Actions #15

Updated by Pierrick Caillon over 9 years ago

  • Status changed from Accepted to In Progress
  • Assignee set to Pierrick Caillon
Actions #16

Updated by Pierrick Caillon over 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.

  1. 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.
  2. The image displays correctly in frontend. The image thumbnail in backend is as expected.
  3. 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.
  4. 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.

Actions #17

Updated by Susanne Moog over 9 years ago

  • Sprint Focus changed from On Location Sprint to Remote Sprint
Actions #18

Updated by Susanne Moog over 9 years ago

  • Target version changed from 7.4 (Backend) to 7.5
Actions #19

Updated by Benni Mack about 9 years ago

  • Target version deleted (7.5)
Actions #20

Updated by Alexander Opitz almost 9 years ago

Hi,

does the problem still exists within newer versions of TYPO3 CMS (6.2.17 or 7.6.2)?

Actions #21

Updated by Riccardo De Contardi over 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

Actions

Also available in: Atom PDF