Updated: Comment #0
Problem/Motivation
This is split from #2105863-7: [meta] Images, toolkits and operations.7.
In #1069140: Requirements should be provided by image toolkit image requirements will be provided by toolkit. But, starting with #2073759: Convert toolkit operations to plugins, a toolkit will have toolkit operations, implemented as plugins. A toolkit operation may have its own special requirements. There's no way to pass those requirements to image_requirements()
.
Proposed resolution
Add a new method in ImageToolkitOperationInterface
called requirements()
. Add an abstract ImageToolkitOperationBase
and implement requirements()
returning an empty array. Operations that require requirements will override the method. Collect requirements from operations in ImageToolkitInterface::requirements()
along with toolkit requirements.
Remaining tasks
n/a
User interface changes
Users will receive requirements from image toolkit operations.
API changes
- New method
requirements()
inImageToolkitOperationInterface
. - New abstract base class
ImageToolkitOperationBase
implementing empty list requirements.
Comments
Comment #1
claudiu.cristeaPostponing this till #2073759: Convert toolkit operations to plugins and #1069140: Requirements should be provided by image toolkit.
Comment #2
fietserwinWhat to do in this case:
Contrib module imagecache_actions provides the autorotate image effect that needs the EXIF extension. If a user is not planning to use that effect and the extension is missing, should it get repeated warnings?
Or can a user selectively disable image effects he is not planning to use (and thus thereby pollute the "select image effect" dropdown in edit image style and thus now also possibly the status report).
Note:
- we are planning to provide all image effects in a single module, not 1 effect per (sub-)module.
- this requirement would only hold for the GD toolkit, Imagemagick can autorotate on its own, so specifying it on the operation level seems the correct place.
Comment #3
claudiu.cristeaWhy? Maybe having a main module and submodules per effect would be a better approach?
Adding a status (enable/disable) on operation plugins would be to complex I guess.
Comment #4
fietserwinWhy?
Normally people don't mind getting a few additional image styles. It might even lead to some new ideas for image processing. furthermore a (useless) .module and .yml per effect is not what I would call good DX.
Comment #5
mondrakeBlockers are in.
Comment #6
mondrake