Convert images to .webp

Myusername · 2024-02-15 00:08:54

I want to convert images to .webp format at the moment I upload them in the image panel. Is there any plugin that does this or something similar?

colak · 2024-02-16 02:37:40

Myusername wrote #336664:

I want to convert images to .webp format at the moment I upload them in the image panel. Is there any plugin that does this or something similar?

Just a heads up that older macs do not support the webp format and images appear broken in the browser windows.

Myusername · 2024-02-16 06:59:26

Yes, I am aware of that. That’s why I like to use images in jpg and copies in webp. There are many ways to work around this in the frontend. However, I can’t find a satisfactory way to do this in Textpattern. I don’t know if there’s any hook that I can intercept at the moment of the image uploads to create copies in .webp or something like that. I was hopeful that there would be, but, well, I guess I’ll have to forget about it, as I don’t have much time to delve deeper.

phiw13 · 2024-02-16 08:53:46

As far as I can tell, there are no hooks currently, and I don’t a plugin exists that can extend Textpattern in some way to do this.

What I do is prepare the images locally (jpg + webp + sometimes avif), upload the jpg and then FTP the other formats. I then have a custom field on the edit image panel to “link” them and a TXP shortcode to build the output block(figure and picture inside). It is a little cumbersome… and I most often limit myself to jpg’s which more often than not sufficient.

Who knows though, in the future the option might exist, the image branch has some option, I think. But that is _future_…

Bloke · 2024-02-16 09:04:35

Myusername wrote #336669:

I don’t know if there’s any hook that I can intercept at the moment of the image uploads to create copies in .webp

There are Images panel hooks available. My smd_thumbnail plugin, for one, uses them to manage multiple copies of images.

However, as phiw13 notes, Textpattern isn’t yet geared up to allow multiple copies of the same image ID with different extensions. If you roll your own, you’ll have to manually construct things using the various <txp:image*> tags to build the components and tack on the extension by hand. It’s stored in the database and there’s only one per image, sadly. This needs a rethink as we move forward – perhaps by querying and stashing the mime type per image when they are (auto-)generated at the required dimensions.

Last edited by Bloke (2024-02-16 09:12:21)

jakob · 2024-02-16 09:06:38

I would have thought the image_uploaded callback would be the hook you need (here in the source). You could then convert to web via PHP (this perhaps) or with a corresponding library on your server.

Keep us posted if you get something nice working.

There’s also a little quick’n‘dirty htaccess snippet that will use a webp if a file is on the server alongside the jpg. See here.

EDIT: Bloke was faster again :-) but maybe the htaccess tip helps as there’s nothing to change in Textpattern.

Bloke · 2024-02-16 09:19:01

jakob wrote #336675:

maybe the htaccess tip helps as there’s nothing to change in Textpattern.

That is indeed a good workaround for now. I like that idea, albeit loading the web server with work, which means we’d need to maintain Nginx and others somehow.

I’d still prefer a core solution one day. One day…

kuopassa · 2024-02-16 23:13:05

I wrote this Textpattern plugin for creating those .webp versions. The plugin adds a new 💾 WebP link in the Edit image page.

bici · 2024-02-16 23:30:21

kuopassa wrote #336686:

I wrote this Textpattern plugin for creating those .webp versions. The plugin adds a new 💾 WebP link in the Edit image page.

Thank-you, this looks promising. I installed it but I am unable to edit any images. I notice that the plugin is installed as: kuo_webp_v0.1 copy and I am listed as the author. there doesn’t seem to be any help doc.

kuopassa · 2024-02-17 01:13:26

^ bici, this is the code that came out from ied_plugin_composer. I don’t know how to use other compiling methods…

phiw13 · 2024-02-17 01:46:18

kuopassa wrote #336688:

^ bici, this is the code that came out from ied_plugin_composer. I don’t know how to use other compiling methods…

ied_plugin_composer is, afaik, brøken in more recent of Textpattern & PHP. The good old route of using the plugin template and compiling at the command line still works fine (documentation). Bloke or Jakob might point to other methods. Textpattern 4.9-dev also has a full-fledge plugin editor build-in.

PS – based on your screengrab only, might it not be better inserting your widget after the main image – and just before the thumbnail generating area?

phiw13 · 2024-02-17 01:57:00

jakob wrote #336675:

There’s also a little quick’n‘dirty htaccess snippet that will use a webp if a file is on the server alongside the jpg. See here.

Interesting… If I understand it correctly, this checks (1) if the browser supports .webp, then (2) checks if there is an image in that format for with the same name as the requested .jpg and then (3) replace the latter with the former. Hmm, is it not a little wasteful? the action would happen on every image request…

