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. ↩︎