Self-Hosted WordPress Galleries

Over the last couple of weeks I moved all my photo galleries from Google Photos to my own WordPress host. For my readers, this means that you no longer have to click an obscure link to reach the actual gallery. You can see all images as thumbnails directly in each post, and click on any one to enter a full-screen gallery view. I’ve also set a “featured image” for each gallery post, so if you browse the Photography category all gallery posts are identifiable by a big (downscaled) picture above the title.

The technical details of this move were somewhat involved. I’ve sprinkled discussions of various issues throughout older posts, whenever I encountered them. For the benefit of other WordPress users I’ll summarize these points in the rest of this post, with links to the original discussions.

Why Self-Hosting?

First, what’s wrong with Google Photos? Its gallery view is fast and overall quite good, including a zoom function and Exif data. But there were several reasons why I wanted to get away from it.

  1. Presenting readers with an obscure link instead of the actual gallery is a drawback that largely erases the benefits of Google’s nice gallery view. Typical for Google, the image access is hidden beneath a mass of server and client code. Directly linking to single images is difficult – you must manually create a “shareable link” for each one! – and there is no official way to embed thumbnails at all.
  2. The result was that few readers of gallery posts ever clicked through to the actual galleries. Google Analytics recorded a total of 59 Google Photos link clicks in all of 2016, as compared to 509 views for posts that linked to these galleries! An engagement loss of nearly 90% is disastrous but conforms to the Internet’s rule of thumb: only 1 out of 10 viewers ever clicks on any link whatsoever.
  3. Conversely, Google does not allow arbitrary clickable links in photo descriptions. You can connect pictures and galleries to a Google+ post, and that’s it. All of my photo descriptions contained links to the corresponding blog post, but as they were plain text users had to manually copy & paste them into their browsers. Since most people don’t even click on clickable links, I don’t imagine very many ever bothered to do this.
  4. Finally, storage space was becoming an issue. Google Photos offers unlimited space but only if you allow Google to downscale your images, erasing the benefit of a zoomable gallery view. If you want to keep the original (or otherwise larger) image sizes you must use Google Drive space for your photos, and that service is limited to 15 GB before you need to pay. Meanwhile, even my cheap shared WordPress host offers unlimited storage.

In conclusion, Google Photos is only an acceptable hosting service if you never want to write articles (outside of Google+ anyway) that should be seen together with the galleries.

Gallery Viewers

WordPress has a built-in media library manager that automatically creates a thumbnail gallery view and simple views for individual pictures. The keyword here is “simple:” each picture is presented as a regular post. So you get all the overhead and load time of a WordPress page view for each picture, and the visitor’s browser navigates away from the original article for picture views. Not good.

I’m already using Jetpack, and Jetpack contains its own embedded gallery viewer known as Carousel. That’s what I tried next, but to my disappointment Carousel was somehow incompatible with my old customized Twenty Twelve theme on iOS. Descriptions were unreadable, and moving through the gallery was difficult.

There are plenty of third-party WordPress gallery plugins, but here came the next obstacle: most don’t show Exif data. What I eventually settled on was a combination of Foo Gallery & FooBox for image viewing with Exifography for extracting Exif data. Read more for the technical details.

Image Sizes

While my host offers unlimited storage space, I didn’t want to risk excessive transfer loads that might lead to unacceptable load times. Pictures in the 10 MB range seemed to work reasonably well, and that’s also the size of high-quality uncropped JPEGs for my original Sony NEX-7 camera (6000×4000 pixels). Most of my early galleries were NEX-7 or some smaller iPhone shots, so I could directly upload those.

Later I switched to the full-frame Sony Alpha 7R (7360×4912 pixels) and then to its successor, the Alpha 7R II (7952×5304 pixels). High-quality JPEGs for these cameras are quite a bit larger, typically 15-25 MB for the A7R and 20-40 MB for the A7R II. Happily Adobe Lightroom features a very good JPEG compressor that allows downsizing these pictures to the 10 MB range with no visible quality loss. Beware of Lightroom’s confusing image quality slider, though – see here for details.

Another aspect of WordPress media storage is the number of image files. WordPress has an annoying habit of creating as many as five or six downscaled “thumbnails” per uploaded image, more than you usually need. Set the unneeded sizes to 0×0 in Settings: Media to avoid creating them. I only keep the smallest thumbnail size which I set to 200×200, useful for both galleries and Twitter cards. I wrote some custom PHP code to serve Twitter this size, as described here.

Media Upload Failure

Despite similar MB sizes, I started seeing the mysterious WordPress media upload failures discussed here when I moved on from NEX-7 to A7R/II shots. Most pictures in a set would upload fine, then the thumbnail creation process would stall for a few. The progress bar stays forever at 100%, sometimes WordPress reports an HTTP error, and the media library contains unusable entries for the stalled images.

The exact causes for this behavior are unknown, but evidently both PHP image processing libraries used by WordPress (GD and Imagick) can fail to downscale certain images, mysteriously depending on both pixel size and contents. My host does not allow changing any PHP settings but it did allow updating to the latest PHP version 7.1, and that alone fixed a number of problem pictures.

For the remainder, the only thing that helped was reducing the image’s pixel dimensions – not the MB size which had no effect at all! I could eliminate all upload failures by having the Lightroom exporter rescale images to 7346×4900 pixels, slightly below A7R dimensions and causing no visible quality loss. Your mileage may vary, but this is something to try.

Leave a Reply