sys_file_processedfile with empty identifier and name fields
In our installation "empty" sys_file_processedfile entries are created when the image cant be found.
The entries are missing identifier, name, width and height and it seems like they are created when a page is rendered but the image cant be found (but already in sys_file and sys_file_reference). It happens in our installation with a dedicated frontend server where the images are rsync'ed every 5min. So it can happen that an image is not synced yet.
In this case the frontend renders the image in its original size (without proper width and height sadly) and an empty sys_file_processedfile is added (leading to the fact that the image isnt rendered correctly later, even if it is synced).
This seems to be new since 6.2, wasnt happening with 6.1 (at least not in the frontend)
#1 Updated by Klaus Hinum about 5 years ago
looks like these empty sys_file_processedfile entries are not only created when a image is missing, but also when the frontend page is rendered. I find a lot of empty processedfiles in the DB and they will be regernerated if I delete them (altough the images exist and the frontend output looks good).
#2 Updated by Christian Ludwig about 5 years ago
- Project changed from TYPO3 Core to FAL Indexing
- Assignee set to Benni Mack
There seems to be a problem with the caching. We are often running into the same problem.
I am not sure if this should be handled by FAL Indexer? At least TYPO3 lacks a function to clear processed files as it is still available for the old image handler in the install tool.
At the moment, when we find images that are not scaled at all, we simply TRUNCATE TABLE `sys_file_processedfile`. But this leaves many processed images in numerous processed folders.
#7 Updated by Tobias Liebig over 2 years ago
I have the same issue with sys_file_processedfile reocrds with empty identifiers, which result in not-correctly-scaled-images in the frontend.
In my installation there are about 1.200.000 records in sys_file_processedfile of which about 20.000 have an empty identifier. I delete them regulary; on the next request the not-scaled-images git scaled correctly and an correct sys_file_processedfile is created. In my frontend there is no case where the original file would not be scaled, thus sys_file_processedfile with an empty identifier should not exists. So i guess they got created, when something went wrong (e.g. many larges images should be scaled in the same request), however I could not yet find the root cause.
The patch (http://review.typo3.org/39373) got merged in 6-2, but is missing in 7 and 8. However, it doesnt fix my issue, so i'm trying the workaround of https://forge.typo3.org/issues/62400#note-10 in my setup.
#9 Updated by Christian Stemmler 8 months ago
I found out that there are entries with empty identifier if the original image dimensions are smaler then the dimension that are given within eg. the image viewhelper and if upscaling is inactive. This could be correct so the original image should be used.
The problem i had was that this entries were processed again and again. The \TYPO3\CMS\Core\Resource\ProcessedFile::needsReprocessing function always return that the image should be reprocessed. I had to change \TYPO3\CMS\Core\Resource\ProcessedFile::usesOriginalFile function to respect identifier with empty string as well. So far i can't see any side effects.