127.0.1.1 {{fqdn}} {{hostname}}

I have no idea what it’s even trying to do with that.

What it does do is break a lot of things, because while 127.0.1.1 is a valid address (albeit weird to use instead of the canonical 127.0.0.1), in a standard Plesk system Nginx (that sits in front of Apache typically) is configured to listen only on the network interface(s) associated with your web server’s public IP address(es), not localhost¹. So if you try e.g. curl mydomain.com from inside your server hosting that very domain, you get a connection refused error (or it just times out with no response, depending on firewall settings).

The way I found out about this was when WordPress’s “cron” system silently stopped running tasks (because I use a real cron job to trigger it periodically, rather than relying on WordPress’s flaky built-in system). I subsequently also noticed that Broken Link Checker mistakenly reported every link within my own site as broken.

The solution

…is fairly simple – modify the template to remove the offending line. You then have to either reboot or similarly manually modify /etc/hosts to actually apply the fix.

If for some reason you cannot do that, there are potentially workarounds. For example, for curl commands you can make curl navigate around the problem this like:

In a non-Plesk environment you might also be able to just change the Nginx configuration (somewhere under /etc/nginx). That’s ill-advised for Plesk-operated servers as Plesk will inevitably revert your changes (and as far as I can tell there is no configuration option, or workaround otherwise, to make Plesk configure Nginx to listen on localhost as well 😕).

1. I suspect this is more a side-effect than intentional. Plesk chooses the interface only implicitly, when it specifies that it listens on specific addresses – those assigned to the website in question (Nginx can host multiple otherwise unrelated websites, and each is configured independently within its settings). Since Plesk supports hosting multiple websites, each with potentially different IP addresses, it makes sense that it would want to keep them separate. Otherwise, in a shared hosting situation you could connect to the IP address for somehost.com yet issue a HTTP request for unrelatedhost.com and actually get a response, which is weird, at least. ↩︎

WordPress relies on either ImageMagick or GD for its ability to read & write images. It prefers ImageMagick, as ImageMagick supports a much wider range of files, tends to be faster, and some assert that it produces higher quality files.

ImageMagick 6 was superseded by ImageMagick 7 nearly a decade ago. Version 6 is officially in legacy mode and while still technically supported (in a long term support sense) it generally receives only bug fixes – it fundamentally lacks many features, and most crucially it doesn’t support modern image formats correctly, such as AVIF¹.

Additionally, ImageMagick is a common source of serious security exploits. It’s very important to run the latest version (or very close to) at all times, to have as many critical bug fixes as possible.

Note that, depending on how you operate your WordPress site(s), you may or may not be seriously exposed to ImageMagick security problems. For simple single-author sites, where only the admin can upload anything to the site (images or otherwise), it’s arguably not a huge concern. But for more complex sites with multiple contributors – or worse, sites which accept images from general users or the public – using an outdated ImageMagick release is a serious risk.

Why isn’t this easy?

On some Linux distros, and when Plesk isn’t involved, it is easy – you just apt install imagemagick or yum install ImageMagick or at worst download the RPM and install that. Generally that installs ImageMagick 7 (and if not the very latest release, at least a recent one). You subsequently just run update on your package manager periodically and ImageMagick is kept reasonably up to date.

Ubuntu does not like ImageMagick 7, for some reason. No version of Ubuntu supports it officially, in the sense that it is not in any of the official package repos. If you apt install imagemagick, you’ll get version 6 – and not even a recent version 6, but 6.9.11-60 which is over three years old! That’s three years of well-known bugs – some of them potential security exploits.

So, unfortunately, the only way to install a modern version of ImageMagick on Ubuntu is manually.

Consequently, you have to manually install a suitable version of Imagick as well, and you have to do it into Plesk’s special PHP installation(s).

It took me several hours to figure all of this out, which is why I’ve written this post – so that nobody else ever has to.

The procedure

If you run into any issues, please let me know in the comments section at the bottom of the page. I endeavour to correct any mistakes, oversights, or confusion.

Note that most of these commands must be run as root. Either run them inside a root shell (e.g. su, or sudo bash) or prefix them with sudo.

Install ImageMagick 7

Fortunately, ImageMagick Easy Install (IMEI) exists to greatly simplify this step.

First, as a precaution IMEI insists you remove any existing ImageMagick installation(s). Manually installing a build of ImageMagick over the formally-packaged Ubuntu version could cause problems.

Next, download and install ImageMagick:

By default it’ll install a very recent version – usually the very latest release – but you can customise it if you wish with the --imagemagick-version argument to imei.sh.

