The transform to extend does not need to be a named transform.
Extending a transform returns a new transform object.
With all of this, I feel it's safe to close this issue.
This will be a part of Craft 3.5.
All 17 comments
This is a great idea - webp has wide adoption at this point and is essentially a requirement for a good page speed score. The plugins available right now are great; but, can be a bit overkill if we're just looking to support webp.
Should this feature be implemented, I think there would need to be some additional Twig helpers to ensure the browser supports webp and the asset should be converted to a webp (i.e. not a gif)
@wrux For what it's worth, Imager has evolved into Imager X
This has come up before (#1545), but I agree at this point we should have built-in support for it.
Will this also allow for the creation of png, jpg or gif from a webp as part of a transform? I'm currently having to use a dedicated second field using png's for this in conjunction with picture to support Safari. Unless there's a way I can do this already. I've looked at a few plugins but seems like overkill for my needs. Setting the transform to output as a png doesn't seem to work at the moment. Thanks.
@brandonkelly @andris-sevcenko Adding this feature for 3.5 would be awesome!
@brandonkelly
Will there also be helper functions for detecting webp server support and webp browser support, like these imager plugin has?
Just a sidenote: Transforming images to webp isn't mentioned in the docs, but I've been transforming jpeg images to webp for a while now and it seems to work well in Craft as long as your server has the required php extensions (gd libraray if I'm not mistaken).
Using image.getUrl({ width: 800, height: 600, format: 'webp' }) in my templates created a webp version from a jpeg image just fine and has a noticeable decrease in filesize.
@timrosskamp @brandonkelly
Just tested it - and indeed, it works!
So, why it is in open issues? :)
There are browsers that don't support it yet, and you'd need to generate fallback images for them, anyway. This leads to having two transforms created in the control panel to generate the same image in two different formats - it is not a pattern we'd like to encourage. Everything will be fine until someday somebody forgets to update one of the transforms.
So, we'll have to discuss this internally a bit to figure out the _best_ approach here. For now, you can still specify that directly in templates using unnamed transforms, keeping in mind that the server might not support it.
@andris-sevcenko
About browser without webp support - personally, I just use unnamed transforms and <picture> element with two <source> elements - one for webp, one for another format. Sources have type attribute set, so browsers can pick format they support. For example:
I guess the only thing we need is some function that would inform us if the current server supports webp - like serverSupportsWebp that Imager (x) uses.
By the way, I remember that some time ago webp transforms didn't worked in native Craft. Was this support added recently?
By the way, I remember that some time ago webp transforms didn't worked in native Craft. Was this support added recently?
The support is determined by underlying capabilities of GD/Imagick (whichever Craft is using), so it's probable that your server configuration has changed since then.
About browser without webp support - personally, I just use unnamed transforms and element with two elements - one for webp, one for another format. Sources have type attribute set, so browsers can pick format they support.
Right, this is possible and doable with unnamed transforms and you can reduce transform setting duplication in the template with Twig, but to pull this off with a _named_ transform (which is the real issue here, I think), you would have to create two transforms in the control panel, which is far from ideal.
I guess the only thing we need is some function that would inform us if the current server supports webp - like serverSupportsWebp that Imager (x) uses.
That's not related to the exact issue here but makes total sense to me. I'll make sure this makes it into Craft, soon!
to pull this off with a named transform (which is the real issue here, I think), you would have to create two transforms in the control panel, which is far from ideal.
That's a good point. A possible solution could be an option to override the named transform in your template. For example:
That way we avoid the duplication of named transforms.
That's not related to the exact issue here but makes total sense to me. I'll make sure this makes it into Craft, soon!
Great! I'm working on plugin that simplifies <picture> element creation, and such function would simplify my code a bit, I would not need to do it manually.
Alright.
@piotrpog a04df43dc17ac2ae26898d37e24cc92891eea65d adds the getSupportsWebP() method to the Images service.
@timrosskamp I just implemented your suggestion for extending transforms.
So, as of a04df43dc17ac2ae26898d37e24cc92891eea65d, it's possible to do
The transform to extend does not need to be a named transform.
Extending a transform returns a new transform object.
With all of this, I feel it's safe to close this issue.
This will be a part of Craft 3.5.
Just tweaked the way you override transform settings a bit. Now instead of specifying the overrides as a 2nd argument on getUrl(), you can specify it inline from the 1st argument, like so:
@brandonkelly Could this be extended to the new getSrscet (https://github.com/craftcms/cms/issues/5774) method and possibly the transform eager loading?
Can open as a separate issue if you prefer.
@NixonGit Probably, if you could open a new issue that would be helpful though.
Most helpful comment
Alright.
@piotrpog a04df43dc17ac2ae26898d37e24cc92891eea65d adds the
getSupportsWebP()method to theImagesservice.@timrosskamp I just implemented your suggestion for extending transforms.
So, as of a04df43dc17ac2ae26898d37e24cc92891eea65d, it's possible to do
With all of this, I feel it's safe to close this issue.
This will be a part of Craft 3.5.