Bug #91675
closed
Processed files are not properly re-processed when a crop is defined and the file does not exist
Added by Helmut Hummel over 4 years ago.
Updated about 4 years ago.
Description
steps to reproduce:
- create and image content element with cropped image
- render frontend
- delete processed file only
- render frontend again
- Related to Task #91571: Harden internal state handling added
- Status changed from New to Under Review
- Related to Feature #65585: Add GUI to enable the editor to set the cropping area for an image added
- Related to Story #75880: Add art direction capabilities to BE added
Actually that seems to be a regression from #75880 - prior to that crop
was handled as string and then became the Area
object.
LocalCropScaleMaskHelper::process
gets the configuration array having ['crop' => Area(...)]
- it performs a
json_decode(Area::__toString)
in order to retrieve the properties
- issue #91571 revealed this design flaw by disallowing arbitrary classes during deserialization
Oliver Hader wrote:
Actually that seems to be a regression from #75880 - prior to that crop
was handled as string and then became the Area
object.
I agree. We can fix the initial regression and json_encode the crop property before serializing the configuration.
That actually was my first approach when working on a fix. However this would invalidate all processed files,
because the configuration hash would change.
BackendUtility::getThumbnailUrl
(expects JSON) via ThumbnailViewHelper
and does not pass crop
information at all, since it's given as Area
object. This would be another candidate when switching to plain JSON for passing the cropping information...
- Status changed from Under Review to Resolved
- % Done changed from 0 to 100
- Status changed from Resolved to Closed
Also available in: Atom
PDF