> Software > Why I wrote my own image gallery system

Why I wrote my own image gallery system

So why did I write my own content management system to serve these image galleries? The short answer is that I'd never seen anything that worked exactly the way I wanted, and because I wanted to.

My previous web publishing system consisted of an unwieldy bunch of scripts that generated static HTML files that I would simply upload to the web server. I figured I needed something better that still looked and behaved the way I wanted. I'd encountered several web-development systems over the years (Drupal, Zope/Plone, Turbogears, Rails), but the one that seemed to have the most going for it was Django, and I was keen to build a substantial project using it, so here it is. At some point I'll release it under an open-source license. As of mid 2011 the editor's interface and site configuration mechanism need a lot more polish before it's ready for general use.

Screen grab of the editor's interface
Larger image

Screen grab of the editor's interface

Here are some of its features:

  • Web-based content management. All the content editing and management is done in your web browser.
  • Human-readable URLs Instead of URLS ending with something like index.php?id=7352739438&x=9&p_q=b, you'll only see things like /here-and-there/outback/mount-arckaringa-after-sunset. This is particularly nice if you want to send someone a link in an email
  • A page can belong to more than one gallery. When categorising images into galleries, it's often the case that an image rightly belongs to several categories. With this system, the same page can appear in several different parts of the site. Each page knows about all of its aliases and shows a "this page also appears in..." link at the bottom. I use this to pick out particular images from trips I've done and create aliases for them in one of my main galleries. The system flags the original page as the "canonical" version, and uses special tags in the HTML in the aliased pages to tell search engines which page is the original. This ensures that the search engine's page score is not distributed amongst the aliases.
  • The site structure can be reorganised without breaking any links. The editor's interface allows pages and galleries to be moved around and renamed. The system keeps track of where everything has ever been and what it was called. Instead of returning "page not found" for old links, the system follows the historical chain of reorganisation and redirects the browser to the new URL.
  • Selectable image size. Each image can be made available in several different sizes. The viewer can switch between sizes using links on each page. This setting persists across the entire site as they browse it, and works without using cookies by using different URLs for each size. For example, if they have a large screen and fast internet connection, they might want to browse the site using the largest image setting. The "canonical" tag is used here too so that search engines don't waste their time on the larger versions of images.
  • Low web-browser CPU and memory load. All image scaling is done on the server and I've deliberately kept javascript use to a minimum.
  • Linkable pages. Some image galleries display images in a pop-up that emerges from the gallery page in some animated fashion. While this can be quite appropriate for some websites, I've deliberately avoided this approach for the time being. The trouble with these techniques is that they often don't provide a way to create a link to a particular image page, so you can't bookmark it or create a link to it in an email or another web page. It also means that search engines can't refer to those images because there's no URL to go to that will make the image emerge from its gallery again. They often make the browser's "back" button misbehave too. Being able to link to things is an important part of the web - in fact it's fundamental to its operation.
  • Uses liquid layout. The page layout adapts to the browser window width and the viewer's chosen font size over a wide range.
  • Built-in "What's new" functionality. Each page has an associated change-log that you can edit at any time. These change-logs are used to generate the "What's new" list on the front page, or anywhere else you'd like to put it. The change-log display can be restricted to those pages in a specific branch of the site, so you can have, say, a "What's new in Landscapes" list in the landscapes section of the site.
  • Slideshow style image loop of selected images. You can put a looping slideshow of randomly selected images from one or more galleries on any page. You specify the galleries to take the images from and the number to loop over and it will randomly choose a subset to fade between. You can specify height and aspect-ratio tolerances so that the images in the selected subset don't differ in size too much from each other.

For the more technically inclined...

  • All the text content and site structure is held in a SQLite database. All the images are stored as files. This makes it easy to have an offline copy of the site that you can edit at your leisure, which you can then publish to a live site by simply rsyncing a single directory containing the SQLite database and image files. If you're on the road, you can update the live site directly, then rsync that back to your offline copy again when you get home.
  • The URLs don't have any query arguments. This makes for shorter and more readable URLs and provides more opportunity for caching.
  • The thumbnail navigation column uses a single tiled composite image for each set of thumbnails, generated automatically. This cuts down on network traffic, cuts down on the number of URLs that need to be cached and means less work for your web browser.
  • Images are added to the site by dropping image files into a "feed hopper" directory on the web server. You then run an ingest operation which scales down the images to the desired sizes, watermarks them and puts them into an image queue. The name of the file that the scaled images were generated from is saved in the Xmp.xmpMM.DerivedFrom metadata field of the resulting JPEGs so you can find the original file if you need to.

    The image watermarking operation examines both the bottom left and right corners of the image to figure out where to put the watermark. It will choose the corner that has the least brightness variance (a reasonable surrogate for detail), and will use either a dark or light watermark depending on the average brightness of the chosen corner.

    To add an image to the site, you navigate to the desired part of the site in the editor's interface and choose the "new" tab. This presents you with the next set of images in the queue as the candidate images for the new page. You can skip ahead in the queue to choose a different image if you want. Once you've got the right image you can fill out the accompanying text fields, then hit "save" to pop that image off the queue and put it on the site in a new page. The URLs are generated from the page titles, disambiguating them as necessary. Alternatively, you can append images and accompanying text to existing pages by using the "append" tab instead - roughly equivalent to appending a new paragraph to an existing page.

    The editor's interface also allows simple ad-hoc addition of images into an existing page using a standard HTML file upload.

  • Doesn't use cookies. State is maintained in the leading URL path component.

Articles and information