To get things started, I took a stab at developing a website for her: olinda-gibbons.com.

I’m not 100% happy with the theme, but we kind of had to launch it under short notice so that we could post/sell images from a few events that she worked. I’ll probably re-vamp the theme over the summer when I have free time, but at the moment there are some really cool things in there that I want to show off.

Auto Portfolio with a jQuery Gallery

One feature I definitely wanted to have was a portfolio page with some kind of nifty jQuery functionality. I looked through some options on this list of jquery gallery plug-ins, and I liked the galleria plug-in. Although I think it might now be out of development, I was able to get it working to my satisfaction with a static html demo.

Of course, I wanted to be able to easily and automatically create and change portfolios with WordPress, and the NextGEN Gallery plug-in for WordPress made that possible. I created a custom template file to display a gallery with the mark-up necessary for the Galleria plug-in to work. Now all I have to do is upload the pictures to a gallery, insert a piece of short code, and instant portfolio page. Nice.

There are two samples on the site now: Olinda’s portrait portfolio and her events portfolio.

Integrating PayPal Web Payment

The second thing I needed to do was integrate PayPal’s web payment system so that we could accept payments and then print/ship pictures after events. Portrait sessions can be handled through invoicing and other payment methods, but PayPal makes it really convenient to handle larger groups of people more efficiently.

Again, this was made possible by the NextGen gallery plug-in. I marked up a custom template to include the html mark-up for the PayPal payment buttons. Now, I just upload the proof images to a gallery and with one piece of short-code I have an instant ordering page.

This is a place where I definitely want to work on a better design, but I was working under short notice and just wanted something functional…

Example: William Paterson Fashion Show proof album.

How Did I Do It?

I plan to write up some detailed guides to how I designed those pages. I’m not sure if I’ll post them here or start up a blog section on olinda-gibbons.com and post it there. Either way, I’ll post about the guides here because I think they’ll be valuable for anyone looking to develop a site for a photographer. The more I work with it, I’m really impressed with the combination of WordPress and the NextGen gallery plugin.

There are a number of things I like, but there is one thing that everyone can use: Google’s hosted Javascript libraries.

Last year, Google launched a project to host a handful of popular Javascript libraries. Among the initial offerings is jQuery – the Javascript library that I use on this site. They also have some other widely used options – like prototype and MooTools.

Basically, Google hosts the most recent (and some legacy versions) of the library on its server. You can then link the remote copy of the JS library to your site instead of hosting it yourself.

Why Should I Use Google Hosted Javascript Libraries?

Because it could be faster.

If two sites use the same Javascript library but host it locally, the user has to reload and recache the library for each site. jQuery.js on life-of-brian.com is different from jQuery.js on css-tricks.com – even if the file is exactly the same.

By pointing the user’s browser to the Google server, it will recognize that .js file in the cache and not download it a second time. So if life-of-brian.com and css-tricks.com both used the jQuery library on Google’s servers, the user would have to cache it once – and it would be preloaded when he or she visited the second site.

A secondary benefit (of concern only to large sites) is that it doesn’t put a strain on your bandwidth. This shouldn’t be a big deal for most people, but some high volume sites may find this comforting.

How Do I Load Google’s Hosted Javascript Libraries?

You could use the fancy load() function of Google’s AJAX API, or you could simply add a <script> element using the remote address on Google’s server.

I chose to go the second route with this site. I wanted to load both the jquery library and the jquery ui library (mainly for the tabs in the sidebar), so I included the following two lines in my header:

<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.2.6/jquery.min.js" type="text/javascript"></script>
<script src="http://ajax.googleapis.com/ajax/libs/jqueryui/1.5.3/jquery-ui.min.js" type="text/javascript"></script>

You can find a list of all the URLs on the AJAX API documentation page.

Why Not Do This?

I don’t see a lot of potential for harm, but there could be some drawbacks.

No version control. Presumably Google is going to keep hosting important legacy versions of each library, but this takes version control somewhat out of your hands. It also means you can’t use the development releases – only the stable releases are hosted on Google’s server.

No hacking the library. You won’t be able to introduce custom hacks into the library if its hosted on Google’s server. I don’t know how many people do that anyway. I’ve never jumped into to hack a compressed library file – I just use it as is and add any custom code to another .js file.

Google could sabotage your site. Unlikely, but I suppose it’s possible. If you’re paranoid, steer clear.

Check It Out

I’ve been using it for a week or so, and I haven’t noticed any problems. In theory, it’s a great idea, but it’ll only work if a large number of sites (especially highly trafficked sites in a variety of niches) opt to use it.

I’m going to do my part and point my users to Google’s servers. Why don’t you?

The plugin allows you to insert a Digg This badge in  your posts, but only have it appear if your post has a certain number of Diggs.  The idea is that you don’t want to promote the fact that your article only has one Digg – you only want to brag when it has 10, 20, or 100s.

The plugin ran into some problems, and I ran out of time to fix them.  As a result it’s dead.  However, I’ve recently had a few ideas on how to revive it and make it much more efficient.

The Old Plugin Method

The old plugin worked, but it was plagued with problems.  Most notably, it had a delayed effect and the badge wouldn’t show up for 10 or 15 seconds.  If it was used on an index page, it would slow down the loading of the page terribly.  It also broke when WordPress moved to version 2.5.

Most of the problems, I think, come from the way I designed the plugin.  I had just begun tinkering with the Digg API to grab information from the Digg database, so I thought this plug-in would be a useful way to fetch information about an article and have it dynamically update the way the article is displayed.

The plug-in relied on a bit of Javascript to insert or remove the Digg Badge.  The JS used AJAX to contact the Digg API via a tiny php script.  If there was a sufficient number of diggs, the Digg Badge would be inserted.  Otherwise, the container div would just remain empty.

A Better Method – No More AJAX

Recently, I had an idea on how the plugin could be improved and re-implemented.  The loading problems seemed to derive from the Digg API – it sometimes lagging in response time, which prevented the Digg This Badge from appearing in a timely fashion.

A more streamlined method would be to use CSS to toggle the display of Badge on and off and use JS to find out how many Diggs the article has.

The Digg This Badge is contained in an iframe, which contains in its source the number of Diggs the post currently has.  If you look in the source of your page, you’ll see the src of the iframe.  Load that page and view its source.  You’ll see a line like…

<strong>1767</strong> diggs

It should be possible to use Javascript (and possibly jQuery for convenience) to access the iframe’s source, dig up the number of diggs, and then toggle the display attribute of the iframe on and off.

I tried testing this out last night, but I ran into some browser compatibility issues.  In Firefox, I was able to access the contents of the iframe.  However, both Google Chrome (my browser of choice) and Internet Explorer balked at the code.  It generated an error somewhere inside the jquery file itself, and any time I tried to access the contents of the iframe the script aborted.

The concept seems sound.  I just need to find a way to make the javascript work in Explorer.  Regardless, I’ll work up some code examples later on how to use jQuery to access an iframe.

The advantage of this method is that there should be no lag time at all.  As soon as the Badge would normally load, it should be a fraction of a second before the Javascript function to evaluate its logic and turn on the display attribute of the iframe.