Bug #82667
closed
Passing a FAL file reference as data to the f:cObject view helper causes the creation of unwished fal-tempfiles in typo3temp/var/transient
0%
Description
We often do something like the following to generate images (image is a FAL object).
<f:cObject typoscriptObjectPath="lib.imageRenderer" data="{image}" />
We do this mainly to generate multiple versions with different resolutions, which then get chosen and loaded via javascript in the web browser.
But there is a problem:
- The CObjectViewHelper calls \TYPO3\CMS\Extbase\Reflection\ObjectAccess::getGettableProperties($data).
- The getGettableProperties method finds the \TYPO3\CMS\Core\Resource\FileReference::getForLocalProcessing method and calls it to get the property.
- getForLocalProcessing has the parameter "writable" which is true by default and thus causes the creation of a fal-tempfile in the typo3temp/var/transient directory.
Those fal-tempfiles are always unwished (at least in our case), because lib.imageRenderer is a IMAGE cObject and thus creates the temp files on its own.
I think it's generally a bad idea, to create a fal-tempfile, if someone passes a FileReference to the CObjectViewHelper.
This problem also exists in TYPO3 v7.
Updated by Susanne Moog about 7 years ago
- Category set to File Abstraction Layer (FAL)
Updated by Susanne Moog over 5 years ago
- Status changed from New to Needs Feedback
Hey and thanks for the report, I analyzed the issue a bit further.
Basically when adding an object to the cObjectViewhelper it automatically calls every public get... method available regardless of whether that method is in fact a simple getter or does more intensive computing - as it's probably originally meant to be used with simple models where that actually makes sense.
As we need to keep things backwards-compatible and getForLocalProcessing is an interface method we can't easily change things there.
There are multiple ways to tackle the issue anyhow but all I found are a bit ugly:
- Convert {image} in your example to an array with only necessary properties yourself before handing it over to the CObjectViewhelper
- Check for FileReference class in cObjectViewhelper to handle that differently (which is ugly as it would potentially mean building exceptions for single class types all over)
Do you (or anyone) have a better idea that keeps backwards compatibility?
Updated by Kai Strecker over 5 years ago
Hi,
since I created the ticket, we always pass the uid of the image as the only parameter. In the TypoScript we then fetch the image using the FILES cObject.
Unfortunately I don't have a better idea that would keep backwards compatibility. So I guess we have to tolerate this little quirk, if nobody else has a good idea.
Updated by Susanne Moog over 4 years ago
- Status changed from Needs Feedback to Closed
As nobody else had any idea I would recommend going with Kais workaround if this happens in your projects. Going to close the issue now - so we have it documented as quirky.