nina was surfing one of my many galleries on my homepage and then mentioned, that it would be much more convenient to proceed to the next image in the gallery by clicking on the image, rather then moving the mouse to the "<<Prev" or "Next>>" links on each gallery slide page. and, as always, she was right. so, in order to change the galleries, i had two possibilities. first one would be to rerun the llgal command on all of my galleries (which would be a total of 446 galleries, at the time of writing). or, in other words this means craft a nice bash one-liner, and then wait a long time and consume a lot of cpu power. second approach would be to tweak my nginx configuration. and that was the approach i preferred, as it would give me more flexibility in changing all galleries at once in one central file. after a little research it seemed the "subs_filter" module (mind the "s" here, as there's also a "sub_filter" module that has several limitations that made it rather useless for this task) was the perfect choice. and soon i had my clickable image, but it had some flaws, like what if it was the last slide? the crafted link would then point to a non existing slide. hm, not very nice. this meant digging again and also a little deeper into the possibilities nginx offers to modify html code and configurations. and while i'm at it, why not split the image into two clickable areas. one on the right half of the image to proceed to the next slide, and one on the left to go back to the previous slide? research showed the solution to this problem would either involve either a lua or a perl module to do the trick. of course i went the camel path and crafted a nice little sub-routine that would create a variable that i could feed back to nginx and back to the "subs_filter". here is the nginx.conf part: for all locations that contain "/slide_<some_number>.html" run the sub filter, and change all occurrences of the first argument to the stuff defined in the second argument. to get stuff into the "$slide_navigation" variable, i used the "perl_set" command. this command is run as soon as nginx finds the variable name in a directive, which means, it is only called when there's a request for a document matching the "/slide_*.html" pattern. here is the perl part of the magic in the nginx.conf file: the "<div [...]>" and "<a [...]>" tags at the end include loads of css stuff to create the clickable zones for the previous and next image. additionally the "<div>" tag wraps around the "<a>" and "<img>" tag, so i can place the link directly on the image. notice the "</div>" tag is closed in the "subs_filter" directive, not in the perl part. for more details, feel free to have a look at the page source code of any gallery. so far i was pleased with my achievements, but now that i have the links to the previous and next slide, i lost the ability to right click on the image to copy the image location - that is not what i had intended. looking at the html code of the slides i found out, that llgal always places the image file name in a line after the actual image. it is only prefixed by blanks, so that makes it easy to match with a regular expression - a good thing for another "subs_filter". so i added it right after the first one in the nginx configuration file. here is the second "subs_filter" in the nginx.conf file: ha, a link to the image location right under the image (with it's own css class definition) - nice. awesome, so now you can click on the images to get to the previous or next image, or back to the index if there is no previous or next image, and i a have a link to the picture location too. but while i'm (still) at it, why not add google analytics to every html document? and - you might have guessed it - once more, another line of "subs_filter" does the trick. google recommends to place it right before the closing "HEAD" tag. here is the google analytics "subs_filter" part: and here is the perl part for the GA magic: done. excellent, a clickable gallery, google analytics code included, all without modifying a single existing html document. all hail to the power of nginx, perl, and regular expressions.