Bug #62400

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

Added by Albert van der Veen 10 months ago. Updated 17 days ago.

Status:Rejected Start date:2014-10-22
Priority:Should have Due date:
Assigned To:Andreas Wolf % Done:

0%

Category:File Abstraction Layer (FAL) Spent time: -
Target version:7.4 (Backend)
TYPO3 Version:6.2 Is Regression:No
PHP Version: Sprint Focus:
Complexity:easy

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

related to Core - Bug #44105: Image size does not get updated Closed 2012-12-19
related to Core - Bug #45922: image replacement, width and height are kept even i chang... Accepted 2013-02-28
related to Core - Bug #46020: Image size is 0 when not scaled Closed 2013-03-04
related to Core - Bug #46446: sys_file doesn't get updated Needs Feedback 2013-03-20
related to Core - Bug #50392: Specifying size in ImageViewHelper does nothing Closed 2013-07-24
related to Core - Bug #52658: Overriding image does not change the dimensions Rejected 2013-10-10
related to Core - Bug #54533: imgResource.noScale doesn't scale image tag Rejected
related to Core - Bug #58019: FAL Indexer for broken files: Column 'width' cannot be null Rejected 2014-04-17
related to Core - Bug #59216: Image dimensions (width/height) are 0 when not scaled Closed 2014-05-30
related to FAL Indexing - Bug #60215: sys_file_processedfile with empty identifier and name fields Under Review 2014-07-09
related to Core - Bug #61181: FAL: file maxW and maxH are ignored Rejected 2014-08-25
related to Core - Bug #62247: FAL: Uppercase File Extensions of Image cannot be displayed Rejected 2014-10-15
related to Core - Bug #63519: sys_file_processedfile rows contain zero dimensions Resolved 2014-12-02
related to Core - Bug #64556: ProcessedFile record should not be saved/created when pro... Closed 2015-01-28

History

#1 Updated by Albert van der Veen 9 months ago

Looking into the class TYPO3.CMS.Core.Resource.ProcessedFile, I now understand that entries with name=NULL are valid: 'A file may also meet the expectations set in the configuration without any processing. In that case, the ProcessedFile object still exists, but there is no physical file directly linked to it. Instead, it then redirects most method calls to the original file object. The data of these objects are also stored in the database, to indicate that no processing is required. With such files, the identifier and name fields in the database are empty to show this.'

But that still doesn't explain why these entries are generated for processed files. However, I suspect something is wrong with the config of this particular site, as I tested the same bahaviour on another site (far less complex as far as extensions etc is considered), and there no 'wrong' entries are generated. I'll investigate further and report back on my findings.

#2 Updated by Mathias Schreiber 7 months ago

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

#3 Updated by Frans Saris 6 months ago

  • Complexity set to easy

possible solution

In typo3/sysext/core/Classes/Resource/Service/FileProcessingService::process() extend the check

 if ($processedFile->isProcessed()) {

That also checks if the identifier is set

#4 Updated by Benjamin Mack about 1 month ago

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

#5 Updated by Jonathan IROULIN about 1 month ago

  • Assigned To set to Andreas Wolf

After discussion with Andreas Wolf, this is not a bug it is a feature.
This is the normal behaviour when the original file can be used,
to avoid to run the process file again and again.

#6 Updated by Andreas Wolf about 1 month ago

  • Status changed from New to Rejected

#7 Updated by Mathias Schreiber 17 days ago

  • Sprint Focus deleted (On Location Sprint)

Also available in: Atom PDF