Note: I had to use the --force argument to get imei.sh to actually build & install all the components – for some reason it skipped the dependent libraries (for AVIF & JXL support) and just installed ImageMagick, without AVIF and JXL support. Try it without first, since that’s supposed to be the happy path, but check that it says [OK] for every item; that nothing is [SKIPPED].

Once it’s completed successfully – which can take tens of minutes if you have a wimpy server such as is often used for WordPress hosting – double-check that you have a good version installed:

At time of writing that says 7.1.1-26 for me, but of course for you it’ll probably be something newer. You can consult ImageMagick’s download page to find out what the newest version is.

Install Imagick

First, download Imagick:

Next, you need to set the version string to the actual version – otherwise, at the very end of this process, you’ll find that WordPress quietly refuses to use ImageMagick / Imagick! Do that by editing the php_imagick.h file. You should see, somewhere near the top of the file, something like:

#define PHP_IMAGICK_VERSION    "@PACKAGE_VERSION@"
#define PHP_IMAGICK_EXTNUM     30700

You need to change that first string to the version declared on that second line. 30700 means version 3.7.0. So in my case I replaced "@PACKAGE_VERSION@" with "3.7.0".

Now you need to determine where the relevant PHP installation is – the version that Plesk is using to run WordPress for your website(s). You can find that out in various ways, perhaps the simplest being to log in to your Plesk dashboard, open the “Websites & Domains” section, and look at the PHP version listed for each website of interest.

In my case I’m using PHP 8.2. So now I know that the PHP install of interest is located at /opt/plesk/php/8.2/ (Plesk installs all its versions of PHP in /opt/plesk/php). I’ll use that in the subsequent commands shown here, but make sure to adjust that to suit whatever version of PHP you’re using.

To build Imagick, you need the PHP developer tools – for your particular Plesk PHP installation(s). e.g. in my case I’m using PHP 8.2, so I need to run:

Now you need to configure the Imagick build:

Don’t forget to change “8.2” to your version of PHP, if it’s different!

It should only take ten seconds or so to configure, build, & install Imagick.

Now, rename the built library so that Plesk updates won’t clobber it:

Lastly, although it’s technically optional, it’s nice to fix the permissions of the installed library:

Load Imagick into PHP

Annoyingly, PHP won’t automatically notice Imagick is installed – you have to tell it so, manually. Though this is pretty easy to do. There are a few ways to do it, the easiest being through Plesk: go to the “Tools & Settings” section of your Plesk dashboard, click “PHP Settings” (from the “General Settings” category), then click on the relevant handler in the list (e.g. “FPM application”). If you’re not sure which is relevant, look for a non-zero number in the “Domains” column.

Click on “php.ini” to switch to that tab, and you should see a text field containing the contents of the relevant php.ini file. Somewhere in this file – technically anywhere, but I like to scroll down to the section where all the other extensions are listed – you need to add the line:

extension=imagick_custom.so

Then, click the “OK” button to save your changes.

In theory Plesk will now restart the relevant server daemons, to have them pick up the change, but if you subsequently find that WordPress doesn’t seem to see the new ImageMagick installation (or you edited php.ini directly from the command line), you can give it a more forceful shove:

You should now be set – you can test your upgrade in a variety of ways, such as:

• Try uploading an image in a format, or using features such as animation or transparency, that wasn’t previously supported. e.g. AVIFs. Note that you might need additional WordPress plug-ins to enable use of the new formats, e.g. AVIF Support or any of the numerous SVG support plug-ins.
  
  See also my earlier post on my Image workflow for WordPress – particularly the section on AVIF.
• Check phpinfo – in your Plesk dashboard, go to your website(s) in the “Websites & Domains” section, click “PHP” (under the “Dev Tools” category), then click the subtle “View the phpinfo() page” link to the right of the first pop-up menus. Search for “imagick” – you should find an entry for it, with a table of plug-in information such as its version, the version of ImageMagick being used, and the file formats supported.

Addendum: updating ImageMagick & Magick

You can of course just repeat all the above steps to perform a fresh install, incorporating any updates since you last installed everything. But you can save a little time by keeping the imei and imagick folders around, and just doing:

1. git pull --rebase in each, then re-run their respective build commands. For Imagick you’ll probably have to git stash first, in order to do the git pull, and then restore your version string patch with git stash apply.
   
   Don’t forget to check if you need to update the version string in php_imagick.h.
2. Rename the built imagick.so again, and fix its permissions.
3. Restart the PHP daemon.