I think I prefer my method of using a custom field on the edit images panel to establish a link between the various image formats and a little shortcode to insert the images with the required code. No additional server lookups, the whole “thing” is known upfront. (the result could eventually be cached with etc_cache ??)

kuopassa · 2024-02-17 02:26:49

Thanks to phiw13, the kuo_webp plugin is now available as a .zip package. I got that with the Textpattern 4.9-dev export tool. :-)

Myusername · 2024-02-17 04:49:27

Knowing which hooks to use seems easy to do this:

register_callback('convert_to_webp', 'image_uploaded', 'image');
register_callback('delete_image', 'image_deleted', 'image');

function convert_to_webp($evt, $stp, $id = '')
{
    $image = safe_row(
      '*',
      'txp_image',
      "id = '$id'",
      false
    );

    // Base path where images are stored
    $basePath = IMPATH;

    // File extension of the image
    $fileExtension = $image['ext'];

    // Constructs the full path of the original image
    $originalImagePath = $basePath . $id . $fileExtension;

    // Checks if the image exists
    if (!file_exists($originalImagePath)) {
        return;
    }

    // Depending on the file extension, loads the image
    switch ($fileExtension) {
        case '.jpg':
        case '.jpeg':
            $image = imagecreatefromjpeg($originalImagePath);
            break;
        case '.png':
            $image = imagecreatefrompng($originalImagePath);
            break;
        default:
            echo "File format not supported.";
            return;
    }

    // Path where the WebP converted image will be saved
    $webpImagePath = $basePath . $id . '.webp';

    // Converts and saves the image as WebP
    $result = imagewebp($image, $webpImagePath);

    imagedestroy($image);
}

function delete_image($evt, $stp, $id = '')
{
    $basePath = IMPATH;

    $webpImagePath = $basePath . $id . '.webp';

    // Checks if the WebP version of the image exists
    if (file_exists($webpImagePath)) {
        // Attempts to remove the WebP image
        if (unlink($webpImagePath)) {
          return "The WebP image was successfully removed.";
        } else {
          return "There was an error trying to remove the WebP image.";
        }
    } else {
      return "The WebP image does not exist or has already been removed.";
    }
}

In this way, we have {id}.jpg and {id}.webp. Simple, but it seems functional. I didn’t think about how the webp image would be accessed on the frontend, but it has the same URL, what changes is just the image extension, so it shouldn’t be a problem. However, the problem seems to be about the thumbnails, since looking at the URL that Jakob mentioned, I didn’t find any hook that is triggered when creating a thumbnail, only when the thumbnail is deleted. The same logic should work, and we would have {id}t.jpg and {id}t.webp.

jakob · 2024-02-17 22:11:14

Bloke wrote #336678:

That is indeed a good workaround for now. I like that idea, albeit loading the web server with work, which means we’d need to maintain Nginx and others somehow. I’d still prefer a core solution one day. One day…

phiw13 wrote #336690:

Interesting… If I understand it correctly, this checks (1) if the browser supports .webp, then (2) checks if there is an image in that format for with the same name as the requested .jpg and then (3) replace the latter with the former. Hmm, is it not a little wasteful? the action would happen on every image request…

Yes, the author does caution that it add server load and is more responsibly solved using the source tag or similar.

And an nginx equivalent would be great.

kuopassa wrote #336691:

Thanks to phiw13, the kuo_webp plugin is now available as a .zip package. I got that with the Textpattern 4.9-dev export tool. :-)

Cool, thank you! (BTW: there’s now this command-line too which will make a txt-installer from the /textpattern/plugins/plugin_name folder).

Myusername wrote #336692:

Simple, but it seems functional. I didn’t think about how the webp image would be accessed on the frontend, but it has the same URL, what changes is just the image extension, so it shouldn’t be a problem. However, the problem seems to be about the thumbnails, since looking at the URL that Jakob mentioned, I didn’t find any hook that is triggered when creating a thumbnail, only when the thumbnail is deleted. The same logic should work, and we would have {id}t.jpg and {id}t.webp.

Also cool! This was more along the lines of what I was thinking.

You’re right, there’s not a thumbnail_uploaded callback, but in your convert_to_webp{…} function, which is run when the image_uploaded callback is triggered, you could always check if there are values for $image['thumb_w'] and/or $image['thumb_h'], and if so resize your image accordingly and create a corresponding webp file with a t in the filename.

The only situation that’s then not covered is the exclusive creation of a thumbnail independently of the main image.

Might this last situation be addressed by adding a corresponding callback just after this line ?

Textpattern CMS support forum

#1 2024-02-15 00:08:54