Problem/Motivation
The ImageStyle class is a config entity that besides doing the config entity, also has methods that do process images into derivatives.
This is probably the result of the migration of the image system from D7.
As things stand, though, this is causing issues -
- the entity code is for instance invoking hooks
- it's difficult for custom/contrib to override parts of the image derivatives generation process, for instance to change the derivative URL/URI, or to pre/postprocess image derivatives
Several issues were filed in that respect, to list some:
#2359443: Allow creating image derivatives from an Image object
#1358896: Flexible scheme and URI for image derivatives
#2940016: Make possible to respond to image derivative creation
#1826362: ImageEffects of the same image style should be able to pass variables between them
#2685905: Refactor ImageStyleDownloadController so derivatives can be generated by contrib modules
#1903190: Allow image style derivatives of private images to be stored on the public file system
#2098247: Provide a hook for ImageStyle::createDerivative
#3218514: [PP-1] Deprecate passing path (instead of true URI) to ImageStyleInterface::buildUri($uri)
Proposed resolution
In #2359443-26: Allow creating image derivatives from an Image object, before stalling, we started discussing decoupling the config entity from the image derivative processing code.
This is implementing that:
- separate the image derivative processing methods from the ImageStyle into a plugin, that takes ImageStyle as the config entity as in input, like the source URI or the Image object directly
- deprecate the methods on the ImageStyle, leaving the code that calls the plugin methods instead
- the plugin implements a fluent API to pass the variables needed and then executes the process required, bieng determining the derivative URI, or creating the derivative image, or getting the safety token
- keeping full BC
Why a plugin?
So that the default implementation can be overridden e.g. to change the derivative URI calculation logic or to post-process an image derivative - only re-implementing the plugin methods that are necessary without touching the config entity code. But also, plugin allows to have parallel 'derivative processing engines' if someone wants that. For instance, Textimage contrib module has its own formatter and API that could leverage this plugin concept.
Remaining tasks
Review
User interface changes
None
API changes
Several methods deprecatedin ImageStyle, new plugin manager and a default plugin implemented.
Data model changes
None