Bug #90600


Frontend cache inconsistency with processed images

Added by Markus Mächler about 4 years ago. Updated 8 months ago.

Should have
Target version:
Start date:
Due date:
% Done:


Estimated time:
TYPO3 Version:
PHP Version:
Is Regression:
Sprint Focus:


We discovered a cache inconsistency where processed images can be removed from the filesystem, even though they are still part of a cached page. We have tested this with TYPO3 9 LTS, but it is very likely also an issue with TYPO3 10 LTS.

Steps to reproduce the issue

  1. Create two pages pageA and pageB
  2. Add an images content element to pageA and pageB and choose the same image demo_image.png
  3. Apply image processing to the image (e.g. max width 50px) on both pages
  4. Open both pages in the frontend and note the generated unique hash (e.g. /fileadmin/_processed_/d/2/csm_demo_2cb965e686.png -> 2cb965e686). The hash should be the same on both pages.
  5. Change the column modification_date in sys_file for demo_image.png, this will lead to a new hash for the processed image
  6. Clear the page cache for pageA only
  7. Open pageA in the frontend, note the new unique hash e.g. /fileadmin/_processed_/d/2/csm_demo_bf52a6057a.png -> bf52a6057a)
  8. Note that the previous processed image csm_demo_2cb965e686.png has been removed from the file system
  9. Open pageB (make sure caching is not disabled, e.g. use inkognito mode) and note that the image is missing on the page because it is still referencing csm_demo_2cb965e686.png, which has been deleted.

Proposed fix

Add page cache tags for all processed images. Whenever a processed image is removed, clear the page cache of all pages including that image using the cache tags.

Additional info

At the moment the deletion is done in TYPO3\CMS\Core\Resource\ProcessedFile in a function called needsReprocessing. Probably processed images should not be deleted in a seemingly innocent method called needsReprocessing. See

Actions #1

Updated by Friedemann Altrock 8 months ago

This bug very much still exists.

The phenomenon occurred for a customer of mine, some images vanishing after an arbitrary number of days or weeks of no changes in the system (or so it seemed).
It took a while to find out the underlying cause. As it turns out some external process updates the images in an export/import.
Even if the file is the same, the modification_date column is updated when the metadata extraction or FAL indexing scheduler task runs.
This leads to a different checksum, and as soon as the page containing the image is regenerated, the "old" processed file is deleted.
If another cache_pages entry containing the old URL has not expired, it shows a 404 image. In our case multiple cache entries existed
because of some TypoScript conditions.

Just adding cache tags for the processed file DB entry would not work, as the FileDeletionAspect removes the row via QueryBuilder, not DataHandler.

As an aside: delete() is also called in the method ProcessedFile::setName, another "innocent" name hiding a serious side effect.

Actions #2

Updated by Friedemann Altrock 8 months ago

I've made an automated reproduction here


Also available in: Atom PDF