Skip to content

[BUG] a single crop variant that is not named "default" is missing from the output entirely #913

Open

Description

@dvdmlln

Describe the bug

Two independent mechanisms decide what ends up in an image payload:

  1. The top level rendition is processed with ProcessingConfiguration::$cropVariant, which defaults to default. CropVariantCollection::getCropArea() answers unknown names with an empty area, so when no variant is named default, the top level is the uncropped original.
  2. processCropVariants() only builds the cropVariants map 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

  1. 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]],
                ],
            ],
        ];
  2. Render that field through FilesProcessor with a plain processingConfiguration
  3. Add an image, here a 2400×3600 one, crop it to 16:9 in the backend and look at the JSON:
    {
      "publicUrl": "…the uncropped original…",
      "properties": { "dimensions": { "width": 2400, "height": 3600 } }
    }
    The dimensions are those of the original: no cropVariants key, 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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions