[CropperJS] Rotation of the image not applied at PHP level

[tjveldhuizen]

When using CropperJS in the frontend, it provides the ability to rotate images. The selected rotation angle is included in the options object passed by CropperJS. However, the getCroppedImage() method within the symfony/ux-cropperjs component does not apply this rotation to the final cropped image.

The Crop model class in the component currently lacks a direct method to retrieve the rotation information from the options array, other than through the full, JSON-encoded options string. This makes it challenging to properly process the rotation in my own code.

I had considered submitting a Pull Request to directly add the rotation logic to the createCroppedImage() method:

// Rotate (intervention/image rotates counterclockwise)
if (isset($this->options['rotate']) && $this->options['rotate'] !== 0) {
    $image->rotate(-1 * $this->options['rotate']); // Negative because intervention/image rotates counter-clockwise
}

However, implementing this directly would introduce a breaking change. Users of the bundle might already have their own logic in place to handle rotation, and this new functionality could lead to double rotations.

The symfony/ux-cropperjs component should provide a way to correctly apply the rotation specified by CropperJS in the frontend to the cropped image on the server side, without disrupting existing implementations.

What is the most suitable approach to add this functionality while maintaining backward compatibility? Here are a few options to consider:

• Add a method to the Crop model to directly retrieve options as PHP array. This would simplify access to the rotation value.
• Introduce a separate, optional method or parameter to getCroppedImage() that specifies whether or not the rotation should be applied. For example, getCroppedImage(..., bool $applyRotation = false). This would give users control and prevent a BC-break.

[Kocal]

Hi!

Indeed, that's weird the rotation feature is missing, but as you said it could be a BC if users already implemented their rotation logic.

For the BC layer, by following your idea:

1. the Crop class is marked a final, so we can add the parameter ?bool $applyRotation = false to getCroppedImage() and getCroppedThumbnail()
2. if !$applyRotation, trigger a deprecation telling the user that not applying the native rotation is deprecated, applyRotation: true must be passed (and its custom rotation logic removed if exists) and will become the default behavior in the next major version

WDYT @kbond @smnandre ?

[kbond]

Yep, that BC logic makes sense to me!