Project

General

Profile

Actions

Bug #89004

open

Image processing (on scaling) runs repeatedly for the same image on every page load

Added by Dalibor Hrtánek over 4 years ago. Updated over 4 years ago.

Status:
New
Priority:
Should have
Assignee:
-
Category:
Image Cropping
Target version:
-
Start date:
2019-08-23
Due date:
% Done:

0%

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

Description

Hi there,

I am using the f:uri.image viewhelper in my news plugin's fluid template to generate images in 4 sizes for different devices/screens, which is placed in data-attributes of the image tag and loaded by javascript lazy loading, e.g.

{f:uri.image(src: '{image}', cropVariant: 'extrasmall', maxWidth: 768)}

This will generate a thumbnail in "_processed_" folder and related record in "sys_file_processedfile" table.
If the original image is smaller than the requested maxWidth, no processed image (resource) is created in the filesystem and the record in "sys_file_processedfile" table has empty "identifier" field instead of the filename of the processed image file.
It was working fine, but since this fix:
https://github.com/TYPO3/TYPO3.CMS/commit/9bb994f492e75efcfe139c3d6a64ef42dbef9bd1
I started to have issues with processed images, which are using original image (do not have resized copy in processed dir, because original is small enough already).
This issue has already been described in: https://forge.typo3.org/issues/86947, which has been resolved, but I think the real problem still remained.

If you check the database specification for "sys_file_processedfile" table, you will see the default value for identifier is empty string:

identifier varchar(512) DEFAULT '' NOT NULL,

and I think the empty string value is assigned exactly when processed images are using original image (and does not have own identifier).

Then when my f:uri.image ViewHelper asks ImageService to process the image, the processing should NOT be done again, if the very same image has already been processed with the very same processingInstructions (width/height) before.
The processing is not done again, if the function isProcessed() of the ProcessedFile class returns true and this happens correctly for processed images, that have not empty identifier.
BUT it incorrectly returns false for processed images that are using original image and it is because of the change in usesOriginalFile method in: https://github.com/TYPO3/TYPO3.CMS/blob/master/typo3/sysext/core/Classes/Resource/ProcessedFile.php

    public function usesOriginalFile()
    {
        return $this->identifier === null || $this->identifier === $this->originalFile->getIdentifier();
    }

Where double equation mark (simple comparison) has been changed to triple (strong type comparison).
Processed images that are using original image have empty string as identifier in the database (instead of null) and therefore this condition is no longer met with strict type comparison and the original image is constantly re-processing - database records are being updated and the file is rewritten in the file system with every (uncached) page load.

I suggest to change back to weaker == comparison or fix the database specification to use NULL as default for identifier of "sys_file_processedfile" table, but that will not fix old records without some update script.

Thanks.


Related issues 1 (0 open1 closed)

Related to TYPO3 Core - Bug #86399: Wrong processed folder resolved, when folder is configured to be on a different storageClosed2018-09-27

Actions
Actions #1

Updated by Dalibor Hrtánek over 4 years ago

  • TYPO3 Version changed from 10 to 8
Actions #2

Updated by Riccardo De Contardi over 4 years ago

This issue seems still valid on 9.5.11

Actions #3

Updated by Benni Mack 7 months ago

  • Related to Bug #86399: Wrong processed folder resolved, when folder is configured to be on a different storage added
Actions

Also available in: Atom PDF