1. Some versions & builds nominally support AVIF, but this support is almost by accident – what they actually support formally is HEIF, for which they use libheif, which can be built with AVIF support as well, but in my experience that support is buggy and incomplete – e.g. alpha channels are not supported. ↩︎
2. Alas I don’t actually know if / how often it was successfully exploited, as far as Google saw. I have to imagine it was not uncommon, though, given the large attack surface that is ImageMagick’s APIs and image plug-ins, not to mention how lucrative a target Google is. ↩︎

WP Dark Mode had ‘flashing’ problems, though – where the page loads first in normal, ‘light’ mode and only then re-renders into dark mode. Possibly just a result of interference by WP Fastest Cache, which I later realised was probably deferring WP Dark Mode’s JavaScript files past initial page load. Irrespective, I found that Dracula Dark Mode worked better – though still not flawlessly in this regard – so I switched to that.

However, I eventually noticed that Dracula Dark Mode adds 415 KiB to every single page load, with its JavaScript and CSS files. That doubles the total size for some pages, even with WordPress & Jetpack bloating the baseline. Its own analytics suggested that basically nobody uses dark mode, at least amongst people that browse my website. So that does not seem like a reasonable trade-off.

Thus, with a bit of sadness, I’ve disabled the plug-in. Maybe in future the plug-in’s authors can find a way to optimise things such that its JS & CSS is only loaded if dark mode is actually in use.

Turns out, though, that almost no websites support dark mode anyway – I discovered as much while having dark mode enabled during my own testing. So it doesn’t seem like I’m an odd one out, and my tiny website is not going to start any trends. From the looks of it the way most people actually tackle the web in dark mode is through browser plug-ins which basically do the same thing as the WordPress plug-ins, but for every website. And only users actually interested in dark mode have to pay their price.

I haven’t tried any of them, but there’s numerous Safari plug-ins for dark mode, e.g. Dark Reader, Noir, Dark Mode for Safari, etc.

It does mean I can’t do image substitutions for dark mode users, but I couldn’t find any dark mode WordPress plug-in that works correctly in that regard anyway (they seem to do naive URL substitutions, without accounting for images having various replicas of different sizes per WordPress standard practice, and certainly without supporting Perfect Images). It’s also rare that I have a dark mode version of an image available – though I can at least be better about using actual alpha channels rather than fixed white backgrounds, going forward.

My input images generally fall into three categories:

1. Screenshots, as PNGs.
2. Random 3rd party images, typically as JPEGs but sometimes PNGs or other formats.
3. Photos, as Nikon NEFs.

Some of these formats can be published directly into WordPress – mainly PNG and JPEG – but not all, and neither PNG nor JPEG are the best file formats for anything these days. In terms of compression efficiency, there are numerous superior formats – JPEG 2000, JPEG XL, HEIF¹, WebP, AVIF, etc.

Using an appropriate and efficient format – and suitable compression quality settings – is important to me to save disk space, save bandwidth, minimise page load times, and ensure images are seen the way I want them to be (re. lossless vs lossy).

Best image codecs

Legacy options

PNG and JPEG are supported in practically any & every web browser still in real use today. As is GIF, technically, although it’s strictly inferior to PNG [for static images] and actual video formats [for moving images]. It certainly is possible to still use them, but it wastes storage space & bandwidth, and hurts page load times.

That said, PNG is not the worst option if you use appropriate tooling to maximise the compression. The level of compression you achieve ‘out of the box’ with most applications – e.g. Photoshop, Apple’s apps, etc – is actually quite poor. There are numerous specialised tools which can greatly improve the compression. I recommend ImageOptim – it’s free and open source. It typically reduces PNG files sizes by a further 20% to 50% (depending on how much fine detail or noise the image contains) without any loss of image quality. It actually makes PNG competitive with the modern formats to a degree, although ultimately still not the best.

It’s quite configurable, including with regard to stripping metadata or not – although, alas, it offers no nuance in this, such as keeping copyright metadata but removing spurious camera metadata, or geolocations.

It’s also possible to use such specialised tools for lossy PNG compression. PNG is not inherently lossy, but by manipulating the image before compression it is possible to greatly improve its compressibility. e.g. by reducing the colour palette, adding or removing dithering, or simply removing fine detail. Various tools – including ImageOptim – will do this for you if you wish, although be warned that the resulting image quality is unpredictable and sometimes very poor (exhibiting obvious colour changes, banding, or visual artefacts otherwise).

