Mar 21

More on this topic later - for now, posted on the About page at

The media gallery at, now hosted with In the spirit of simplification, I have elected to move my media hosting to a service.

For the investment made in customization to the legacy media gallery that I self-host at using zenPhoto, I will retain the implementation as-is.

Sadly, I found that my schedule and life-obligations simply aren't conducive to the model which requires high-touch involvement to the population and maintenance of a proper media gallery, and that a service, such as that offered by zenfolio, solves these, and other problems. There truly is a reason why so much of what we do online is moving into the proverbial cloud.

I am excited for the new adventure - hours of painstaking due diligence have gone into the final decision to move this effort to a service provider, and to ensure that I have selected the right one for my purposes. While I forfeit complete control and a richer set of minor features, what I gain in performance, ease of use, and a model that lends to adoption makes the wiser decision. In other words, I will tend not to entangle myself in the weeds of web app development and administration by relinquishing some control in favor of pure function of design and purpose. Free at last...

Welcome, and enjoy!
Adam Krause

Posted by Adam KrauseGo w.i.d.eTweet MeShort URL

Feb 26

I happily received my invitation to the Instagram API developer's party the other day, and have since carved a few moments to give it a once-over.  Sadly, there is no shrink-wrapped PHP class or port - only Python and Ruby.  Ruby is a foreign language to me, and Python is not an altogether foreign language, but at least a dialect that I'm not completely at home with.  It's unfortunate that PHP wasn't considered as part of the initial API release, and seems more unfortunate in that one enterprising individual released a PHP Instagram API prior even to the Instagram team doing so themselves.  Unfortunately, it seems that the author has been blackballed by the Instagram team to some degree, his API rendered "rogue", and future of his efforts left uncertain.

I'm determined to wait and see how things shake out.  Soon enough, I predict that an official port of the API will be available in PHP.  I only hope that in doing so, consideration is made for making it fully portable with no secondary dependencies (PEAR comes to mind) outside of the core PHP - it should be supremely simple, like any good PHP app is.  For now, I'll poke around a bit at the Python package, and forgo and real work towards an S9Y module.

Posted by Adam KrauseGo w.i.d.eTweet MeShort URL

Feb 21

A need has recently arisen which has sent me on a mission to explore the vast sea of directory listing scripts that are floating about.  I'd briefly considered writing my own from scratch, and possibly do so as an S9Y plugin, and I may still do so one day.  If done, I'm envisioning a pop-up panel in jQuery which, passed the appropriate directory as a variable, would give a tidy tabular listing of available files for download.  An option would include a sidebar panel which included a select list of available indexed directories, where when selected, the links to the files contained would be displayed in the sidebar panel.

But alas, there are many off-the-shelf options available, and I've far too many priorities at the moment to trouble myself with such an effort.  My search for the simplest, most functional directory listing script landed on Greg Johnson's "PHPDL" or "PHP Directory Lister" script.  Of all that I looked at, Greg's was the best marriage of function, simplicity, and lightness of weight.  Completely self-contained, index.php delivers not only the UI framework and backend PHP directory reader, but all of the supporting collateral as well.  This is to say that various icons and images used throughout the script are stored as binary encodings within, as are the javascript libraries, and so on.  Not many folks use this approach (I've done this only a time or two), which is unfortunate as it makes for cleanliness and supreme portability.

I did, naturally, feel compelled to make one or two (or three) minor changes.  These include:

  • Re-theme to compliment the i3theme of the site.
  • Add sorting via jQuery.TinySort.
  • Prevent indexing of .htaccess.

The re-theme was fairly straight forward, mainly adjusting colors, and the usual.  However, in keeping with the i3theme's rounded corners look, and the script's incorporation of all image collateral within the body of the script itself, I pulled the top and bottom (image) borders out of i3theme, base64 encoded them, and included them within the body of the script.

Adding table sorting via jQuery.TinySort was straight forward as well.  As Greg includes jQuery already within the script, it was only a matter of packing TinySort, then base64 encoding it for a reduction of 1300 characters, and from 127 lines to only one.

Preventing the indexing of .htaccess was a simple hack within the body of the script where it already evaluates exclusions such as the script itself and references to the parent directory.

The styling could use some further tidying up - I was mostly going for quick and dirty, and am quite sure that I've left some irrelevant CSS in place...perhaps a project for another rainy day.  In the meantime, I've left all of the original credits in place, and put the work I've done here.  Look for


