Bug #62400
Lot of entries in sys_file_processed with name=NULL and identifier empty
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
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)