The example below is a fairly typical “good” result – the file size is cut by 70%, but the lossy PNG compression has introduced noticeable banding and dithering. You might consider it worth the trade-off but consider that a lossy WebP version, also saving 70% on file size, doesn’t have any noticeable image degradation. And an AVIF version with similar image quality cuts the file size by 80%. So while you might think it’s neat to use a ‘lossy’ PNG and get – by PNG standards – dramatically higher compression, you’re probably better off just using WebP or AVIF.

Non-options

Despite its age JPEG 2000 is surprisingly good in my experience – I used it many years ago on this website for my Raw converter comparison as an alternative to TIFF and PNG, as it yielded file sizes about half that of PNG. It’s competitive even with newer formats like WebP and AVIF. JPEG XL is purportedly even better again. Alas, no browser other than Safari supports either of them.

HEIF exists and is “modern” but isn’t really in the same ballpark – while it is better than JPEG, that’s a low bar; it achieves worse results even than JPEG 2000, a codec that’s twenty years older. Its only claim to any fame is that it’s the native source format for many photos today, thanks to its use on Apple iDevices. In any case, the only current-version web browser which supports it is Safari.

Viable options

The only modern format which is universally supported² is WebP.

AVIF is nearly universally supported, with the unfortunately notable exception of Edge.

I choose to use AVIF nonetheless, as my audience are unlikely to be using Edge anyway, since they’re unlikely to be using Windows at all. I also like to assume that Edge will, eventually, get with the program – although the fact that AVIF support was apparently incorporated in versions 114 to 117, but then removed, is concerning.

So those are the two options, basically. For better or worse, neither one is strictly superior to the other.

It is case-dependent and a little subjective as they have noticeably different methodologies:

• AVIF tends to be heavy-handed with ‘noise’ removal, which seems to be a significant part of how it achieves better compression.
• WebP will more faithfully preserve noise (and artefacts from earlier lossy compressions), which can be counter-productive.

AVIF really excels – compared to WebP and earlier codecs – with more aggressive compression settings. It’s much better under tight file size constraints. It also performs particularly well for images which aren’t so clean to begin with – where they do have some actual image noise, or visible compression artefacts from an earlier lossy compression stage, or otherwise fine details that aren’t important to preserve.

WebP behaves more “traditionally” – like JPEG – with regard to increase blockiness and banding as you crank up the compression. AVIF does a much better job of degrading image quality more ‘smoothly’ across the image – so that particularly bad, noticeable artefacts don’t develop as easily. Even while it preserves more genuine detail.

WebP is more competitive with high quality settings or high quality, ‘smooth’ images (e.g. screenshots or computer renderings). In lossless mode WebP universally outperforms AVIF, often by a significant margin. In fact even PNG typically outperforms AVIF for lossless compression!

I’ve also noticed that WebP is substantially better at compressing repetitive patterns (even if they’re not perfectly identical).

AVIF seems particularly good at reducing visible artefacts resulting from JPEG over-compression, and in avoiding prominent compression artefacts in general – such as in the example below, where the file sizes are very similar (14 KB for AVIF, 13 KB for WebP) but AVIF does more with it – preserving more genuine detail such as in the camera lens and IR sensor even while doing a better job of removing the JPEG artefacts (noise, blockiness, and banding).

While generally I avoid re-compressing from an already lossy source since it tends to just compound the compression artefacts, AVIF can be useful for replacing low-quality JPEGs when you don’t have a quality original available. It can actually improve subjective image quality – by correcting JPEG artefacts – even while substantially shrinking the file size.

Image format conversion

There’s basically two schools of thought on converting images to their serving format – do it in advance of uploading the image to WordPress, or have WordPress do it (via one or more plug-ins). I prefer the former as:

1. I have more control over the images by doing the conversion myself.
   • I can pick the best format for each situation.
   • I can customise compression settings to suit the situation (e.g. use more aggressive compression if the source image isn’t high quality to begin with) and use (e.g. use lossless for images which are about comparing image formats, RAW converters, or other such situations where viewers need to see the image exactly).
2. I have more reliably-available computing horsepower locally; I can run pretty much any conversion or optimisation process and it’ll just work. In contrast, WordPress-hosted processing is subject to various limits on runtime and RAM usage, which can cause things to fail in all sorts of ways both obvious and nefarious. Most web servers [used for WordPress sites] have way less RAM available than even an entry-level personal computer. Processing of “large” images, such as photos from a camera, will fail with default WordPress & PHP settings.
3. Every additional WordPress plug-in increases the possibility of problems, whether due to bugs in the plug-in, the possibility of incompatibilities between plug-ins, etc.
4. WordPress plug-ins don’t always age well; each one I adopt is yet another plug-in which I might have to migrate off of in future.
5. WordPress plug-ins for image format conversion & optimisation tend, in my experience, to be both buggy and money-grubbing. Many are tied to 3rd party services like CDNs or “Cloud”-based image processing, and try to lock you into pricey and unnecessary paid subscriptions.

