I’m looking for a new photo gallery application, and I’ve been having terrible trouble finding one that is worth the disk sectors it’s written on. I know something about writing such things, because I wrote the one I’m using now — but that was more than a decade ago, and it’s fragile, inflexible, unresponsive, slow, and hard to use. (You can see many examples of its output at my photo site. If the only photos of mine that you’ve seen are on this blog, you may be surprised to learn that I mostly don’t take pictures of my food.) Most of the old gallery application’s faults can be traced to two design decisions that made sense twelve years ago, but don’t make much sense now: the gallery database is an XML document, and it’s processed using a suite of XSLT transformations to generate flat HTML files for the Web server. Adding anything to the output — even a simple style sheet — is a fairly painful process, and making better use of the metadata stored in every image is impossible. Even dealing with images that aren’t all the same aspect ratio is too painful to bother with, so I almost never crop even the most poorly composed images in the old system.

I’ve been on the look out for a replacement for a while now, and the need has gotten acute since I switched my photo workflow to my laptop (where I can run Lightroom) rather than the Perl script that I wrote to generate the XML file. I have yet to find anything that looks even remotely acceptable. Everything I’ve been able to find when I’ve searched lately has either been an add-on for a CMS that I’m not interested in using (any of them), or has been useless for anything other than a stock-photo business. But maybe I haven’t been looking in the right place. So here’s what I’m looking for:

1. Free Software. Being able to share and modify the source code (the real source code, not some obfuscated blob) is an absolute requirement.
2. Search-engine and mobile-friendly. I need something that will adapt seamlessly to small screens, but without compromising full traversability for search engines. This leads into:
3. Real URLs. Every photo has its own predictable, cacheable, bookmarkable, search-engine-database-compatible URL. Because:
4. Photos are the illustrations in a story, not the content of a slide show. Most of the things I take pictures of look alike. The entire value of the photo gallery is the connection of photos to the expository text and the metadata that describes the specific location and circumstances of each photo and its relationship to the others.
5. Photos have titles. A corollary to the previous point: since most photos look alike, the “filmstrip” metaphor is worse than useless. The index page of a photo gallery is just that: an index, identifying the things being pointed to by name. Nobody is looking at my photos for just any old picture of a four-bay Shively in radomes, a three-tower AM array, or an SAS Rubicon control surface. There’s a specific facility they want to look at, and the index has to help them (and me) find it, and all the pictures related to it.
6. Static data. I do not want anything that involves server-side code running at request time (especially not PHP, which is not welcome on my server). I’m perfectly happy to extract metadata, generate databases, and write static HTML/JSON/RDF/whatever at upload time — even better if the templating is done using the same JavaScript code for both dynamic/responsive views and the static HTML files.
7. Metadata is good. With one (significant) exception, all of the data needed to generate a highly featureful photo gallery is already embedded in the images. Most are geocoded; all have titles and descriptions; they are keyworded for searchability; the people shown, when known, are identified. The one exception is the desired order of presentation. In my new workflow, the embedded metadata is the sole source of truth: anything else required to make a Web site from the images should be generated automatically from the embedded metadata (or else should be a static site-wide template).

So, gentle readers: am I out of luck? I asked this question on a general mailing-list at work, and got all of three responses (out of 1200 people on the list), all of which were of the form “well, $this kinda sorta does what you want, if you squint at it and you’re willing to write a lot of additional code to make it work”. Do I have to implement this all myself (which will probably take another few years)? Surely I cannot be the only person who has similar requirements.