Repository navigation
[BUG] a single crop variant that is not named "default" is missing from the output entirely #913
Description
Describe the bug
Two independent mechanisms decide what ends up in an image payload:
- The top level rendition is processed with
ProcessingConfiguration::$cropVariant, which defaults todefault.CropVariantCollection::getCropArea()answers unknown names with an empty area, so when no variant is nameddefault, the top level is the uncropped original. processCropVariants()only builds thecropVariantsmap when the crop configuration holds more than one variant.
For a field whose TCA defines exactly one crop variant under a name other than default, both miss it: the top level renders the original, and the map is never built. The crop the editor configured appears nowhere in the JSON.
To Reproduce
- Restrict a field to a single crop variant that is not called
default:$GLOBALS['TCA']['tt_content']['types']['image']['columnsOverrides']['image']['config'] ['overrideChildTca']['columns']['crop']['config'] = [ 'cropVariants' => [ 'desktop' => [ 'title' => 'desktop', 'allowedAspectRatios' => ['16:9' => ['title' => '16/9', 'value' => 16 / 9]], ], ], ];
- Render that field through
FilesProcessorwith a plainprocessingConfiguration - Add an image, here a 2400×3600 one, crop it to 16:9 in the backend and look at the JSON:
The dimensions are those of the original: no
{ "publicUrl": "…the uncropped original…", "properties": { "dimensions": { "width": 2400, "height": 3600 } } }cropVariantskey, and no URL that reflects the 16:9 crop.
For comparison: renaming desktop to default makes the crop the top level image (and the original unreachable instead), and adding any second variant makes the map appear.
Expected behavior
A configured crop variant should be reachable regardless of its name and regardless of how many variants are configured.
Background and suggestion
The > 1 threshold is reasonable as long as the single variant is the top level image — the map would then only duplicate it. That assumption holds for the name default and breaks for every other name.
The underlying reason is that "the top level rendition" and "the crop variant named default" are the same slot. The map is therefore the only way to reach anything else, which is what gives the threshold this side effect. It also means there is no configuration that yields the uncropped original once a default variant exists — the only way is to make sure no variant carries that name, which is an accident of naming rather than a setting.
Making the original addressable in its own right would resolve both sides, e.g. a processingConfiguration.includeOriginal = 1 that adds an original node (url + dimensions) next to cropVariants, or a reserved cropVariant value meaning "no crop area". The map could then be emitted from one variant upwards without duplicating anything a consumer could not otherwise get.
I am happy to prepare a PR for this. As the fix depends on how you would like the original to be addressed, and on whether the threshold should change along with it, I would rather agree on the direction with you first than send something unsolicited.
TYPO3 version and TYPO3 Headless version
- TYPO3 13.4
- EXT:headless 4.8.1
The code paths are unchanged in v5.0.0-rc2.
Activity