Nominally having WordPress do it means you can just upload any random image without care for its format or compression, and that over time you can easily adopt new image formats just by installing new plug-ins, with all existing images converted retroactively. In reality, new image formats come along very rarely and popular ones – like PNG, JPEG and WebP – are supported basically forever.

You do have to be a little careful, however, to not over-compress your original uploads (or, retain higher-quality versions locally). Especially if you’re churning through image conversions & uploads rapidly, you might not immediately notice compression artefacts. Having the original available in order to redo the compression is valuable.

Advance conversion

There’s a further choice as to whether you do the processing locally or use a website. I prefer to just do it locally, for some of the same reasons as not using WordPress, and also because in my experience I can achieve better results – websites that do image conversion / recompression, especially those that do it for free, use weak compression in order to minimise processing time, and consequently do not achieve the best results.

The best tool I’ve found for local image processing is Image Tool+. It supports all the formats you’ll likely need and is designed for easy batch conversions.

In years gone by I used GraphicConverter, but it doesn’t support AVIF.

It’s important to note that the PNG files produced by Image Tool+ are not very efficiently compressed – you should run them through ImageOptim if you actually intend to use them.

Publishing images in WordPress

WordPress supports some image formats natively, and does a passable job of handling them by default. So you don’t have to do anything additional, necessarily. However, there’s several plug-ins I recommend which significantly improve its capabilities.

AVIF Support

As it says on the tin, it adds support for AVIF to WordPress, which sadly lacks support otherwise. Without this plug-in, WordPress will simply refuse to accept AVIF uploads.

It’s free, open source, and works pretty seamlessly, as long as your web server and WordPress installation are sufficiently modern. The easiest way to determine if that’s the case it to simply install the plug-in – its Settings page will tell you if AVIF is supported or not. If it’s not, only then will you need to do some package upgrading. In particular, you need (as best I can tell from experience and what I’ve read online):

• PHP 8.2 (or later).
• libavif and suitably-compiled versions of GD and PHP.
• ImageMagick 7.0.25 (or later)
  
  …or ImageMagick 6 with a suitably new and compiled libheif w/ AVIF support. I haven’t been able to pin down specific version numbers, and it might vary by package repo (as libheif has to be compiled with certain flags to include the AVIF support). In a nutshell you can tell if your system has it by following the dependency graph from your libmagickcore-6… library (via apt info <package> or similar) and seeing if it includes libheifN with in turn an [installed] dependency on svt-av1 or libaomN. Where ‘N’ may be any number.
  
  Note: ImageMagick 6 doesn’t support alpha channels in AVIF images (see Bug: Alpha channels, below). So use ImageMagick 7 if possible.

Even though all those versions are quite old, I actually had to switch web hosts in order to get them, as you’d be sadly surprised how many WordPress hosting services are running wildly ancient versions of Linux (kernel & distro) and PHP. Now that I have my own Linux VPS, however, it was quite trivial – I basically just used apt and Plesk to install the latest versions of all the relevant software (which you should be frequently doing anyway, for security patches and bug fixes). Although sadly that still only gets me ImageMagick 6 (and an outdated GD that doesn’t support AVIF) – Plesk PHP builds are pretty far behind, and Ubuntu doesn’t officially support ImageMagick 7 at all! 😠

Note that you only need one of GD or ImageMagick to have the necessary AVIF support, which is fortunate in case one of the two is difficult to upgrade with your particular system (such as if you use Plesk).

ImageMagick is apparently superior:

It’s recommended though to use Imagick lib. It gives way better results in terms of speed, quality and size.

AVIF Support author (GrandPlugins)

I haven’t tested that claim myself, but you’ll find it repeated in numerous places online, and not just in the context of AVIF. It sounds like the common wisdom is that GD just isn’t very good³.

Bug: AVIF over-compression

At time of writing, it has a bug whereby it doesn’t respect image quality settings, neither the WordPress defaults nor any customisation you might do with other plug-ins. Instead, it always uses a 30% quality setting for AVIF compression (e.g. for thumbnails) which often results in noticeable visual artefacts from the over-compression. I’ve reported this to the developer and 🤞 they address this soon, as it looks like a trivial one-line patch.

