Add ImageMagick to your WordPress site

ImageMagick logo
The ImageMagick wizard.       Courtesy of ImageMagick/Creative Commons

We should use ImageMagick on our sites; here’s how 

Everybody who has a WordPress website should enable ImageMagick (at least for the time being) to protect artists’ rights metadata. Why? Because we’re ethical, socially concerned folks, that’s why. How? Read on. It’s real easy.

A bit of background. WordPress uses an imaging library to (among other things) create the images that will be served by your website. We have a choice of imaging libraries. Right now, circa 2020, of the two at hand, only ImageMagick protects the important metadata that this site is all about.

This post is all about the process WordPress uses to optimize images.

This one covers stuff we can do to get our images ready for WordPress efficiently. 

Virtually all good hosting providers offer ImageMagick. We could go so far as to say that doing so is part of the definition of a “good” hosting provider. 

If ImageMagick is enabled on a server, WordPress, by default, will use it. Many hosting providers – and their number is growing as we speak- enable ImageMagick by default. In that case, we’re golden. We don’t have to do a thing. 

Look before you leap

So, first, let’s see if ImageMagick is already working on your site.

  • Upload an image that you know contains IPTC metadata. The image should be big enough that your imaging library makes sized renditions of it. If you don’t have such an image handy, you can grab a purpose-made one here.
  • Put your sample image on a page or post. It should be small enough on the page that WordPress serves a re-sized rendition, rather than the original image that you uploaded. (The original image is just that. It’s exactly what you upload. It’s the renditions that we’re concerned about.)
  • Publish or preview the post or page with your test image. Previewing will do fine.
  • Right-click on your image and download it to your computer. When you see the save-as dialog from your browser, you’ll see the filename of the image, as served by your site.
  • Take a quick look to make sure the filename includes some dimensions, like this one: DSC4334_wp_test-300×200.jpg.  When WordPress makes images, it adds dimensions to the filename. If you see them, that’s good. We’re dealing with a file made by the imaging library. If the filename is exactly what you uploaded, you were served your original file. Either your picture was too small or you made it too big on the page.
  • Now, take a look at your “round-tripped” file in any application that reads industry-standard metadata. You should see some meta-information. (If you downloaded the test file from a few paragraphs ago, you’ll see one of the metadata starter templates I give away all the time in How-To posts.)

Read metadata

Applications that will read metadata for us include any of those that I cover in this blog: Photoshop, Photo Mechanic, Lightroom Classic, XnView, ON1 Photo RAW, Adobe Bridge, and a bunch that I don’t cover, including the File Info dialog of the Mac operating system, the File Properties dialog in Windows, and a slew of photo editors and image browsers. Or you can use the IPTC’s own free online metadata viewer. A link is in the footer of every page on this website.

If you see that your site is indeed preserving metadata, congratulate yourself with a glass of fine wine, good coffee, or whatever floats your boat.

If not, you’ll need to enable ImageMagick on your server, which won’t take but a few minutes.

How to enable ImageMagick

Being the considerate people that we are, we should Google the name of our hosting provider and “ImageMagick” to see if they’ve provided an easy way to DIY this. If they have, then do what your provider’s documentation says.

If they haven’t, just ask their Customer Support team to take care of it for you. Usually, hosts provide chat with Customer Support. Or maybe you have to use an actual telephone. Most hosts have great support. They’ll take care of your request in a jiffy and you can be on to that congratulatory beverage.

You should re-do the check procedure, just to make sure all is well.

A bit more background

In order to enable ImageMagick on a WordPress server, we have to enable a PHP extension called Imagick. Imagick is all ready and waiting. It ships with PHP. The line to turn it on is already in your php.ini file. It’s commented out with a semicolon. All we need to do is delete that semicolon. One keystroke. That’s if we have access to the main php.ini. But we don’t. 

Each server administrator chooses how he or she will handle this PHP extension thing. There are all kinds of ways to configure a server to allow ordinary users like you and me to do the deed. Or maybe the admin just wants their own employees to handle it. Thus, it’s a host-by-host thing and we usually let Customer Care take care of it for us.

I have a post explaining how to enable ImageMagick on a mini server on your local machine, like MAMP, here. In that case, you have total access to the server. So, that post shows the under the hood gitty-gritty, if you’re interested.

Is your site on Drupal? This post talks about enabling ImageMagick on Drupal. If anything, it’s even easier.

All of this assumes that ImageMagick itself is installed on your server. As I said, on good hosts, it almost always is.

If it isn’t, or if it’s not enabled via Imagick, WordPress falls back to an imaging library called GD.

GD what?

GD ships with PHP, so it’s always available. By necessity, GDis a more stripped-down, lightweight sort of affair. One of the things it doesn’t have is the ability to preserve metadata. Which is the whole reason for my mania about enabling ImageMagick. I’ll circle back here in a minute.

Is there an efficiency advantage to one library or the other?

Short answer: No. 

If you’re a normal person, running a website that isn’t Facebook or eBay, you won’t see any real difference. ImageMagick uses a bit more server resources during the two or three seconds while your image uploads. Unless you upload a zillion images a day, like eBay, you won’t notice. 

GD runs in PHP’s memory space. ImageMagick doesn’t. Depending on a bunch of factors that we, as normal website owners, don’t even have a way of knowing about, that could tilt an advantage in server speed, so small that nobody would ever notice – during those few seconds when images are uploading – one way or the other, depending on which library is in use. Not that we could even know, much less care.

Load time?

Will the imaging library make a difference in how an image is processed that will affect page load times?

Again, no.

ImageMagick’s fans claim that it provides better image quality at a given compression ratio. In theory that means that if you use ImageMagick, you could have WordPress compress your images a tiny bit more and see faster load times, or better quality at the same load times. But in all honesty, I can’t tell the difference. We’ve got more important stuff to worry about.

ImageMagick is a much bigger, fancier, more comprehensive program than GD. If we had a WordPress plugin that would allow us to take full advantage of all the cool things it can do, that might be really cool and we might be able to eke out a load time advantage. But we don’t have such a plugin. Volunteers? 

GD, for its part, has a new maintainer, Wilson Chen, who is very interested in adding metadata support to the program. He has added it as a milestone in a future release. When GD gains metadata support, those of us who are so inclined can nerd out on the fine points and choose whichever imaging library we like. 

But until then, social responsibility wins out and ImageMagick remains our library of choice.



Feel better about how your site treats the people who create your content – a group that may include you – by enabling ImageMagick to preserve artists’ right metadata. Just do it. Congratulate your self in the comments.



Share this content