Project

General

Profile

Actions

Bug #62400

closed

Lot of entries in sys_file_processed with name=NULL and identifier empty

Added by Albert van der Veen over 9 years ago. Updated about 8 years ago.

Status:
Rejected
Priority:
Should have
Assignee:
Category:
File Abstraction Layer (FAL)
Target version:
Start date:
2014-10-22
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
6.2
PHP Version:
Tags:
Complexity:
easy
Is Regression:
No
Sprint Focus:

Description

We have a fairly large site with an enormous amount of entries in sys_file_processed that have name = NULL, identifier = ''. A substantional subset of those has configuration = a:9:{s:5:"width";N;s:6:"height";N;s:13:"fileExtension";N;s:8:"maxWidth";i:0;s:9:"maxHeight";i:0;s:8:"minWidth";i:0;s:9:"minHeight";i:0;s:7:"noScale";N;s:20:"additionalParameters";N;}

A related issue can be found here: https://forge.typo3.org/issues/50392#note-15

This leads to all kinds of problems, for example images not being displayed in the FE according to dimensions specified in a content element, but in the original size (no processed file is being generated). If the entry in sys_file_processed in manually removed and the FE page reloaded, the image is correctly displayed.

It also breaks the 'replace image' in Media (current 0.6.0-dev from the repo): as soon as a FE page is generated with an image a correct entry is added to sys_file_processed, but also an extra entry with name = NULL and configuration = a:9:{s:5:"width";N;s:6:"height";N;s:13:"fileExtension";N;s:8:"maxWidth";i:0;s:9:"maxHeight";i:0;s:8:"minWidth";i:0;s:9:"minHeight";i:0;s:7:"noScale";N;s:20:"additionalParameters";N;}

If you then use 'replace image' through Media on that image, the new image is not handled correctly: you don't get a new thumb and no output on FE. This can be traced back to the function flushProcessedFiles in media/Classes/Cache/CacheService.php which deletes old processed files. Because the entry with name=NULL exists, the newly uploaded (original, not processed) file is immediately deleted again. Just using 'replace image' again and again (without generating the FE page) works fine.

Changing $processedFile->delete(TRUE) to $processedFile->delete(FALSE) in that same function 'fixes' the problem, but I presume these NULL entries shouldn't be generated in the first place?

Anyone have an idea why these entries are generated?


Related issues 14 (0 open14 closed)

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

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

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

Actions
Related to TYPO3 Core - Bug #58019: FAL Indexer for broken files: Column 'width' cannot be nullRejected2014-04-17

Actions
Related to TYPO3 Core - Bug #54533: imgResource.noScale doesn't scale image tagRejected

Actions
Related to TYPO3 Core - Bug #62247: FAL: Uppercase File Extensions of Image cannot be displayed RejectedBenni Mack2014-10-15

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

Actions
Related to TYPO3 Core - Bug #45922: image replacement, width and height are kept even i change my imageClosed2013-02-28

Actions
Related to TYPO3 Core - Bug #46020: Image size is 0 when not scaledClosedAlexander Opitz2013-03-04

Actions
Related to TYPO3 Core - Bug #46446: sys_file doesn't get updatedClosed2013-03-20

Actions
Related to TYPO3 Core - Bug #52658: Overriding image does not change the dimensionsRejected2013-10-10

Actions
Related to TYPO3 Core - Bug #64556: ProcessedFile record should not be saved/created when processing failedClosed2015-01-28

Actions
Related to TYPO3 Core - Bug #63519: sys_file_processedfile rows contain zero dimensionsClosed2014-12-02

Actions
Related to TYPO3 Core - Bug #89716: identifier not null in sys_file_processedfileClosed2019-11-20

Actions
Actions

Also available in: Atom PDF