Update: the plug-in author fixed this in version 1.0.5, January 2nd 2024. As a bonus they also added plug-in settings for specifying the desired image quality and (for GD) ‘speed’ (how hard the AVIF encoder tries, trading off compression speed for effectiveness).

Bug: Alpha channels

AVIFs with alpha channels don’t work with ImageMagick 6, at time of writing – any time WordPress re-encodes the image, such as for thumbnail generation, it removes the alpha channel. Typically this results in the transparent sections turning black instead.

For now, I use WebP when transparency is involved, as I’m hamstrung by Plesk’s lack of support for ImageMagick 7 in their PHP packages. 😕

I ultimately upgraded to ImageMagick 7 to fix this bug. See my upgrade guide if you’re on Ubuntu or using Plesk, or otherwise can’t seem to get ImageMagick 7 from your normal package management process.

CDN incompatibility

Note that some CDNs still don’t support AVIF, and there’s nothing the AVIF Support plug-in can do about that. You might be using such a CDN without even realising it – e.g. the popular Jetpack plug-in secretly uses the wp.com CDN, so AVIF images don’t work in some places, such as Jetpack’s “Related posts” feature. Alas there’s not much you can do other than not use such broken CDNs – nor plug-ins that rely on them, like Jetpack.

In general you don’t want to use such CDNs anyway, because their lack of support for AVIF – or any other content format – is usually only a result of them mucking with your images in some way. Not all CDNs are bad, though – e.g. Cloudflare has no issues with AVIF because they don’t try to mess with your files.

Enable Media Replace

This lets you replace an existing image without breaking any use of it in existing posts, pages, etc. Including with a different file format. That latter detail is something most competing image replacement plug-ins do not support [reliably], but it’s crucial if you want to upgrade any existing images on your website.

It’s free and open source.

Image Regenerate & Select Crop

This lets you perform a bunch of helpful little things, including:

• You can define custom image “thumbnail” sizes (and modify WordPress’s defaults), which can be handy for tailoring your images to your actual presentation sizes. The WordPress defaults are pretty arbitrary and typically don’t match what your theme desires, let-alone any other plug-ins’ needs (such as for galleries, slideshows, etc).
• You can adjust the default image compression quality setting (for each thumbnail size individually).
  
  Note however that this doesn’t always apply, e.g. currently the AVIF Support plug-in has a bug whereby it ignores this setting. The setting seems to work for the built-in-supported image formats, though, like JPEG and WebP.
• You can manually delete or [re]generate thumbnails in each of the possible sizes, for images both individually or en masse. This can be handy if you change relevant settings (like compression quality, above) or in debugging situations (such as if you’re experimenting with other image plug-ins and they muck up your thumbnails).

It’s free (albeit with optional paid ‘advanced’ features).

Perfect Images

It’s baffling that to this day WordPress doesn’t support modern displays – and I use ‘modern’ in a very liberal sense, since we’re talking circa 2010 onwards. That is, displays designed with a high pixel density that use a non-1-to-1 ratio of points to pixels. i.e. any smartphone or quality computer display in the last decade.

The result is images that render at a quarter (or worse) of full resolution, looking pixelated or soft.

If you care enough about image quality to even consider what image formats or compression settings you’re using, you absolutely should be using Perfect Images.

Basically it fixes & extends WordPress’s image support to – mostly automagically and invisibly – just work with full-resolution images. It’s particularly noticeable and essential for things like screenshots, or any images containing text, as those are especially obvious if rendered incorrectly.

Its core functionality is free – and you can get a fair way with just the free version – but the pro version is worth it, even if a bit pricey.

Usage tips

Fix WordPress’s image size limit

Make sure to check the “Image Threshold … Disable” checkbox in the General settings. This fixes a truly obnoxious WordPress bug whereby it mangles uploads of large images.

Upload ‘Retina’ images specially

For images which are explicitly “2x” – such as screenshots – it’s important to upload them ‘manually’ using Media > Add New Media File, as opposed to e.g. just drag-and-dropping them into a post. The plug-in adds an “Upload New Retina Image” option to the dedicated upload page, which registers the uploaded image with WordPress at technically a quarter of its actual size. That basically tricks WordPress into using the correct dimensions for the image – otherwise, WordPress mistakes the pixel dimensions for the point dimensions, and will naively try to display the image at four times its natural size.

Don’t worry, Perfect Images preserves the real, full-resolution version as the “2x” version of the upload, and will display that instead to your visitors.