Posted by Adam KrauseGo w.i.d.eTweet MeShort URL

Feb 13

I finally got around to re-enabling the iPhone theme for zenPhoto.  This was a task of minor importance that I've been meaning to address since upgrading to ZP 1.4.  I had anticipated more problems with the theme in ZP 1.4 than I actually encountered.  As it turns out, there were one two deprecated functions to deal with, and I learned of an effort underway to build mobile-detect plugin for zen which serves-up an admin-definable theme for a wide variety of mobile platforms.

First the mobile-detect plugin - I've installed this in dev for the moment and deployed the iPhone theme to production using the original iPhone-detect hack which involves a slight modification to one of the ZP core files (functions.php).  As I've already touched other core(ish) files, I figure one more small modification in functions.php isn't going to make my life any more complicated at upgrade-time than it already is.  One day, I plan to revisit the mobile-detect plugin for it's do-it-the-right-way approach, and it's broader detection and handling capabilities.  For now, this zen plugin can be found here.

Now, the minor adjustments needed to bring the theme into ZP 1.4 compliance.  The two deprecated functions are "normalizeColumns()" in normalizer.php, and "zenJavascript()" in album.php, gallery.php, image.php, index.php, and login.php.  "normalizeColumns(1, 4)" should be replaced with "setThemeColumns(1, 4)".  "zenJavascript()" should be replaced with "zp_apply_filter('theme_head')".

As I'd written about in a previous post on the topic of incorporating a login into the iPhone theme to support private albums, I found a couple of new spots where superfluous information in the album titles was getting in the way of a clean UI.  I'm not sure at what point I missed this, or something changed in a more recent release, but sweep of the same five files listed above requiring the replacement of zenJavascript() revealed a handful of instances where getAnnotatedAlbumTitle() needed replacing with getBareAlbumTitle() - quite simply, I replaced each and every instance.

Here's the finished product, implemented against ZP 1.4, looking much the same as it did for ZP 1.3 - which is a very good thing.Smile

iPhone Theme for ZP 1.4

Posted by Adam KrauseGo w.i.d.eTweet MeShort URL

Jan 31

I spent a few minutes this evening working out the problem of why my mobile blogging apps refuse to display my category information, and am happy to report that I've resolved the issue.

At some point, I'd written about this before, and back-burnered the issue for more pressing matters.  I figured it was due time to put the problem to rest, so did a bit of digging.  In the end, the solution proved a simple one, though a little perplexing to someone (me) who doesn't have a very firm grasp of the various XMLRPC API floating about.

First a little background:
In BlogWriter, there were always as many blank category list items as there were categories (so I knew it was getting somewhere), and in BlogPress, the app would just crash when trying to fetch the categories.  Meanwhile, DeepestSender for Firefox did everything it was supposed to do.

Narrowing the problem space:
I narrowed the problem down to the metaWeblog_getCategories function in (this can be found in the plugins/serendipity_event_xmlrpc directory).  Look at, or around, line 182.

