[KPhotoAlbum] (yet another) html front end

[jedd]

 Greetings busy people,

 A couple of months ago I got excited (all over again) at the idea
 of organising my photos - thanks to a multi-country, 4-month
 holiday looming.  I realised early on that I really wanted something
 a bit more dynamic than the current web front end offerings, and
 ideally something that would 'just work'.  The simplest approach I
 could come up with was to have a php (it's the only appropriate
 language I'm familiar with) script talking directly to the file system
 where the pictures and the index.xml file live (it therefore has some
 security implications, as below).  To publish a picture, you simply
 nominate a Keyword-tag (I use 'PUB - jedd'), save the config, and then
 hit the web page.  The php scripts generate three cached files (I use
 my own caching system) - the thumbnail, the inline picture, and a
 'huge' image (from an original of about 4mb, these cached images
 are around 16kB, 170kB, and 400kB respectively).

 I have a functioning system cranked up on my server, visible
 to young and old at :

 http://dingogully.com.au/kphpalbum

 This server is located on the other side of the planet to where I am
 now, so as per the cosmic rules on such matters, it's likely to die
 within a few minutes of me posting this message.  It's living at
 my sister's place, and she's closer but still a good 700km from it
 for another few days, too.  *


 Right now what I'm after is basically some ideas on :

 o  whether this is likely to be useful to anyone else.  (I see the
     subject pop up periodically, and most people seem to write
     their own custom script, or learn to live with the html export)

 o  ideas on functionality - present or missing.  (I have a TODO
     list somewhere that I should put into the footer on that page,
     but will briefly go through known issues below.)

 o  ideas on layout - as I've developed this on my MSI Wind, and
     in case anyone doesn't know .. this is a painfully small, 8"
     laptop, with a 1024x600 resolution - so I know that things are
     going to look quite weird on a Real Machine.  I also develop
     with konqueror, so I expect things will look even weirder with
     IE (not that many of us use IE, I expect) or Firefox.

 Later on you can give me ideas on coding - I'm not a coder
 by trade, and a lot of this stuff is pretty fugly in style, whilst
 being perfectly indented.  :)   I toyed with the idea of making
 it a bit more shiny (some ajax, wedging it into codeigniter, etc)
 but my priorities were to keep it lightweight, and lay down code
 as fast as I could come up with new ideas.


 I have tarballed up the code AS IT STANDS - but mind, this is
 pretty ugly and I'm not proud of the internals (is anyone ever?).

 URL is as above but tack on /kphpalbum.tgz

 Installation is .. badly documented.  But it's painfully simple - just
 modify the config.php file with the path to your picture repository
 (that is, the directory with the index.xml file in it).  For the sake
 of security you could have a symlink that is hard to guess, and
 perhaps several directories deep, that points back to that location
 (this is what I do).



 ====== Known Issues  ======

 Security

 I use an obscurity approach to hiding the location of the actual
 pictures, but by definition, the web server needs to have visibility
 of all images - or rather, all images that are PUBLISHED, but for
 convenience sake that's the same set.  I've set things up such
 that this information (path) is not referenced in any PHP or HTML
 that the user can see.  However, occasionally errors may generate
 a useful pathname - I'm still working through that oversight now.

 Alternative workaround - is to replicate merely the cached images,
 and that's what I'm doing right now for the bulk of my images (rather
 than sending back 12GB of photos from the past 2 months, I simply
 rsync back the cache - about 150MB, for 200 pictures).

 I considered also just advocating a .htaccess or /etc/apache
 directive to decline directory-listing access to directories under
 the picture-root .. but it'd be a trivial matter for the kind of
 person I'm talking about to simply try 'img_0001.jpg', 'pict0001.jpg'
 'dsc0001.jpg' and so on, through the standard set of image names.

 There might be a more elegant way of telling apache to not allow
 direct access to this part of the file system, while still allowing
 PHP to do direct access to the same location.  (?)



 Sub-categories

 I haven't got this working properly for the Explorifier, but I have
 got it working via the image-tags (right-hand side).  I haven't
 worked out a good way of handling the potentially conflicting
 and multiple-presences of items within the hierarchy yet ...


 Sorting / searching by dates

 No idea how to implement this neatly yet - I'm still waiting for a
 wake-up-in-the-night moment with some great insight.  At the moment
 sets are defined by filters you use, and all thumbnails (and hence
 the images) are shown in chronological order.


 index.xml reliance

 It'd be a huge job (for me) to convert this to SQL, as much as I
 really want a SQL backend (mostly for the multi-user aspect).  I see
 that Jesper reckons SQL won't be implemented in the next version,
 anyway, and I also suspect that we'll have export-to-index.xml in
 the menu for quite some time - so it's not a huge thing.  But it's
 worth mentioning.


 EXIF information

 Relies on visibility of the primary picture - if you're being secure
 (by using cache directory only) you won't have this visibility, so
 I'm looking at some simple way of copying EXIF data into one of the
 cached files - presumably the thumbnail.  I have CLI scripts for this,
 and have been looking for an equivalent PHP library - alas none seem
 to exist.  system() calls within PHP scare me, partly for security
 reasons, and because they tend to be expensive.


 Filtering

 Arbitrarily limited to five filters - I think anything more becomes
 too complex for the average web user that I would point this to,
 and it also got messy on this rinky dinky monitor.  Really, I think
 even five filters is too much, given the way that I'd be likely to use
 this (here's a URL with one implicit filter that defines the set of
 photos that I want to show you right now).


 Multiple views into the same archive

 One goal I had was to allow multiple people (my, my girlfriend,
 my sister) to all have the ability to have their own sets of photos
 published via different URL's, and that's really easy with this
 system because you just copy the php scripts, modify the config
 file to point to a different tag to look for, and away you go.  The
 only downside is the replication of cached files - but I reason
 disk is cheap (ha!) and we're unlikely to be publishing the same
 sets of images anyway.


 cheers,
 Jedd.



 * As it happened, just before I sent this email, 24 hours ago, I
 went to confirm my server was alive - and it had disappeared.
 My sister returned home about 5 hours ago, and reports a power
 outage had occurred, with simply stunning timing - although usually
 I'd expect the power outage to occur several minutes after I
 sent such an email to a list, rather than several minutes before.

 In the interim I sync'd to another server, which I'll retain:
 http://www.progsoc.org/~jedd/kphpalbum