This particular upload method is the only way to get images to render correctly in all cases. In some places – e.g. embedded in posts – you can manually specify the correct image dimensions, but that’s both tedious and error-prone, and not possible in all uses.

The only caveat is that those images will look ugly and blurry in the post & page editors. Don’t worry, they’ll render correctly in the actual published (and preview) version of your posts & pages.

For images which don’t have an intrinsic pixel density – such as photos – you typically don’t have to worry about this, as you’ll usually just let them render at whatever size the viewport & layout permit, up to their natural full size.

Limitations

The core functionality works reliably in my experience (over many years now), but some of the peripheral features are broken or notably buggy:

• Image replacement will not work correctly if the file format changes – and it won’t even recognise this case and prevent it, instead leaving you with broken images. Use Enable Media Replace for this instead.
• Batch regeneration of thumbnails doesn’t work reliably – it will silently fail midway if an error occurs, such as it encountering a video file. Use Image Regenerate & Select Crop for this instead.
• Custom Image Sizes don’t work correctly – they always force cropping of the image (“resize to fill”), rather than resizing to fit. This is almost never what you want. Use Image Regenerate & Select Crop for this instead.
• For the Pro version [only], auto-update doesn’t work. You have to periodically check the website for new versions.
• It sometimes reports “issues” for images, in its special dashboard under the Media section, when there aren’t any. This is of course pretty insignificant – you can just ignore it – although it might hide any actual issues if they occur. I did find a way to clear these bogus issues, but it involved manually deleting all thumbnails for all my images and regenerating them, which was a bit of an ordeal due to other, aforementioned bugs. So I don’t recommend mucking with it.

1. Note that HEIF does support lossless encoding but support for this amongst actual encoding applications is poor to non-existent. As such it’s generally not a suitable replacement for PNG in practice. ↩︎
2. As the matrix shows, no version of Internet Explorer supports WebP. But – though there apparently is some non-trivial number of people still using it – I don’t consider Internet Explorer a browser of concern anymore, given it has an official and straightforward successor in Edge, and its last version was released a decade ago in 2013. ↩︎
3. Although for image compression, specifically, this is odd, since there’s only a couple of underlying libraries they could possibly be using, and while they do vary significantly in speed they should produce very similar outputs. ↩︎

While I was doing that, I figured it was high time to drop the subdomain, so now it’s just https://wadetregaskis.com, instead of https://blog.wadetregaskis.com. Blogs are so last year.

Previously I was using Gandi.net (I recall choosing them because they were touted as a particularly privacy-centric host) shared webhosting. I’m now using an unmanaged VPS from IONOS. This is far superior – site performance is much higher, I can finally use modern web technologies like TLS 1.3 and AVIF¹, and frankly it’s just deeply satisfying to have a whole [virtual] machine at my disposal. It might be a gateway to bigger things.

I chose IONOS because they offered the best apparent value amongst hosts that seemed well-reviewed. I’m now paying just a third of what I was at Gandi.net (for what amounts to at least 2x the CPU performance and 4x the RAM!). They also include a full copy of Plesk, which has proven a net win in getting everything set up and configured – notwithstanding some serious initial issues with it, that ended up requiring me to reimage the whole VM and restart from scratch. 😒

The process took over two full days, partly because of the aforementioned Plesk issue which cost me nearly a full day by itself, and otherwise because of just a whole bunch of issues along the way. e.g.:

• File transfers (via HTTPS or SFTP) to & from Gandi are slow. They always have been – it’s one of several things that always bothered me about Gandi.
• TCP connections to Gandi tend to get killed if they hang around for any significant amount of time (such as for large file transfers over HTTPS or SFTP²).
  • This in turn exacerbated a few bugs in Cyberduck whereby automatic retries don’t work and I had to manually relaunch Cyberduck completely between retries (otherwise it locked up).
    
    I partly addressed this by using Transmit instead, which isn’t entirely immune to Gandi’s bugginess but seemed to hit it much less often. And is also a much more elegant application, in any case.
  • Combined with the general slowness, this meant it took most of an entire day to copy out the compressed copy of the old site – which was just a few gigabytes.