The solution:
Changing 'description' to 'categoryName' does the trick for both BlogWriter and BlogPress - however it does break DeepestSender. No telling what other desktop authoring apps this change would break, but it fixes the mobile apps, and that's all I personally care about.

    foreach ((array) $cats as $cat ) {
        if ($cat['categoryid']) $xml_entries_vals[] = new XML_RPC_Value(
//              'description'   => new XML_RPC_Value($cat['category_name'], 'string'),
//  PigsLipstick: change 'description' to 'categoryName' to support mobile publishing
              'categoryName'   => new XML_RPC_Value($cat['category_name'], 'string'),
              'htmlUrl'       => new XML_RPC_Value(serendipity_categoryURL($cat, 'serendipityHTTPPath'), 'string'),
              'rssUrl'        => new XML_RPC_Value(serendipity_feedCategoryURL($cat, 'serendipityHTTPPath'), 'string')

The results:
BlogWriter for iPhone is now treating me quite well.  I can author, assign categories, and publish with no problem.  Sadly, the richer BlogPress app still falls short by failing to publish...categories function now (without crashing the app), but a new article will only get as far as draft mode.

//  PigsLipstick: change 'description' to 'categoryName' to support mobile publishing

Posted by Adam KrauseGo w.i.d.eTweet MeShort URL

Jan 8

The zen team has released version 1.4, almost concurrent with the completion of my virtual postcard package.  I've dropped 1.4 for compatibility testing and it seems that all is well aside from the use of a deprecated function (isMyAlbum) used in controlling access to the virtual postcard UI.

So, instead of including zen_postcard_ui.php on condition of "if (isMyAlbum($_zp_current_album->name, EDIT_RIGHTS))", and because I've since determined that these rights are too strict anyway, better to use "if(zp_loggedin(POST_COMMENT_RIGHTS))" which has the effect of making virtual postcards available to users who have permissions to post comments.

The updated readme now reads (excerpt):

5. I don't want to permit the world to send postcards (potentially spam) from my gallery,
so I lock down postcards to folks that I also trust with comment rights.  This is the final
block to include zen_postcard:
        <?php if(zp_loggedin(POST_COMMENT_RIGHTS)) {

I've revved the package to 1.1 and retained the original download point.

Posted by Adam KrauseGo w.i.d.eTweet MeShort URL

Jan 7

Here it is, the readme for zen_postcard and a link to the package...

->: zen_postcard
ga: 1.0 (Jan 7, 2011)
by: Adam Krause
@@: /

zen_postcard is a hack-in for zenPhoto.

The objective of zen_postcard is to provide basic electronic postcard functionality
from within the zenPhoto/zenPage gallery image view UI.

While there is no administrative interface as yet, I've tried to make implementation
a simple affair by requiring only the inclusion of the zen_postcard_ui.php file, and
a small handful of configurables in the zen_postcard_mi.php file.

Following the steps below should yield a working zen_postcard install barring possible
connectivity/transport problems with the mail server that services your domain.  Mine
happens to be ubiquitous combination of Apache on Linux using sendmail.

1. Move the complete contents of the zen_postcard directory (including the directory)
to your zenPhoto /plugins directory.
2. Find image.php in your zenPhoto /themes/<theme name> - I use zenpage, so would
look for: /themes/zenpage/image.php.
3. Find the location in image.php where you would like the link that opens the
zen_postcard sub-UI to live.
4. zenpage contains a block referencing printRating, printImageMap, printShutterfly.
I like the zen_postcard opens its sub-UI just above the Ratings section, so this is where
I include zen_postcard_ui.php.
5. I don't want to permit the world to send postcards (potentially spam) from my gallery,
so I lock down postcards to folks that I also trust with edit rights.  This is the final
block to include zen_postcard:
        <?php if(isMyAlbum($_zp_current_album->name, EDIT_RIGHTS)) {
6. Open zen_postcard_mi.php and update the following:
$sendername = the name that you want in the "from" line on the email sent.
$senderemail = the email address from which sendmail will send the email - this must be
a valid account on the server.
$subject = the subject line of the email.

There are several constants to consider...
1. You can add as many postcard backgrounds, stamps, and fonts as you wish...
2. However, postcard backgrounds are expected to be 570px Wide x 378px High.
Stamps are 107px Wide x 120px High.
3. Fonts must be TrueType (.ttf) files, and for each font, a corresponding image must
exist that shares the font name and is 420px Wide x 40px High.
4. Added collateral must be referenced in zen_postcard_ui.php - look for the unordered
list <li>xx</li> blocks and follow suit with your additions.
5. An empty sub-directory "outbound" must exist in zen_postcard with permissions that
allow zen_postcard_mi.php to write to it.
**5. It may not apply universally, but it does seem that certain PHP functions used in
this package can be especially sensitive to file names that contain any characters
outside the alpha/numeric range, exclusive of dash and underscore.  This also includes

For all postcards sent successfully, where there is a send failure, or where PHP chokes on
a bad image file (usually due to file name), the relevant information will be trapped in a
log file "zpcsendlog.txt" in the zen_postcard directory.  You may see error_log in this same

It should be noted that there is no universal standard shared across all mail clients
to support rich mail formatting.  You can expect that zen_postcard email will look differently
in different clients; however, the postcard itself, as it is a single compiled jpeg image,
should always look the same regardless.

The sub-directory "outbound" receives compiled postcards which are then picked up for mail
processing.  Each file is uniquely named, and subsequently deleted once fully processed.  
The final function call in zen_postcard_mi.php "unlink($outbound)" can be commented out to
retain these files, which can sometimes be helpful in troubleshooting...or if you're nosey.

Since there was no compelling reason to reinvent the wheel for this project, I tried to give
credit where credit is due to the folks from whom I significantly leveraged their work.  
You can find this information in the .js file, and in various articles at

The package can be found here.

This concludes our broadcast of the exhilarating path to completion of a postcard plugin (hack-in really) to the zenPhoto gallery app.  It was challenging in new ways, ends happily, and didn't take too long to accomplish. Cool

Posted by Adam KrauseGo w.i.d.eTweet MeShort URL

Jan 6

The machine interface for the zenPhoto Postcard project is just about wrapped up. 

This, the machine interface, is the bit that handles compilation of the various elements of the postcard (the background, the stamp, the text, the font) into a single JPEG image, constructs the email body, and passes it off to the mail server.  In addition, there is a certain amount of error checking and some actual logging that occurs.

The final core challenge in the project was/has been finding a supremely simple method for handling embedded image email.  There are some well known classes available that make this relatively straight-forward, such as PHPMailer.  However, in the spirit of absolute simplicity, I found simpleEmailClass to be all that this project requires - low overhead, small footprint, incredibly simple to understand (which makes it easily adaptable), and does what it's intended to do.

Up to this point, I've spent essentially no time at all in dark dark woods of rich mail formatting and all of the myriad conditions that cause any given attempt at formatting to look so grossly different across mail clients.  If there is any consistency in this discipline, it's that there is no consistency (or discipline it seems).  One can count on the formatting to appear differently in different web clients (Hotmail, Yahoo, Gmail, etc), native clients (Outlook, Outlook Express, Opera, Thunderbird), and even different versions of clients (Outlook 2007 vs 2000), and so on.  I'll leave it to the reader to find various best practices (more like vague suggestions) for rich mail formatting - I ignored most of them, decided against tables, and used inline CSS to come up with formatting that looks fine in Opera and Yahoo, and is passable in Outlook, Outlook Express and Hotmail.  Luckily, for the purposes of this project, the only that really matters is that the postcard is embedded in the email body to avoid the recipient having to click on an attachment.

Here is a picture of the finished product as it appears in Opera - image the same without the borders/background/text formatting as it would appear in Outlook/Outlook Express:

zenPhoto Postcard Live in Opera

What's left to do?  Aside from properly "zen plugin-izing" the package, which I probably won't do any time soon, the only significant thing left to do is consolidation of the configurables (either into a config file, or into the tops of their respective pages).  A secondary effort should be made in defining certain rules or constants (for instance, it is assumed that all postcard backgrounds and stamps will be of a certain size).  Finally, if I really wanted to build in flexibility, I'd make the source images for the jCarouselLite widgets dynamic by letting PHP read the file system and build the image lists on the fly - though I doubt I'll bother with this any time soon.

Posted by Adam KrauseGo w.i.d.eTweet MeShort URL

Jan 2

I've polished the zenPhoto Postcard UI by adding the obligatory jQuery fade-in/fade-out banner on success/failure of form submit, and some controls to better control double/multiple submits.  I know there are prettier ways to do this, but I'm going for quick and simple.  So, on submit, the very first thing I do is take away the submit button altogether.  After this, and once I understand whether the submit has succeeded for failed, I note it as such, and give back the submit button.

However, prior to this, I do test for a valid email address in the recipient's field.  I considered doing the same for sender, but I've decided that I really don't care too much if the sender address is valid...if it is, the sender will receive a copy - if not, well, they know what they sent and it's easy enough to fake-out anyway, so we're really not achieving much by enforcing a valid address anyway.  For this, I looked at the jQuery Validation plugin, which looks (and is) very nice, but was far more than I required.  Instead, I've adapted a bit of Joren Rapini's form validation script to do in 15 lines (+3 more of CSS) what jQuery Validation does in about 1,100 uncompressed lines.  Come to think of it, 15 lines includes a comment and a couple of variables which could just as easily go in-line.  (Don't get me wrong, the jQuery Validation plugin is quite nice, just many times more than what I require...complete overkill for the single bit of validation that I'm performing).

Here is the bit that controls validation, double-submits, form submit and success/failure:

        email = $("#zpctoaddr");
        emailerror = "Please enter a valid e-mail.";
        // Validate the e-mail.
        if (!/^([a-zA-Z0-9\.\-])+@(([a-zA-Z0-9\-])+\.)+([a-zA-Z0-9]{2,4})+$/.test(email.val())) {
            return false;
        $("#zpcsubmit").css("display", "none");
        dataString = $("#zpcform").serialize();
            type: "POST",
            url: "plugins/zen_postcard/zen_postcard_mi.php",
            data: dataString,
            dataType: "json",
            success: function(data) {
            error: function(xhr) {
        return false;

   if ($(this).hasClass("zpcvalidate") ) {

Posted by Adam KrauseGo w.i.d.eTweet MeShort URL

Jan 1

In the previous zenPhoto Postcard post I reported some apparent anomalous behavior with the zen API getUnprotectedImageURL and/or getProtectedImageURL - this is what I'm leveraging to pass the current gallery image reference from the Postcard UI to the machine interface where PHP then fetches the referenced gallery image and builds it into the compiled postcard.

Well, ask any career IT QA analyst and you're likely to hear all manner of epic battles fought against flaky application that boiled down to some simple condition of the test routine itself, the key-critical factors leading to test failure of which went un-noted for far too many hours/days/weeks.  Such is the case here...

The discovery: in this implementation, PHP's imagecreatefromjpeg() has particular disregard for file names which contain spaces.  This is noted to a certain extent at, but oddly not called out as a major gotcha - this leads me to believe that the behavior is at least somewhat conditional...on what, I'm not entirely sure yet.  As usual, it was largely chance which made the problem seem so frustratingly inconsistent - having one of five to ten sample files that I'm working with which contain a space, and randomly selecting it among several, and all-the-while not paying close enough attention to the broader set of factors...well, it's the same old QA trap described above.

So, while hours were spent trying to ascertain the cause of such inconsistent behavior, the discovery was an important one to make now, rather later as I can do certain things to account for it proactively.

Posted by Adam KrauseGo w.i.d.eTweet MeShort URL

Dec 31

Getting closer...the UI for my zenPhoto Postcard project is effectively done.

Here's a screen capture showing a fully functional UI:

zenPhoto Postcard UI

Pointing out a couple of features...

  • The postcard UI is conveniently hidden on pageload and opened by way of the Send Postcard link, at which point the caroursels (see below) are populated, and so on...the hope is that this gives a cleaner interface, and lighter weight page.
  • The postcard background is selectable (rotates in-place via jCarouselLite by Ganeshji Marwaha).
  • The stamp is selectable (rotates in-place via jCarouselLite).
  • The font is selectable, however, the font is only picked up in the finished product (the compiled postcard).
  • The sender email is pulled from same API that populates the comment email address, if the user is logged in.  Note that I'll be setting my postcard install to be available only to authorized users.
  • There is inline prompting in the recipient's email field using Remy Sharp's Text Box Hints.
  • The user gets a fadein/fadeout success/failure banner upon sending.

I've one small issue to work out to get to consistent successful resolution of the image being applied to the postcard - this is apparently some sort of zenPhoto API strangeness, but should prove easily resolvable, I think.  Once done, a few cleanups in the Machine Interface where the card compiling occurs, and finally the transport (email) logic.

Edit: figured out the issue noted above...see next post...

Posted by Adam KrauseGo w.i.d.eTweet MeShort URL

Dec 19

As mentioned in the previous post, I've been giving some thought to a virtual postcard feature for my zenPhoto implementation.  It seems there is nothing that's already been done for this in the zen community.  Personally, I find this highly surprising given the total number of plugins and hacks that exist for zen.  The postcard feature is/was one of my favorite in the Coppermine package, and was hard to give up when I moved to zen, but I've noticed that the availability of such a feature seems hit-or-miss at best in the world of self-hosted online galleries - I'm not sure why, but it is what it is.

I did a fair bit of research on the topic, looked and and evaluated a handful of scripts, and came to realize that I wanted something that was simple (i.e.: no admin interface, no support for stand-alone functionality, etc), and that it should email an actual postcard, and not simply a link.  It seems many, if not most packages available, email a link to the recipient informing that a postcard is available and waiting to be picked up.  This is less impactful, I think, than having the actual postcard in-hand, which removes the burden of action from the recipient and provides a better guarantee that the postcard will be seen and enjoyed.  Second, as postcards may be sent with otherwise secured images attached, I can't guarantee (and don't care to tackle the functionality) that the recipient would be able to access the photo associated with the postcard being shared.  Therefore, emailing the photo as part of the postcard simply makes sense.

Now, there are two approaches - one includes constructing the postcard of separate content elements within a fully HTML-formatted email.  simplEcard does this and it works pretty well.  If this is the extent of the functionality desired, then I highly recommend looking at simplEcard as a great framework for starting the project.

A second approach includes sending the fully compiled postcard as a single image.  There aren't many open source packages available that seem to do this, though there are a couple whose names escape me at the moment.  The key advantage, as I see it, in this approach - guaranteed "you get what I sent", more easily printable, can be saved with all content intact.

Approach #2 is where I've decided to contentrate my efforts, and it's brought me into previously uncharted territory with PHP - which is nice, because it keeps things interesting.  In the past, when I build the original blog for PigsLipstick and hand-crafted it from start to finish (which included a photo gallery), I'd incorporated some basic image manipulation features, such as resampling and resizing, rotation, and some general file handling.  This time, I'm delving deeper with text-to-image and image merging, transparency, and image creates.  What I've mocked up to satisfy approach #2 follows in example - you'll notice the photo merged onto the postcard template as a background - same with the stamp.  The text is raw text converted to an image and merged onto the background.  The output of all of this is a single .jpg image:

zenPhoto Postcard Mockup

Here is the script that does all of this - finds the background, the picture, the stamp, and converts the text string into an image...merges it all together, and outputs a single .jpg.  Notice how I give the picture, the stamp, and the text a little opacity so that it looks more authentic.  Notice also how the text looks like it was scrawled across the stamp.  The overall effect, I think, is really quite nice.  Another beauty is the way in which this can all be easily variablized - changing the stamp, changing the picture, changing the text, the font, the color, and background...all very easily accomplished.

$txt = imagecreatetruecolor(400,400);
$text = "My Test Text Here With a\n few tall letters...";
$font = "plugins/zen_postcard/dali.ttf";
$bgcolor = imagecolorallocate($txt,234,254,254);
$txcolor = imagecolorallocate($txt,21,1,1);

$postcard = 'plugins/zen_postcard/images/background1.jpg';
$picture = 'plugins/zen_postcard/images/jun1-014.jpg';
//$stamp = 'plugins/zen_postcard/images/eagle-stamp3.jpg';
$stamp = 'plugins/zen_postcard/images/am-indian-stamp3.jpg';
//$stamp = 'plugins/zen_postcard/images/lincoln-stamp3.jpg';
$DestinationFile = 'plugins/zen_postcard/images/alldone.jpg';
$card = imagecreatefromjpeg($postcard);
$pic = imagecreatefromjpeg($picture);
$stamp = imagecreatefromjpeg($stamp);



$opacity = 75;



if($DestinationFile<>'') {


That is all for now - the next phase will include the bits needed to put a UI in front of this.  This UI will give the text field in which to enter the message, auto-populate the picture (and account for portrait vs landscape) based on the picture being viewed at create time, and provide a means to select the desired stamp.

Posted by Adam KrauseGo w.i.d.eTweet MeShort URL

Dec 15

I've got the gallery where I want it, and drawing the line at this point save for one feature that I'm thinking through.

In a nutshell, I brushed up bits and pieces of the UI, taking care to concentrate all changes to the zenPage theme style sheet and template pages.  The last thing I want to do is touch core content and risk an implementation that can never be upgraded in the future without significant rework.  That said, there was one minor change made in the comments page under zp-core/zp-extensions to pull the comments show/hide button into unused real estate next to the comments block header.

I had all the various changes fairly-well detailed, but lost the post in an unfortunate session timeout accident, so to summarize and reinforce with pictures:

  • Changed all buttons to links
  • Restyled buttons that did not function well as links so that they look like links.
  • Tightened up a few odd pieces of the layout to eliminate dead real estate.
  • Modified the use of printTags() and printImageDesc() to display only when content exists regardless of whether the user is logged in, or not.
  • Modified the use of printTags() and printImageDesc() to diplay consistently whether the user is logged in, or not, and whether the user is an edit-admin, or not.
  • Built a panel (of sorts) that provides Tags management and Image Description management in the UI, and displays only for edit-admins.
  • And of course the calendar plugin which I'll get to in a separate post.

This leaves only the remaining item that I wish to incorporate - something that I really enjoyed in the ages-ago Coppermine implementation, and that is: A "send image as postcard" feature.  I'm evaluating scripts for this now, and hope to have something that provides the foundation I'm looking for to re-work and build into zen.

Here are some screen shots for posterity and amusement:

The Sidebar Calendar The Image Info Area default view The Image Info Area expanded view

In taking my screen shots, I noticed a little styling bug in my Quick Edit comments box - my right-alignment is having a rather dodgy effect on the comments, as is the border property.  I'll fix this soon enough, though it only impacts me alone.  You see though, examples of restyled buttons, elements that have been slightly repositioned to tighten up the layout, and other minor brush-ups that give a better overall UI experience.

Posted by Adam KrauseGo w.i.d.eTweet MeShort URL

Dec 12

As I wrote over in the Gallery News some weeks back (three to be exact), I'd become disenchanted enough with my avoidance, and general lack of use of the photo gallery, that I finally decided to do something about it.  I came to realize that the number-one reason I disliked the gallery so much was due to the effort involved in administering it.  Namely, the prospect of having to sift through so many photos to categorize and label them.  There is something that I find utterly distasteful about organizing reams of photos - a strange aversion considering I normally embrace organization, and have a passion for logical data models.

So, in the spirit of moving to a super-flattened categorization model - one where there is basically a public gallery and a private gallery, each with a photo album and a multi-media album, I decided what better opportunity to upgrade.  Well, somewhere along the line, I altogether botched the upgrade (it's remotely possible that it was due to my un-calculated decision not to read documentation first and execute the upgrade in production directly - so let that be a lesson learned).  In the end, I've been better for it as I've come to realize that the original zenPhoto install was never fully configured and generally ill-planned.  This time around, I worked a lot harder to understand all of what I was doing as I spent the better part of the week on configuration alone.  For this, I've learned more about zen than I'd ever have known otherwise, and am even more impressed with it now than before.

For zen, I'm using the zenPage theme, which is now baked into the distribution as a packaged (and more tightly integrated) CMS wrapper around the gallery software itself.  One could probably run a fairly effective site on zen alone, if they so desired, leveraging zenPage for textual content, a scaled-down blog, etc.  A little css tweaking to nail the visuals has really brought the ends together and put me back onto the gallery as an item of interest.

A topic for a follow-on article...a sidebar calendar for zenPhoto.  Oddly, this simply didn't seem to exist prior...well, until now... Wink

Posted by Adam KrauseGo w.i.d.eTweet MeShort URL

Nov 23

I've put a small update into the TinyBrowser FTP Uploader - this change addresses problems with spaces in file names by replacing them with underscores.  This is standard behavior of the traditional HTTP/Flash file upload process in TinyBrowser and was an unfortunate omission in my initial release of the FTP Uploader.

The updated version can be found here.

Posted by Adam KrauseGo w.i.d.eTweet MeShort URL

(Page 1 of 8, totaling 119 entries)

Strict Standards: Declaration of serendipity_event_s9ymarkup::event_hook() should be compatible with serendipity_event::event_hook($event, &$bag, &$eventData, $addData = NULL) in /home1/pigslips/public_html/s9y/plugins/serendipity_event_s9ymarkup/serendipity_event_s9ymarkup.php on line 146

Strict Standards: Declaration of serendipity_event_s9ymarkup::uninstall() should be compatible with serendipity_plugin::uninstall(&$propbag) in /home1/pigslips/public_html/s9y/plugins/serendipity_event_s9ymarkup/serendipity_event_s9ymarkup.php on line 146

Strict Standards: Declaration of serendipity_event_emoticate::event_hook() should be compatible with serendipity_event::event_hook($event, &$bag, &$eventData, $addData = NULL) in /home1/pigslips/public_html/s9y/plugins/serendipity_event_emoticate/serendipity_event_emoticate.php on line 204

Strict Standards: Declaration of serendipity_event_emoticate::uninstall() should be compatible with serendipity_plugin::uninstall(&$propbag) in /home1/pigslips/public_html/s9y/plugins/serendipity_event_emoticate/serendipity_event_emoticate.php on line 204

Strict Standards: Declaration of serendipity_event_nl2br::event_hook() should be compatible with serendipity_event::event_hook($event, &$bag, &$eventData, $addData = NULL) in /home1/pigslips/public_html/s9y/plugins/serendipity_event_nl2br/serendipity_event_nl2br.php on line 395

Strict Standards: Declaration of serendipity_event_nl2br::uninstall() should be compatible with serendipity_plugin::uninstall(&$propbag) in /home1/pigslips/public_html/s9y/plugins/serendipity_event_nl2br/serendipity_event_nl2br.php on line 395

Strict Standards: Declaration of serendipity_event_browsercompatibility::event_hook() should be compatible with serendipity_event::event_hook($event, &$bag, &$eventData, $addData = NULL) in /home1/pigslips/public_html/s9y/plugins/serendipity_event_browsercompatibility/serendipity_event_browsercompatibility.php on line 80

Strict Standards: Declaration of serendipity_event_spartacus::event_hook() should be compatible with serendipity_event::event_hook($event, &$bag, &$eventData, $addData = NULL) in /home1/pigslips/public_html/s9y/plugins/serendipity_event_spartacus/serendipity_event_spartacus.php on line 1183

Strict Standards: Declaration of serendipity_event_imageselectorplus::event_hook() should be compatible with serendipity_event::event_hook($event, &$bag, &$eventData, $addData = NULL) in /home1/pigslips/public_html/s9y/plugins/serendipity_event_imageselectorplus/serendipity_event_imageselectorplus.php on line 1105

Strict Standards: Declaration of serendipity_event_imageselectorplus::uninstall() should be compatible with serendipity_plugin::uninstall(&$propbag) in /home1/pigslips/public_html/s9y/plugins/serendipity_event_imageselectorplus/serendipity_event_imageselectorplus.php on line 1105

Strict Standards: Declaration of serendipity_event_sidebarlogin::event_hook() should be compatible with serendipity_event::event_hook($event, &$bag, &$eventData, $addData = NULL) in /home1/pigslips/public_html/s9y/plugins/serendipity_plugin_sidebarlogin/serendipity_event_sidebarlogin.php on line 148

Strict Standards: Declaration of serendipity_event_popfetcher::event_hook() should be compatible with serendipity_event::event_hook($event, &$bag, &$eventData, $addData = NULL) in /home1/pigslips/public_html/s9y/plugins/serendipity_event_popfetcher/serendipity_event_popfetcher.php on line 1426

Strict Standards: Declaration of serendipity_event_lightbox::event_hook() should be compatible with serendipity_event::event_hook($event, &$bag, &$eventData, $addData = NULL) in /home1/pigslips/public_html/s9y/plugins/serendipity_event_lightbox/serendipity_event_lightbox.php on line 281

Strict Standards: Declaration of serendipity_event_lightbox::uninstall() should be compatible with serendipity_plugin::uninstall(&$propbag) in /home1/pigslips/public_html/s9y/plugins/serendipity_event_lightbox/serendipity_event_lightbox.php on line 281

Strict Standards: Declaration of serendipity_event_tinymce::event_hook() should be compatible with serendipity_event::event_hook($event, &$bag, &$eventData, $addData = NULL) in /home1/pigslips/public_html/s9y/plugins/serendipity_event_tinymce/serendipity_event_tinymce.php on line 291

Strict Standards: Declaration of serendipity_event_tinybrowser::event_hook() should be compatible with serendipity_event::event_hook($event, &$bag, &$eventData, $addData = NULL) in /home1/pigslips/public_html/s9y/plugins/serendipity_event_tinybrowser/serendipity_event_tinybrowser.php on line 150

Strict Standards: Declaration of serendipity_event_prettify::event_hook() should be compatible with serendipity_event::event_hook($event, &$bag, &$eventData, $addData = NULL) in /home1/pigslips/public_html/s9y/plugins/serendipity_event_prettify/serendipity_event_prettify.php on line 245

Strict Standards: Declaration of serendipity_event_xmlrpc::event_hook() should be compatible with serendipity_event::event_hook($event, &$bag, &$eventData, $addData = NULL) in /home1/pigslips/public_html/s9y/plugins/serendipity_event_xmlrpc/serendipity_event_xmlrpc.php on line 160

Strict Standards: Declaration of serendipity_event_podcast::event_hook() should be compatible with serendipity_event::event_hook($event, &$bag, &$eventData, $addData = NULL) in /home1/pigslips/public_html/s9y/plugins/serendipity_event_podcast/serendipity_event_podcast.php on line 939

Strict Standards: Non-static method TwitterPluginFileAccess::get_permaplugin_path() should not be called statically, assuming $this from incompatible context in /home1/pigslips/public_html/s9y/plugins/serendipity_plugin_twitter/serendipity_event_twitter.php on line 1554

Strict Standards: Non-static method TwitterPluginDbAccess::load_short_urls() should not be called statically, assuming $this from incompatible context in /home1/pigslips/public_html/s9y/plugins/serendipity_plugin_twitter/serendipity_event_twitter.php on line 1518