I have a “legacy” business website I wish to keep online for archival purposes. The problem is that in building this site over a period of a decade we were fairly particular about keeping a lot of the images on it good enough for print quality as this was a useful service to customers. A decade later and our wp-content/uploads folder weighs in at 30GB.

Sure, that’s not a tonne of data by modern standards … but I just want to host this on a little personal VPS and don’t want to pay for extra storage just for the sake of it.

Obvious modern solution? Convert all the PNG images to WEBP.

Should be easy, right? Look, there’s a load of plugins for this! Oh, wait, no, nearly all of them make an extra copy of the images in WEBP format rather than convert the existing files. I can understand why, but at least give me the option? Mostly it’s complex overlays of your existing media. Some even try to monetise it – how about using a third party service to “optimise” your images?! Madness… I’ve got a perfectly good ImageMagick thanks. The one plugin that might have done what I wanted wasn’t maintained and didn’t work on my up to date WordPress install.

So… down to fundamentals. Manually convert the files with a shell script, and then poke at the database. How hard can it be? It turns out: not super hard. I’m not sure I’d recommend this be copied verbatim on a production site (use a staging copy at least) but it seems to have worked for me. My biggest issue was thumbnails and the fact they store the data for these in a manky string encoded format in the database, but for this task at least there’s a plugin to help.

Step 1: Manually convert all PNGs to WEBPs:

$ cd wp-content/uploads
$ wget https://imagemagick.org/archive/binaries/magick
$ chmod 755 magick
$ for x in $(find 20* -iname '*.png');
  do
     ./magick "$x" -quality 80 "$(dirname $x)/$(basename $x .png).webp";
  rm -v "$x";
  done | tee magick.log

That took about 45 minutes to crunch my PNGs and after this my 20* folders had shrunk from 27GB to 5.5GB! Nice.

But of course my media files in WordPress are all broken now!

Step 2: Go hit the database with a hammer…

$ mysql <dbname>
mysql> update jgbs_wp_posts
       set
         guid =
           regexp_replace(guid, '\.png$', '.webp'),
         post_mime_type =
           "image/webp"
       where
         post_mime_type = "image/png"
         and
         # only PNGs in uploads/20xx dirs
         guid like "%uploads/20%.png";
Query OK, 13850 rows affected (1.27 sec)
Rows matched: 13851  Changed: 0  Warnings: 0
mysql> update jgbs_wp_postmeta
       set
         meta_value =
           regexp_replace(meta_value, '\.png$', '.webp')
       where
         meta_key = "_wp_attached_file"
         and
         # only PNGs in uploads/20xx dirs
         meta_value like "20%.png" 
         and
         post_ID in (
           select ID from jgbs_wp_posts
           where post_mime_type = "image/webp" )
Query OK, 0 rows affected (5.48 sec)
Rows matched: 13850  Changed: 0  Warnings: 0
mysql>

What you should find now it the key media URLs work from the media library, but all thumbnail/resize versions are broken images. Rather than muck around processing WordPress’s horrid string encoding of the metadata for these files I found a plugin that can force the regeneration of all thumbnails. This takes a good long while to run, but cost me zero time coding or mucking about and just did its thing.

Step 3: Install plugin to regenerate resized images

This is the plugin: Force Regenerate Thumbnails

When it is installed find in your WordPress admin:

Tools > Force Regenerate Thumbnails

JPG files?

Yeah, you can do them too… just replace “png” above with “jpg” or “jpeg” where required – noting that typically the file name is “jpg” but the mime-type is “image/jpeg” (but you could have “jpeg” file extensions present too I guess.) I repeated the above process for JPG files and further shrunk the data size down from 5.2GB to 3.2GB.

DANGER WILL ROBINSON! DANGER!

I hope this post might be helpful to someone, but it comes with a big caveat… there are errors. This isn’t perfect. I’ve found a few cases where files ended up missing, and I had to copy them back in. No biggie for me, this is just an archive. (I do have the original data in backups in the unlikely case I ever want it.)

Definitely use a sandbox, don’t play in production, and test the results!