Using the Lightroom 4 Web module – Part 3

Welcome to part 3 of this series on using the Web module in Lightroom 4 to create a serious website.

In Part 1, I showed that the Web module as it’s supplied with Lightroom is simply not capable of doing the job for a professional or serious amateur photographer.

Part 2 I looked at a plugin solution — The Turning Gate’s CE2 system — and I discussed the various parts that make it up and my early experiences of using it.

Here in Part 3, I’m going to depart a bit from my usual style of relating an ‘as it happens’ account, simply because it’s all too complicated and full of backtracking and rethinking to make a coherent story. So this is being written with the benefit of several weeks’ use of the system and is more a collection of good points and not-so-good points, along with a few hints and tips for anyone who’s thinking of going down this route with their own website.

Disclaimer

In the course of this article, I’m going to be saying some things that appear fairly critical of the TTG plugins. I just want to make it clear that most of the perceived ‘problems’ with the system are not Matthew Campagna’s fault, but rather stem from the difficulties that I outlined in Part 1 regarding the suitability of Lightroom’s UI design for this sort of work. Basically, the Lightroom UI does not lend itself well to a good website creation workflow and it’s a huge credit to Matthew that he’s managed to create something that’s as good as it is.

That said, from a purely user point of view, there are — shall we say? — annoyances in the workflow that will crop up and that will cause frustration.

Let’s start by being positive

It works, and it does a great job. Once you’ve got over the learning hump, and things have started to become clear in your mind, it’s (relatively — see below) easy to make the changes you want and get the website of your dreams…ish. I went through several false starts before settling on the final design, but once I’d got that, things progressed really smoothly.

I ought to add that I cheated a bit: after mucking about with various designs, I took a shortcut and used the design that Matthew made for his tutorial articles. I did this partly so that I could get something up and running for the purposes of writing this article. I like the design but I may make something more personal in the future. I’d recommend using the templates in the early stages — maybe practice with a local site — to get used to the system, then go ahead and build your own design in the confidence that you now understand how it works.

So, on to lessons learned, tips, caveats, bugbears and plaudits.

Two, three… or four?

I said in Part 2 that realistically you need two of the plugins (a framework and a gallery) to create a decent website. Well, make that 3, since you’ll almost certainly want the Autoindex plugin to make multi-level galleries (Pages can only handle a single level of folders underneath the home folder).

And then you’ll probably want to embed your blog on the same website, so you’ll need to get the CE2 Theme for WordPress to make it all look nice and consistent.

So: four plugins for a total outlay of $100. Add hosting costs, and that’s about how much your website’s going to cost you, not counting the value of your time in constructing it. If you create more than one website, then the unit cost comes down but really, even for one site, that’s not unreasonable, considering how much a bespoke design could cost.

Read Matthew’s blog

Right, this bit’s important — it’s the most valuable thing you can do when starting out using the TTG plugins. There are about 8 articles at the TTG blog on advanced website creation. Read them. Then read them again. Then bookmark them for future reference — there’s a lot of information in there that will seriously speed up the understanding process.

Get the site framework right

Here we get to one of those bugbears (see ‘Disclaimer’ above). The various plugins share a lot of settings between them (the ‘CE’ part of the name means ‘Common Engine’). This is a good thing, since it makes it a simple matter to keep your look-and-feel consistent across the modules. It’s also a problem: the way Lightroom works means that every bit of your site is a separate Web gallery. These galleries don’t know about each other, they don’t talk to each other — they are independent entities. With a decent-sized site, you could end up with dozens of galleries.

This image shows the Lightroom layout for my site, and I’m already up to 24 Web galleries. I’ve used collections to mimic the basic website structure and numbered names to keep things in the order that I want.

Now imagine that you want to tweak the font, because you’ve decided that you prefer a serif to a sans-serif in the body text. You have to make that change to each gallery separately. Oh, there are a couple of shortcuts to speed it up a bit, but the bottom line is that you have to visit each gallery and make the change — there’s no notion of propagating or auto-updating from a template change. That mean’s that it’s easy to miss one and that leads to annoying inconsistencies.

So I would advise spending a good amount of time with the framework module (CE2 Pages in my case) and getting the look and feel right before moving on to the other modules.

Test on a local server

