Bug #64556
ProcessedFile record should not be saved/created when processing failed
| Status: | Closed | Start date: | 2015-01-28 | |
|---|---|---|---|---|
| Priority: | Should have | Due date: | ||
| Assigned To: | - | % Done: | 0% |
|
| Category: | File Abstraction Layer (FAL) | Spent time: | - | |
| Target version: | - | |||
| TYPO3 Version: | 6.2 | Is Regression: | No | |
| PHP Version: | Sprint Focus: | On Location Sprint | ||
| Complexity: | no-brainer |
Description
If the processing of an image fails a record with empty identifier and name = NULL is still created for given process instructions. This results in a the original file being used in FE.
Failing of processing can happen when a lot of large files are processed on the same request.
When preventing the record from being saved the processing happens on next request.
Related issues
History
#1 Updated by Mathias Schreiber 6 months ago
- Complexity set to no-brainer
#2 Updated by Mathias Schreiber 6 months ago
- Status changed from New to In Progress
#3 Updated by Mathias Schreiber 6 months ago
- Status changed from In Progress to New
#4 Updated by Ingo Schmitt 6 months ago
- Status changed from New to In Progress
#5 Updated by Frans Saris 6 months ago
We can not reproduce. The empty identifier and name = NULL in sys_file_processedfile are correct if the original file doesn't need to be resized.
we close this issue for now.
#6 Updated by Frans Saris 6 months ago
- Status changed from In Progress to Closed
#7 Updated by Bernhard Kraft 6 months ago
I experienced the same issue.
A site with many (large) images on a single page (https://www.saferinternet.at/broschuerenservice/materialien-fuer-lehrende/)
Under some circumstances the sys_file_processedfile contained wrong entries which resulted in files (3k x 2k pixels in size) not being resized to width=48. Fatal look in FE.
I guess it has to do with upgrading.
In my opinion the sys_file_processedfile should rather be a "sticky" cache than a static table. Currently only the TypoScript Configuration is taken into account when generating the "processedfile" hash. But the TYPO3_CONF_VARS GFX section, the IM/GM version, and also the TYPO3 version would also need to get taken into account.
What is done when processing files is:
original --> algorithm --> output
And "algorithm" not only consists of the TypoScript configuration but of all above mentioned software. When a future TYPO3 version for example differently generates images (for example like when the "colorspace" IM option got added) all sys_file_processedfile entries would become invalidated.
I guess "cf_" cache tables should all require an additional attribute/field "stickyness". The higher the value the more one has to click "clear all caches" :)
No. really: In the Install Tool there sould be an option to clear all cache entries up to some given stickyness level.
#8 Updated by Frans Saris 6 months ago
Hi Bernhard,
would be cool if you could find out where the processing exactly and the wrong info is written to the sys_file_processedfile table.
IMO the saved configuration/algorithm is sufficient this way. If you do a major upgrade and want to renew all you processed file you just truncate the sys_file_processedfile table and all processed folders. But I think this normally wouldn't be necessary, most of the times it is enough if only new used files get the new IM/GM features applied. At least in production environment.
But a clear all processed files for storage x could indeed be a nice addition to the install tool. Maybe you could create an issue for that?
Gr. Frans