Provide a hook for ImageStyle::createDerivative

Hey @mondrake, isn't this related #1826362: ImageEffects of the same image style should be able to pass variables between them?

Check also my comment from #1826362-7: ImageEffects of the same image style should be able to pass variables between them. I wonder how can we merge these 2 issues. Definitely I see the need that effects of the same image style should be able to pass variables between them. I just want to find a more modern way to do this without placing hook invocations all over the code.

+++ b/core/modules/image/image.api.php
@@ -38,6 +38,36 @@ function hook_image_style_flush($style) {
+function hook_image_create_derivative($style, $original_uri, $derivative_uri) {

It would be good to typehint the image style in the actual function signature.

Why add a parameter at all?
By passing info via a parameter construct, both effects (the "setting" and "receiving" one) become dependent from each other, while only the setting one should have to know about this. With getConfiguration() and setConfiguration() on ImageEffectInterface (being a ConfigurablePluginInterface), we can already hack into other effects if we have access to the effect.

Thus if a "special canvas" effect wants to influence the (background) color of a subsequent text, resize or rotate effect, that effect should be happily unaware of its context (no way that the core rotate effect is going to use a parameter set by a contrib effect). So, it should be the special canvas effect that alters the color value in the configuration of the rotate, text or whatever effect.

Aside: if you insist on adding a parameter property, make it a key-value store and you don't have to add any adding, setting or deleting method yourself, not in the interface, not in this class. Compare my patch in #2168511: Allow to pass save options to ImageInterface::save.

What context should be passed to an effect?

• We (imagecache_actions) have had (valid) feature request in which there was a wish to alter the target URI (change image format). So is only passing in the image style enough?
• How sure are we that an image effect will never be used outside an image style? An example of an image effect outside an image style could be resizing an image field directly on upload. That one is now calling the resize operation on an Image directly, whereas, IMO, it should be calling an image effect because an image effect should do the (toolkit agnostic) calculations.
• If we are absolutely sure about the tie between ImageStyle and ImageEffect, I think that a (protected) property $imageStyle on ImageEffect would be more appropriate.

So are we passing in specific context or too few context? My idea for now: we can add the imageStyle parameter to applyEffect, but make it optional by adding "= NULL".