-
-
Notifications
You must be signed in to change notification settings - Fork 370
Description
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.