• I struggled to find a good way to migrate the site before committing to the actual domain name migration. I had never migrated a WordPress site between hosts – never even restored in-place from an existing backup – so I had no real idea to what degree it would work.
  
  This would have been easier without TLS. I long-ago enabled HSTS for my site, and I technically could have worked around that in various ways, but no matter which approach I took I think it would have been challenging.
  
  Ultimately I just got too frustrated and said “screw it, I’ll switch the domain name and then figure out how to move WordPress”. Thankfully almost nobody visits this site, so breaking it for a day or so was inconsequential.
  • I made this slightly harder on myself by insisting on a “proper” TLS certificate for the new host – and therefore from IONOS since they include one free with each VPS – rather than using Let’s Encrypt (support for which is provided by a pre-installed extension to Plesk). IONOS’s control dashboard didn’t particularly want to issue the certificate while non-IONOS nameservers were used for the domain, although eventually I coaxed it into doing so.
• It took a while to figure out how DNS needed to be configured, between the old host (and registrar), the new host, and Cloudflare. DNS isn’t that complicated in principle, I just wasn’t all that familiar with it. I’ve added TXT records before and done a few other tweaks, but nothing of the complexity of multiple intertwined nameservers and non-trivial subdomain routing.
  
  Although in retrospect having Cloudflare in front of everything perhaps made it easier since ultimately I just had to change settings there, as opposed to having to move nameservers.
  • DNS propagation delays were a significant irritation and cause of substantial delays. After several key changes, I had no choice but to wait an indeterminate number of hours before I could see their effects and move on to subsequent steps.
    • macOS bugs whereby it ignores the last entry in /etc/hosts³ also didn’t help.
• UpdraftPlus kept failing to restore the new site from a backup of the old (ultimately it turned out to be an OOM-killing problem, easily fixed by enabling some swap space).
• Many miscellaneous bugs in Plesk, half of which I’ve already successfully repressed, but as merely a few examples:
  • Plesk’s WP Toolkit extension believes it can set up a crontab entry to poke wp-cron.php periodically, but it can’t (because apparently you can’t invoke that directly via php, you have to actually go through Apache with a real HTTPS request – I never got to the bottom of why).
  • Sendmail / postfix don’t work out of the box with Plesk; WordPress & Plesk just silently fail to send emails. I never found any way to get them to log their failures, but I did ultimately get it working through trial-and-error (and I can’t even say what specific configuration change(s) actually fixed it).
    • It also took a while to figure out how to properly set up DKIM, SPF, and DMARC, although that was relatively straightforward once I found this documentation.
  • After using Plesk and staying logging in just fine for over a day, on multiple computers, it suddenly decided it would log me out instantly almost every time. This is apparently a common issue, and through sheer stubbornness of countless login cycles I was able to get to the “Allow IP address changes during a single session” checkbox, which fixed it for me.

I’m glad it’s done, and there is a solid sense of satisfaction with having conquered the litany of bugs, design flaws, and limitations throughout the whole process.

But I really hope I don’t have to move hosts again anytime soon.

1. …because I can install modern versions of basic tools & libraries, like curl and ImageMagick, that support things like TLS 1.3 and AVIF. ↩︎
2. Made worse by Gandi’s weird SSH server being incompatible with rsync, thus forcing the use of all-or-nothing transfers over SFTP. ↩︎
3. It always ignores the last line of the file, so you have to explicitly add a trailing line return. This is actually not uncommon with Unix tools of a certain pedigree, from before good design, robustness, and user-friendliness were values. ↩︎

A few hours later, Gandi.net was working again, but my site wasn’t.  Sad panda.

Long story short, I used up all the disk space – and by “I”, I mean something – still haven’t figured out what, yet.  Apparently when you use up all the space, that simply kills the VM without any notification (their dashboard for my VM still claimed it was running just fine, no problems detected, which was obvious crap).

That said, their tech support identified the problem quickly and were ultimately able to rectify things for me (after first suggesting I delete some stuff myself, which I tried only to find that when your Gandi VM is wedged in this state, you can’t log in via SSH nor delete anything via SFTP, and those are your only two means for deleting any files…).

As far as I can recall, this is the first time my site’s actually been down in the ~four years I’ve hosted with them (other than a few errors on my part when messing with WordPress etc).

Actually, Suffusion was pissing me off as per usual, and I accidentally applied a new theme when intending only to install it (apparently ‘Activating’ a theme applies it, which is sensible in hindsight but not as clear as it should be given how plug-ins work).  Turns out, you can’t easily go back – changing themes permanently wipes out a bunch of settings.  #%@!

And as per usual the backups plug-in I have installed had silently wedged itself and failed to back anything up for a couple of months.  Sigh.

WordPress is kinda shit.  It’s a mess.  A complicated, slow, buggy mess.  If I actually cared to spend any more time on this site, I’d start by looking for another platform.