If you have captions on your photos, WordPress will place them on your page (or post) along with the pictures. If the details in the caption were correct when the photographer - you or whomever - originally captioned the picture, they’ll be correct on your site. That means less chance to make an error. (And less room for excuses if you do.)
If your WordPress hosting provider makes ImageMagick available for your site, that’s good news. It’s good news for metadata. It’s good news for image optimization. It’s just a great day all around.
But what if you’re stuck with GD? Is there a way to fix the metadata damage that library inflicts? Yes. Probably. Maybe. I have a workaround for you. It works for most sites, depending on what sort of access your hosting provider grants.
If you have FTP access to your site, this will work. Most hosts that I’m familiar with do provide FTP access for self-hosted sites. But your luck may vary. (And since you’re probably reading this because your provider already doesn’t provide ImageMagick, you might want to hold off on buying that lottery ticket.) WordPress.com, by the way, does not support FTP access for its users.
Your hosting provider may have given your FTP credentials when you first opened your account. Or, your FTP details may be somewhere on your account’s homepage. Or, maybe there are instructions in the support documentation. Or, you might have to use your account’s control panel to enable an FTP account. Or, quite likely, you’re already well familiar with all that and you’re just waiting for me to get on with this.
If you’re not familiar with using FTP, there are lots of How-Tos on the web. Just Google “FTP and WordPress”.
What we’re going to do here is FTP to our WordPress server, grab the image files that have been stripped of their metadata, paste the metadata back on and put the files back where we found them.
Fire up your FTP client. If you need an FTP client, Filezilla is a good one. I use it. And it’s free. But they all work, FTP isn’t brain surgery.
(You can make a shortcut in your FTP client to save drilling through so many directories.)
Once we have safely arrived in the correct directory, we’ll be looking at our media files. Each image will appear along with several resized copies. (Four, by default)
These resized versions of the image are served to visitors responsively, according to the size of the visitor’s viewport. The original, or full-sized, image is exactly the file that you uploaded to your Media Library. It will have its metadata just as it did when it was on your desktop. The smaller ones, which have dimensions appended to their filenames, were created by your imaging library. If that’s GD and not I
mageMagick, these files will stripped of all metadata. We’ll fix that.
(Don’t worry about interrupting visitors’ access to the images. You’re copying them. The files will be available on your site while you work on them. There will only be a period of a second or so, when we put the files back, when each file wouldn’t be available.)
If you look at your files’ metadata (“I”, or the tooltip in Photo Mechanic), you’ll see that the full-size one has all its metadata in place. The others are stripped clean. We’re going to simply copy the metadata from the full-size image and paste it on the other files.
In XnView, the process is a little different. You’ll open the IPTC panel for the big image, save its metadata to a reusable template, and apply that to the other files. See my post on moving templates between programs for a fuller explanation.
Your repaired images will be exact replacements for the files you downloaded, except for being a few kilobytes bigger and having working metadata.
Test to see that it worked
Now you’ll probably want to go to your website and right-click and download one of your pictures to assure yourself that your work-around-ing did indeed, work. You won’t need to do this next time.
If you put fifty photos on your website whenever you post, fixing your metadata like this could be a fair amount of work. If you’re like me and it’s a half-dozen or so pictures at a time, we’re only looking at a minute or two. It’s just a matter of making it a habit. (Full disclosure: The server on which you’re reading this is ImageMagick-challenged. I haven’t fixed the photos in last week’s post. I’ll take care of them when I post this.)
There you have it. Hopefully, this technique will tide you over until you can get that ImageMagick situation in order. And yes, the technique can be used for other stuff, like running ImageOptim (in lossless mode, please) on your resized files while you have them in front of you. Just be sure not to change the images’ dimensions.
Stay tuned. In future posts, I’ll look at optimizing images for WordPress in a metadata-safe manner, and I’ll do How-Tos for that task in our supported range of software. And, oh yeah, I owe you a metadata How-To for XnView. Dive into the comments and…comment.
The good news: WordPress, by far the most popular content management system on the web, supports embedded metadata. The bad news: Well, not always. But we can fix that.
If you import a photo into WordPress that has a caption, WordPress, by default, will read that caption from the photo and place it in the picture’s caption field in the Media Library. From there, when the photo is placed on a page or in a post, voila! the caption appears under the picture, formatted by your theme and ready to go. After a little touch-up editing, perhaps, but ready-to-go and I-didn’t-have-to-type-it have got to be pretty great. ¹
But what about the photo itself? Will it be served with its embedded metadata intact, or will be it be doomed to wandering the internet without its copyright information or caption? That’s where things get a little tricky.
WordPress, by default, prefers an image-processing library called ImageMagick. If ImageMagick
Is available to WordPress, everything is awesome, and your picture will go forth into the world in possession of all the vital information it needs to be relevant for (hopefully) decades to come. Well, all the vital information that was in the metadata when you uploaded it, anyway.
(Also, by many accounts, ImageMagick produces better visual quality at smaller file sizes than its competitor.)
ImageMagick, which has been an industry standard for many years and is the image processor for many, many, server-based systems, is either on your web host’s server, or it’s not. There’s no requirement thatEnable ImageMagick and your WordPress site is good to go. Karma will be on your side and you won’t have to worry about being sued for removing Copyright Management Information from images.hosts provide it. Many –or even most – do. But some don’t.
And, if ImageMagick is available on your server, you will generally need to enable it in order for WordPress to be able to use it.
If ImageMagick isn’t available on your server, WordPress falls back to an imaging library called GD. GD is bundled with PHP, upon which WordPress depends in order to function at all. So GD is a sure thing. It’s guaranteed to be there.
When you upload an image to WordPress’s Media Library, it makes copies of your image in various sizes, from Baby Bear little to Poppa Bear big. Four new files are created by default, plus the original, yielding five size choices to fit browser windows on devices ranging from itty bitty phones to great big desktop monitors. There may be more sizes created. You might add more sizes, or plugin software might require more sizes.
The biggest instance of your picture is the original file you uploaded. It’s untouched. If it’s the file that is served, say to a visitor with a really big monitor, you’ll serve exactly the same file that you uploaded. So, if you uploaded a file that has proper metadata, that’s what goes out on the internet. If you set clicking on your photos to open the media file (so that a large view of the photo is shown to the visitor – that’s usually expected behavior) then such a click will cause the original file to be served. If someone is, ahem, obtaining your picture, it’s likely that they will grab the largest version, and they’ll get a file with caption and copyright information. So that’s good-ish.
If ImageMagick made the smaller-sized versions of your picture, great. They’ll all have their metadata, too. That’s great.
But GD doesn’t do metadata. (It can, a little, but doesn’t by default) If your WordPress installation is relying on GD, you’ll strip metadata from all your images except the biggest, full-sized versions. Naked. Bereft. Raw statistical probability says that at least four out of five times you’ll serve a stripped image. That’s not good.
So, by now, the picture is clear. (sorry about the pun) ImageMagick = good. You want it. Now what?
Do you use the local/testing server MAMP? Click to See how to enable ImageMagick on MAMP.
Available? Make sure your host provides ImageMagick. If you’re shopping for a hosting provider, you may have to ask. Sometimes if you Google “your-would-be-host ImageMagick” you’ll get an answer in the form of
some sort of knowledge base article. Hosts rarely mention ImageMagick on their benefits page. (Are you listening out there, hosting providers?)
Obviously, if you are shopping for a new provider, you want your ImageMagick. If you’re staying with your current host, ask and cross your fingers.
And enabled. Once you have confirmed that ImageMagick is available, enable it so WordPress to access it. Enabling ImageMagick usually involves un-commenting a line in a PHP configuration file (doing so enables a PHP extension, either IMagick or MagickWand, that talks to ImageMagick, ) and perhaps adding a path statement somewhere.
Check with your host’s customer service department. The whole process only takes a minute or two. If your provider has good customer service, the rep will probably enable ImageMagick for you, while you’re still on the phone or chat. Or maybe they’ll provide you with instructions, or have documentation on their support site. Remember to backup any configuration files before you change them!
You don’t have to do anything on the WordPress side. WordPress will, all by itself, use ImageMagick henceforth.
I called some hosting providers while preparing this post. ImageMagick support wasn’t exactly on the tip of most providers’ tongues, but I got the impression that most good providers do provide the service. You might have to be a little bit persistent, though.
At Liquid Web, Imagine Magick is installed and already enabled by default. “We make sure that ImageMgaick is already there,” says Managed WordPress Product Manager AJ Morris, “On the WordPress side, we take care of all that for you.”
There is a catch, though. Liquid Web is developing an in-house image optimization tool. Morris says that tool will be metadata-friendly. But in the interim, they have temporarily provided their customers with an image optimization plugin. That plugin eats metadata. So, for the moment, Liquid Web customers who want to preserve their metadata will need to work around that issue. They can either disable the plugin, and just make sure they’ve prepared their images properly before upload, or they can keep the plugin active and use a workaround for a little while. Or even possibly substitute their own plugin. (I’ve tested some optimization plugins that are metadata-friendly if the underlying server is using ImageMagick. I’ll post some reviews soon.) But remember, it will only be a short while until the proprietary tool is up and running.
A Flywheel rep told me that ImageMagick was enabled by default on their servers.
At Bluehost, a rep told me, “Our servers do supply MagickWand [a PHP extension that enables ImageMagick] 100%, but that would be something the customers would have to do themselves.” My call was the first time anyone had asked that particular rep about ImageMagick. But their ImageMagick knowledge base page says it has been viewed 68,000 times.
At SiteGround, enabling ImageMagick on my test site only required adding a configuration file to my web root and adding a path statement in my .htaccess file. SiteGround’s spokesman said, “We fully support the ImageMagick extension – with all of our packages. It is not enabled by default. However, our support teams can enable for you in a matter of a few minutes only.” Which is exactly what happened when they did it for me. It wasn’t done quite while I was still on chat, but they came pretty close.
(The server that hosts this site won’t be so simple, by the way. But we’ll get there.)
But what if ImageMagick just plain isn’t available on your server and, for whatever reason, you don’t want to change hosts? There is a workaround that works OK in many cases. It’s a bit of effort, but it’s not too bad. I’ll explain in next week’s post.
That’s it. Enable ImageMagick and your WordPress site is good to go. Karma will be on your side and you won’t have to worry about being sued for removing Copyright Management Information from images.
How was your experience when you asked your hosting provider about enabling ImageMagick? Post in the comments and I’ll include your input in an upcoming post that will feature a list of hosts who support ImageMagick.
¹ You’ll notice in Media Library that there’s a field called “Description” underneath the Caption and Alt text fields. That’s confusing because the IPTC “Caption” field is also called the “Description” field. So what’s WordPress’s “Description”?
Well, every media object in WordPress has it’s own “Attachment page”. The attachment page displays your image with your header and footer, a headline, caption and a text block. That text block is the “Description” field you see in Media Library.
In Media Library, you can see the attachment page by clicking on an image’s permalink. You can link from an image to its attachment page instead of the media file when you place an image into a post or page, if you so desire. It’s kind of cool, but frankly, I’ve yet to find a use for this feature. It might be a nice way to display an infographic, I guess.
You can’t edit the attachment page in the editor. The headline is mapped from the Title field in Media Library. The caption is mapped to Caption, and Description becomes the text block. The only way you can edit any of that on the attachment page is in Media Library, which means that edits to the Caption field will then show up when you place that image on a post or page. That’s kind of inconvenient.²
And the footnote has a footnote:
² Note that editing a caption in Media Library or on a page does not affect metadata in a photo’s file. WordPress does not write edits into a file’s metadata. This conforms to normal conventions. Best practice assumes that where ever it may go, an image is expected to have the original metadata it was published with. You can probably live your whole life without ever having to worry about this, but it’s always better to know how things work. If something is outrageously wrong on a photo’s caption, correct it before you upload the photo to WordPress.