I’ll say it again: test your site on a local server before uploading to your host. I covered local servers in Part 2, so I won’t go over that, but I will say that the last few weeks have impressed on me even more the need to test locally before going live.

This especially true once you’ve got over the initial learning hump and you wanti to start adding some value to your site using PHP plugins. You really, really don’t want to upload untested PHP code to a live site.

For example, I had a problem when I was trying to add some breadcrumb navigation and my blog disappeared. Still haven’t figured that out. But, since I tested locally, there has been no effect on my real site.

The other advantage to testing locally is that it means that you can ignore the Upload button. This is a seductive mistress, but do not be tempted, it will bite you. For one thing, there appears to be a bug (or a feature) — the destination folder’ is not sticky, and the default isn’t even the standard ‘galleries’ folder. Every time you upload, you’ll have to change that setting, because it doesn’t get preserved with the other settings.

Much better to Export… somewhere local, test, then upload with a decent FTP client. I use Cyberduck, but other clients are available.

Centralize common stuff and use templates

Because of the (enforced) independence of the galleries that make up your site, there are things that will be duplicated unnecessarily — PHP code files, your favicon. I strongly recommend (as does Matthew Campagna) that you pick one location for these files and point to that one place from each web gallery.

This is fairly easily done by making extensive use of templates. Full details are in the tutorial series I referenced above, but what it boils down to is to have a template corresponding to each ‘level’ (i.e. depth in the folder hierarchy) and store the path to the files in that. Then, when you create a new gallery, simply choose the appropriate ‘level’ template.

Two templates differing only in the relative location of common files.

A ‘level 2’ path to PHP plugins

A ‘level 3’ path to PHP plugins.

On the subject of templates; take some time, when first creating one, to fill in as much common information as possible. Ideally, for a gallery template (Highslide, Horizon, etc), you want enough information so that all you have to fill in for each new gallery is the copy text, album title and description.

Having centralised your PHP (and, possibly, JavaScript) files, keep a backup copy of them. The simplest place to put them is in the top-level phplugins folder (it saves editing other files to change the location), but this will get overwritten if you re-export the framework gallery, and all your careful modifications will get lost.

Small things

Those above are my major tips when using this software. There are a few minor things that I noticed as well — not enough, in themselves, to tip the balance, but worth looking out for.

• Some of the social media icons are out of date. It’s a simple matter to get the latest ones from the relevant site and overwrite the existing one (do this in the actual plugin folder, so that you don’t have to remember every time you export).


• There’s what appears to be a bug in the Horizon module such that the space between the photos and the scroll bar expands and contracts with the height of the browser window.

• I said before that there are a lot of settings to keep track of. One down side of this is that, for a while at least, you’ll spend a lot of time trying to find the setting you want to change – until you get used to where they all are.


• Although, in general, you have to request a re-render of the page after making changes, adjusting the order of images in the filmstrip will trigger a re-render every time you move something. This can get irritating, so it’s best to re-order things in the Grid view and then go back to the Web module when you’ve done.

How could things be improved?

Difficult one, this. As I hope has become clear over the last three articles, my opinion is that Lightroom is not a good environment for web site creation. The whole paradigm is wrong, so any attempt to do something along those lines is doomed to compromise. It’s to Matthew Campagna’s credit that he’s done such a good job in producing something that’s usable and mostly effective.

One change that springs to mind immediately would be if the Web Galleries could be made to act like Publish Collections — i.e. if they could be made to update changes only, rather than regenerate entire web site sections. That would cut out a lot of housekeeping work — deleting old images on the server, protecting modified files, remembering which galleries you’ve updated…

Some communication would be nice, too — a way of propagating a style modification across all the galleries, so that you don’t get that ‘argh!’ moment when you realise that you really want to change a font, but you’ve got a dozen templates to update.

The bottom line

TTG CE2 is a very good solution for the photographer wanting a professional-looking web site, but it’s not perfect. It rewards research, planning and a methodical approach and it punishes carelessness.

On the whole, I’d thoroughly recommend it if you’re prepared to put in the work required, and you’re methodical enough to remember all the tasks that can’t be easily automated.

Graham Douglas – Grey Dog Photography

via X-Equals - Click. Download. Smile. http://x-equals.com/blog/using-the-lightroom-4-web-module-part-3/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+xequalsblog+%28X-Equals+%2B+Blog%29