Maybe relevant: PHP Version 8.2.18

Thanks for your report @rmens, this only seems to occur when you don't set the third parameter in resize:

<img src="{{ post.thumbnail.src|resize(1200, 300, 'right') }}" />

leads to a correct image, although cropped from the right of the image.

The error seems to lie in this logic:

        if (!$crop || $crop === 'default') {
            return [
                'x' => 0,
                'y' => 0,
                'src_w' => $src_w,
                'src_h' => $src_h,
                'target_w' => $w,
                'target_h' => $h,
            ];
        }

https://github.com/timber/timber/blob/2.x/src/Image/Operation/Resize.php#L20

which has been changed from the 1.x version

edit:

removing || $crop === 'default') from the linked block of code seems to fix the issue. That code of block is meant to force a image in a particular set of dimensions, not cropping it. Can you confirm that works for you as well @rmens ?

This change was introduced in 18bf358 to fix integration tests from what I can see,

Yes that works @Levdbas! It would be most logical to default to a center crop when a third parameter isn't specified. Alternatively, we could update the documentation to mandate a third parameter for resizing, although that may not be the most practical solution.

To me, this sounds like a bug if it changed from how it used to be in v1.

I would first fix the issue and then we could also discuss whether changing the default would make sense. But that would be a breaking change for which we have to provide the proper upgrade information.

So, I’m wondering, rather than removing || $crop === 'default'), shouldn’t it be || $crop === null)? Because the way I read the code, the default value for $crop is null when not provided.

I’m wonder what the default behavior in 1.x was. That was probably center cropping and not top right cropping.

$dest_ratio = $w / $h;
$src_wt = $src_h * $dest_ratio;
$src_ht = $src_w / $dest_ratio;
$src_x = $src_w / 2 - $src_wt / 2;
$src_y = ($src_h - $src_ht) / 6;

Well this was the default behaviour in 1.x and should have also been de the default behavior in 2.x were it not for the shortcircuit bug that was introduced.

What this exactly does however is kinda hard to wrap my head around :D This could use some documentation. Its is also kind of strange that you can pass a default option but that is not an actual option in the codebase that runs something explicitly. It just prevents the running of a specific crop behaviour.

According to ChatGPT it's a center-ish crop

$dest_ratio = $w / $h;
This line calculates the aspect ratio of the desired output image, where $w is the width and $h is the height that you want the cropped image to have. The aspect ratio is the ratio of width to height.

$src_wt = $src_h * $dest_ratio;
This line calculates the width of the crop area from the source image. It uses the height of the source image ($src_h) and multiplies it by the desired aspect ratio ($dest_ratio). This ensures that the width of the crop area maintains the aspect ratio of the target image dimensions.

$src_ht = $src_w / $dest_ratio;
Here, the height of the crop area is calculated using the width of the source image ($src_w) divided by the desired aspect ratio. This also helps in maintaining the aspect ratio consistency with the target dimensions.

$src_x = $src_w / 2 - $src_wt / 2;
This line determines the horizontal starting point ($src_x) of the crop area. It centers the crop area horizontally within the source image. It does this by taking half of the source width ($src_w / 2) and subtracting half of the calculated crop width ($src_wt / 2).

$src_y = ($src_h - $src_ht) / 6;
Finally, this line calculates the vertical starting point ($src_y) of the crop area. The formula takes the difference between the source height and the crop height, subtracts it from the source height, and then divides by 6. This is a somewhat unusual choice and suggests that the crop area is intended to be closer to the top of the image rather than being perfectly centered vertically.

I remember that Jared once mentioned that the default crop is not fully from the top, but in the upper part of the image. This is a cropping area that works well in a lot of cases, and mostly works better than just a top or center crop.

When I was still using 1.x without an off-site image resizer (which lead to not seeing this bug with the upgrade to 2.x of my theme) the crops always looked good. So cropping from the upper part of the image seems to be good choice imho. Documenting that behavior would be a win.