Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Updated: Comment #0
Part of #2105863: [meta] Images, toolkits and operations.
Problem/Motivation
In the process of revamping the image system (see #2105863: [meta] Images, toolkits and operations) we've found that, before Image operations (resize, crop, rotate, etc.) are actually applied, there are some toolkit-agnostic tasks that are performed against operation arguments. Those tasks are referring mainly to normalizing dimensions, coordinates, etc. Example: \Drupal\Core\Image\Image::scale() effect is computing the height when only width is provided. Partially those tasks are deferred to an utility component: \Drupal\Component\Utility\Image but most of this algebra is still performed in the image layer.
This is inconsistent now. We can move this processing into toolkit operations but that would duplicate the code when adding new toolkits. We need a way to standardize all those tasks in the abstract Image layer and send the arguments already prepared to toolkit operations.
Proposed resolution
The solution to be decided and the issue summary to be updated!
Remaining tasks
User interface changes
API changes
Related Issues
| Comment | File | Size | Author |
|---|---|---|---|
| #2 | image-geometry-2108307-2-combined.patch | 85.86 KB | claudiu.cristea |
| #2 | image-geometry-2108307-2-do-not-test.patch | 20.28 KB | claudiu.cristea |
Comments
Comment #1
fietserwinIt is not only "normalizing dimensions, coordinates, etc". It is also processing input as entered on the forms to straight numbers. Think of cropping angle: center-center, center-bottom, or setting a new width: 90%, width - 20. The latter are quite effect specific as the effect determines what may be entered in its form fields.
So, yes there are probably a few calculations that can get moved, but a large part will stay in the effect. Moreover, contrib will come with enhancements, especially enhancing what can be filed in (I guess that the 2nd example currently is not allowed), where should contrib place it? (The answer is: contrib should keep it locally, thus within its own effects.)
But let's see what calculations we can find.
Please postpone working on this until the large API changing issues have landed.
Comment #2
claudiu.cristeaThis is just a proof of concept. Is fixing also #2109375: Provide sane defaults for toolkit operation arguments.
Approach: The image geometry abstract layer is provided using the Symfony event dispatching/subscribing mechanism. Modules (core does it too) are able to subscribe to 3 events: DEFAULTS, PREPARE and ALTER. First I was tempted to implement the standard Drupal hook mechanism but ended with event subscriber/dispatcher.
Modules that want to provide operation arguments defaults or prepare arguments need to add an event subscriber by extending
\Drupal\Core\Image\ImageOperationArgumentSubscriberBase.This patch is build in top of #2073759: Convert toolkit operations to plugins. A combined patch is available for testing purposes.
This needs an agreement/amend or proposal of other approach. Let's discuss this.
Comment #4
claudiu.cristeaThings that we should take care here, as soon as #2073759: Convert toolkit operations to plugins is in:
\Drupal\Component\Utility\Image.Comment #5
claudiu.cristeaThe scope of this issues has moved to #2073759: Convert toolkit operations to plugins.
The arguments preprocessing is handled now by
ImageToolkitOperationInterface::prepare().Closing this as duplicate of #2073759: Convert toolkit operations to plugins.