The Turning Gate » Tutorials

Tutorial: Google Web Fonts + TTG

theturninggate — Tue, 24 Aug 2010 07:43:31 +0000

Compared to the world of print design, web-designers have always had the short end of the typographic stick. While seemingly infinite possibilities exist for typography in print, web-designers have always been restricted in that specified fonts will only display in the end-user’s browser if that font is installed on their machine. And so web pages have ever relied upon fonts such as Arial, Helvetica and Verdana to name but a few, fonts known to be common on all computer systems. Simply put, web-designers’ typographic options have been limited.

As is often the case, Google comes to the rescue — this time with Google Web Fonts. Google Web Fonts and the Google Font API allow web-designers to utilize a selection of new open-source typefaces on their web pages, and doing so is as simple as adding a snippet of code to your pages, and then specifying the font to be used in your styling instructions, per usual.

If you’re not a web-designer, I realize that last sentence might have frightened you. Bear with me a moment and all will be made clear and simple.

TTG web engines already include robust options for choosing and customizing font stacks for use in your web pages and image galleries. For those of you wanting still more options, however, Google Web Fonts integrates easily with the existing TTG feature set and offers a world of new typographic possibilities.

To begin, you will need to be using one of the more recent TTG web engines — such as TTG Pages or TTG Highslide Gallery — which contain controls for …

… Custom font stacks, such as this:

… Advanced Options, usually located in the Output Settings control pane and including the “Add script in ” option:

Having confirmed that, visit the Google Font Directory at the following address to check out your new typographic options:

http://code.google.com/webfonts

Step 1: Choose a Font

On visiting the Google Font Directoroy, you will be presented with a list of available fonts. These fonts are open-source and therefore free for you to use in your web pages. Peruse the list and, when you’ve found a font that you like, mouse over it to highlight your selection in blue. When you do so, you should see the words “Click to embed [font name]” appearing to the right of the list. In the screen capture below, I have highlighted the words in red:

Click these words to advance.

Step 2: Inspect your chosen font, Get the code!

And so I’ve chosen Droid Sans. The next page displays several examples of the font in use at various sizes and weights.

If you are satisfied with your selection, click the “Get the code” link highlighted in blue.

Step 3: Download and install the font(s)

This third step is optional, though recommended. You would probably like to be able to preview the font within Lightroom, and to do that you will need to have the font installed on your system. And so, on the page subsequent to clicking “Get the code”, scroll to the bottom of the page where you will find the font files available for download:

At this point, if you have Lightroom running, Quit Lightroom.

Download and install the new fonts; font installation will vary according to your operating system, but can usually be achieved simply by double-clicking the font file(s). Consult your operating system documentation should you need further explanation on how to install fonts.

Once you have completed installation of the fonts, you may launch Lightroom.

Step 4: Add the Google Web Font(s) to your image gallery

And now the sexy bit; it’s time to enable the new font in your web gallery. Because knowing is half the battle, understand that …

… you are able to view the font within Lightroom’s web preview because you have installed the font on your system (accomplished in Step 3, above).

… visitors to your gallery may not have the font installed, but will be able to view the font on your page because it will be fetched from the Google Font Directory.

These points establish that once you have completed Step 4, exported your gallery and published it to the web, everyone will be able to view the font on your web page. Now, let’s get down to business.

On the same page from which you downloaded the font(s) in Step 3, scroll back to the top and locate the section titled “Embed the font into your page”, pictured below.

There should be several check-boxes for the typeface’s various styles — Regular, Bold, Italic, etc. Not all typefaces offer the full range of styles; for example, Droid Sans does not include the italic style. You may as well go ahead and enable all of the available options. As you do so, the code snippet will update to reflect your choices. When ready, highlight the code snippet in its entirety, then copy (CMD-C on Mac, CTRL-C on Windows).

Return to Lightroom’s Web module, then Paste (CMD-V on Mac, CTRL-V on Windows) the code into the “Add script in ” option in your TTG web engine:

Next, you will need to instruct you gallery components to use the new font by adding it to your font stacks. Back on the Google Font Directory page, located the sample font stack:

This will show you how to call the font by name when adding it to your own font stack. Please note that if the font name is more than a single word, it will be necessary to wrap the name in single-quotes when adding it to the font stack. For example, the font Droid Sans must be writting 'Droid Sans', when added to your font stack, including single-quotes and followed by a comma, like this:

Keep in mind that individual gallery components have their own separate font stacks. For example, the menu fonts, gallery description title, subtitle and paragraph text, page footer and image captions all have separate font stacks. Therefore, you should be sure to add the new font to all font stacks where you would like it to appear. Otherwise, go about styling your image gallery as you normally would. When you export and upload the gallery to the web, the page will fetch the new font from the Google Font Directory, and it will be visible to all site visitors.

Coda

In conclusion, we have learned that web fonts may be included in TTG web engines from Google Web Fonts. Google Web Fonts gives web-designers new options in choosing typography for web pages, and ensures that all visitors will be able to see the chosen fonts regardless of whether or not that font is installed on the end user’s system.

To utilize Google Web Fonts within TTG web engines, users need only to insert the code snippet — provided by the Google Web Fonts page — into the “Add script to ” field within the Output Settings control pane of engines such as TTG Pages or TTG Highslide Gallery, and then to specify use of that font in the engine’s font stacks.

Print Module Tip: Printing from JPGs saves time!

theturninggate — Sun, 04 Jul 2010 21:40:11 +0000

These days I spend a lot of time working in a commercial photo studio as a photo assistant and digital tech. At the end of each job, I’m required to print an 8×10″ contact sheet of the day’s images for filing, create a PDF of that same contact sheet for storing on the network, and a 4.75″ square version of the contact sheet to file with the backup DVD of the day’s images. What this amounts to is having Lightroom crunch large image files into prints a minimum of three times every day that we shoot, and that rendering time really adds up.

When having to create contact sheets of the same images in multiple formats, I’ve found this easy trick can save tons of time. First, export the images as JPG files and have Lightroom then re-import those JPGs to the catalog:

Once the export is finished, the JPG files will be a part of your catalog. Use these JPG files for your contact sheets.

In my situation, I need to print at least three different contact sheets, and would therefore be asking Lightroom to render RAW files into prints three times — a process that takes an eternity. By exporting and printing from JPGs, Lightroom instead renders from the large RAW files only a single time. When printing from those JPG files, Lightroom is able to generate prints much more quickly, saving me a great deal of time and allowing me to go home at the end of the day, rather than sitting around the studio waiting for the computer to crunch data.

New slideshow feature in TTG Pages 3.7

theturninggate — Mon, 14 Jun 2010 22:27:20 +0000

TTG Pages 3.7 is now available for download. A major addition in this version is the new slideshow feature for the Home page. Slideshows are rendered using the JQuery-based GalleryView slideshow plugin, providing you a non-Flash slideshow option for the front page that functions in desktop browsers, as well as on the iPhone and iPad. The demonstration video below shows how to use this feature.

This update also includes the option to disable the right-click menu in exported galleries. For various reasons, I’ve never liked including this feature in my galleries. Users have asked for it, however, and I’ve managed to find a method of disabling the right-click on which I’m willing to compromise: script with a minimal footprint, and no obnoxious pop-ups replacing the right-click. The new implementation is functional, elegant, minimal and unobtrusive. Hurray!

A number of smaller additions have also made the release, detailed in the changelog below.

v3.7 ( 2010-06-14 ): New Javascript slideshow option for the Home page, powered by GalleryView.; Structural changes to accommodate slideshow.; Added option to disable right-click.; Added Font-style option for Menu Settings.; Footer can now be unstuck from the bottom of the page, allowing it to float just below page content as it used to.; Support for specifying languages other than English in the tag; if your language is not included and you’d like to see it in an update, let me know!
v3.6.1 ( unreleased; rolled into v3.7 ): PHP compatibility fixes.; CSS tweaks for templating purposes.; Added new class selectors allowing the individual images on each page to be targeted using custom CSS.

Even More Tutorial Videos for TTG Highslide Gallery Pro 2.0

theturninggate — Sat, 22 May 2010 00:15:31 +0000

The Video Manual for TTG Highslide Gallery Pro 2.0 has been updated yet again with new content. The new videos cover the Output Settings control pane in its entirety, including Image Settings, Pagination, Google Analytics and more. New videos have also been posting covering the setup and use of the Client Proofing Gallery features in the Appearance control pane.

All that remains to be done at this point is to record videos detailing the configuration and use of the shopping carts. The videos currently posted apply to both TTG Highslide Gallery Pro 2.0 and the standard TTG Highslide Gallery 2.0. In fact, at this point we have a 100% complete video manual in place for the standard version of the web engine. The only options not covered at present are Pro options.

Please keep in mind that the videos are being recorded with the current development build in-progress, and show some controls and features not yet available in the public release build. These features will be coming in the next update.

New tutorial videos for TTG Highslide Gallery Pro 2.0

theturninggate — Wed, 05 May 2010 23:51:28 +0000

New tutorial videos for TTG Highslide Gallery Pro 2.0 are now available via the About & Help menu, on the Video Manual page. So far, the videos cover the Site Info control pane in its entirety, with more videos to come. The videos vary in length, but all clock in at under 10 minutes for easy digestion. They have been recorded and posted in YouTube HD for full-screen viewing; at the time of this writing the videos are still being processed, but the HD versions should be ready in a few hours, after YouTube has finished chewing on them.

The tutorial videos for the 1.x versions have been removed from the site, though they remain available on my YouTube channel.

Tutorial: Creating Extra Pages with TTG Pages

theturninggate — Sun, 28 Feb 2010 23:50:05 +0000

TTG Pages creates a Home page, About page, Contact page and Gallery Index. But what if that’s not enough? What if you need additional pages for pricing info, press statements or psychobabble?! In this tutorial, I show you how to leverage TTG Pages to create extra pages for your TTG-made website.

New Google Analytics, Custom CSS and Custom Javascript implementations in TTG Pages 3.4

theturninggate — Sun, 17 Jan 2010 23:45:03 +0000

TTG Pages 3.4 is now available. With any luck, this will be the last update to this one for a while, because I do have other projects I’d like to spend time on. This update brings several new features and revisions, a few new styling options, and some bug fixes.

One big change is the engine’s handling of Google Analytics. You no longer need to copy and paste a large chunk of Javascript to get Analytics working on your pages; just enter your Web Property ID into the Output Settings pane, as pictured. Your Web Property ID can be found in your Google Analytics overview.

Google Analytics options in TTG Pages

Because extra Javascript — such as the despised right-click disabling script — can no longer be cheated into the Google Analytics area, I’ve created the new Advanced Options control group in the Output Settings control pane. This new control group allows much more than the previous cheating allowed.

The new Advanced Options control group.

To use the script for disabling right-click, for example, you would copy the code and paste it into the Add script before field.

Another exciting feature, for those who understand its use, it the Add CSS rules in input field. Using this field, users can write their own CSS overrides. Be sure to use the !important CSS modifier to override styling commands already in the gallery. To enable new styling possibilities, I’ve also added a #wrapper div that encompasses the page elements. To see this in action, copy the following code into the Add CSS rules in field.

For Marc Labro and Frank Noort:

The complete list of changes:

v3.4 ( 2010-01-17 ): New border-bottom options for the header/identity plate.; New text-decoration options for Hyperlinks and Menu Links.; Bug fix to galleryindex.php.; Hyperlink target for the “Home” menu item can now be changed; not a feature most people will need to use, but could have some applications for advanced manipulations of your pages.; Changed handling of Google Analytics. Now requires only your Web Property ID (UA-xxxxxx-x), rather than the entire block of Javascript.; Because scripts can no longer be cheated into the Google Analytics entry field as before, I’ve added a new Advanced Options control group to the Output Settings control pane. There are three input fields: Add CSS rules in , Add script to and Add script before . CSS rules are visible in preview, while the scripts are only added when the gallery is published (exported, or previewed in browser) to prevent any possible Lightroom tantrums.; Added a new #wrapper DIV to the source code that allows for new custom styling possibilities.; Source code for Lightroom’s preview onclick events now prevented from exporting, resulting in cleaner code that IE8 should no longer bitch about.

Tutorial: File Name Conventions

theturninggate — Mon, 11 Jan 2010 20:15:04 +0000

It’s been more than a year since I published my first article on file name conventions. The problem with the blog format is that important articles are often buried in time. And the problem with time is that it often changes our perspective on things. The purpose of this article is to once more bring the topic of file naming to the foreground, as well as to revisit, redress and expand upon my recommendations for file naming.

How you name your image files is important. It is far more important for many more reasons than I think most people realize. Adhering to a convention when naming your files can help you to locate specific images, organize your images, identify ownership of your images, correlate various renditions of your images in various locations, factor into search engine optimization, assist in client proofing and image sales, and more.

And while file names tie into the use of TTG web engines in a number of ways, which shall be discussed, this is not an article only for TTG users; this is an article for all Lightroom users, and all digital photographers.

First things first; let’s take a field trip. Open a new browser window and perform a Google image search for _MG_0001.jpg and/or IMG_0001.jpg, which are common default file names produced by many makes of digital camera. There’s no telling what you’ll find. And I think this illustrates the importance of always renaming your own image files, lest you become lost in this mash of anonymous, often poor quality imagery.

Now, open your Library and search for the same. If you find even a single image still retaining its default file name from the camera, then you haven’t been doing a good enough job managing your files. I know I’m guilty. Are you?

Naturally, every photographer will follow different rules for naming their files. In the course of this article, I will outline and provide support for my own reasoning in naming files. This is the way I think is best, though opinions may vary and you are welcome to disagree. My rules attempt to take into account various factors such as computer operating systems’ file handling, file handing on the web, file name consistency in various locations, file identification, Lightroom behavior and more.

As Lightroom users, the first thing we must take into account is Lightroom’s handling of file names. This is a consideration comprising two parts. The first, is our file handling preferences; the second is exporting from the Web module and will be discussed below. In Lightroom’s Preferences, go to the File Handling tab and locate the options for “File Name Generation”. Pictured below are my recommendations for how to setup these options.

By setting our File Name Generation rules this way, we give ourselves a sort of insurance against pilot error when naming files in the future. And this leads us to our first rule of file naming:

1. Do not use spaces or special characters in your file names.

Considerations taken into account by this rule include file sorting, Lightroom’s Web export behavior and web use.

Spaces or special characters in file names can cause a number of problems in sorting, web use and more. Lightroom recognizes this, and strips file names of spaces and special characters on export from the Web module, replacing them with underscores ( _ ). Rather than relying on Lightroom to do this on export, though, we should name the files in our Library so that Lightroom will have no reason to rename them for the web. This will ensure that your image file names on the web match perfectly the image file names in your Library, making it easier to move back and forth between the two, and also ensuring that you can make the most of your web galleries.

To accomplish this, avoid spaces and special characters when naming your files; use underscores where separation is necessary. Do not use dashes, exclamation points, parentheses, slashes, etc. Example file names might look like mc20070108Identifier001.jpg or mc_20070108_Identifier_001.jpg.

If your files are named correctly, the file names of the exported web gallery images will match the file names in your Library.

With matching file names across the board, it’s easy to isolate files in your library in accordance with the feedback collected by the client proofing features in many TTG galleries. Feedback comes into your mailbox as a comma-separated list of files for each category of feedback (all selections in a list, all 5-rated images in a list, etc.).

You can copy this list of comma-separated files and paste it into Lightroom’s Text filter to isolate the specified images in your Library. The filter should be set to Text | Filename | Contains, as pictured below.

The filtered images can then be saved as a Collection for processing.

In summary, the only characters we will be using in file names are letters, numbers and underscores.

2. Begin file names with an alphabetic identifier.

Considerations taken into account by this rule include file sorting, file identification in your Library and web use.

File names should begin with an alphabetic code or keyword that identifies you as the photographer. You might use your initials or your name, but this should be something that will be consistent for all of your images. The reason this identifier should never or rarely change is that the next step in the file name will be the date (see below), which will be used to sort our images chronologically. If this front-end identifier varies from image-to-image, it will invalidate our sorting by date.

But this begs the question, then why not begin with the date? The answer is the web. In using Lightroom to export galleries, your file names will often be used in the gallery source code to fill in id or class for various page elements. It is invalid for either id or class to begin with a number or special character; they must always begin with letters, or your page will contain validation errors. As a precautionary measure, and to ensure web validation according to W3C standards, it is best to adhere to this rule.

Because your initials or name are not likely to vary, they make an excellent front-end identifier for your files. By using a photographer identifier up front, this also makes it easy to separate images from multiple photographers — if you have a second shooter on a wedding job, for example; or if you’re on location and your assistant takes a nice photo of you that you’d like to save, but not mix in with your own shots.

Having this identifier will also help your clients to identify your files amongst others when they receive or archive files from multiple photographers. Because your files all begin with your initials, they will always be grouped together in folders.

My name being Matthew Campagna, my identifier would be “mc”, and our file name in-progress is:

mc.jpg

3. Date your files in the format YYYYMMDD.

Considerations taken into account by this rule include file sorting.

One of the key concepts when naming files is to place your broadest identifiers first, and to narrow your identifiers as your move deeper into the file name. Your name will not change, making it the broadest possible identifier; the date will change and daily. But it is important to keep your images in chronological order, as capture time makes for a natural organizational structure.

In keeping with the broadest-first rule, we begin our dates with the year (YYYY), then the month (MM) and finally the date (DD). This will ensure proper chronological sort order on your computer.

For the sake of argument, however, let’s try it another way. Americans often follow the rather backwards habit of writing their dates in the order MM-DD-YYYY. A group of files named in this way would sort improperly, as in this example:

01-10-2010
01-11-2009
01-11-2010

In order for the computer to sort files in the correct order, the year must come first, followed by the month and then the day. Our file name in progress now looks like this:

mc_20100110.jpg

4. Use descriptive keywords in your file names.

Considerations taken into account by this rule include file sorting, file identification in your Library and search engine optimization on the web.

When placing your images on the web, the most important piece of information that search engines are capable of using to identify your images is the file name. It is therefore prudent to make your file names descriptive through the use of keywords. For file sorting purposes, keywords should follow the date and should appear with the broadest keyword first, narrowing in specificity with each subsequent keyword. Keywords should be separated by underscores. For example:

Italia_Firenze

In this example, “Italia” is the broadest keyword being the name of the country, while “Firenze” becomes more specific in naming the city. We might narrow further by adding additional keywords for locations within that city:

Italia_Firenze_Duomo
Italia_Firenze_Ponte_Vecchio
Italia_Firenze_Uffizi_Gallery

For the sake of argument, see what happens when this broadest-keyword-first rule is not followed:

Coloseum_Roma_Italia
Duomo_Firenze_Italia
Eiffel_Tower_Paris_France
Ponte_Vecchio_Firenze_Italia
Vatican_Roma_Italia

As you can see, our cities and countries get all mixed up due to our file system sorting by the first letters of each specific location. Here’s one final example that might work well for files from a client shoot, in the order [ Client Name ]_[ Location ]_[ Descriptor ]:

Maxim_Los_Angeles_Grace_Park
Maxim_Los_Angeles_Tricia_Helfer

Or:

Starbucks_Seattle_Exterior_Tables
Starbucks_Seattle_Exterior_Walking
Starbucks_Seattle_Interior_Chair
Starbucks_Seattle_Interior_Counter
Starbucks_Seattle_Interior_Tables

Building our in-progress file name, let’s take it back to Italy. Here’s our example thus far:

mc_20100110_Italia_Firenze.jpg

5. End it with a four-digit sequential counter.

Considerations taken into account by this rule include file sorting.

Why four digits? Say you’re shooting a wedding. You’re definitely going to shoot more than 100 images, probably going to shoot more than 999 images, but will likely not shoot more than 9,999 images unless you’re some kind of masochist. And so the four-digit counter is most often an excellent all-purpose fit. And so, our final file name might look like this:

mc_20100110_Italia_Firenze_0001.jpg

Coda

And that’s it for file names. What have we accomplished in this process?

We now have a file naming system that produces file names which …

… are identifiable by the photographer who took them.
… are identifiable and searchable by date or keyword in our library.
… will sort in proper chronological order on any computer file system.
… will remain consistent between your Lightroom Library and Lightroom-generated web galleries.
… utilize keywords to improve search engine optimization for each individual image and for our image gallery on the whole.
… are valid values for use in XHTML source code for id and class attributes.
… fully translate back into our Library when using TTG client proofing options in engines such as TTG Highslide Gallery or TTG Client Response Gallery, or returned from shopping cart services such as PayPal or Fotomoto.

In closing, it’s easy to use Lightroom’s Filename Template Editor to create a template for naming your files in this fashion. Here’s how to setup your template:

Then you will only need to enter underscore-separated keywords when renaming files; the template will take care of the rest:

For more information on using the Filename Template Editor, see the Adobe Help Center.

As usual, feedback on these methods is welcome. Everyone has their own take on file naming, so if there’s something you feel could be done better in another way, let’s hear it in the comments.

Tutorial: PHP Cart Setup

theturninggate — Tue, 05 Jan 2010 22:32:53 +0000

This tutorial provides a detailed explanation on how to setup the new transactionless shopping cart in TTG Highslide Gallery Pro 1.9.1. It also explains how to enable and utilize the cart’s debugging options.

The information below may seem daunting at first, but it’s really pretty simple. Have no fear, and I think you will find this to be a lot easier than it looks.

Before the cart can be used, it must first be configured. Because the cart runs on PHP, it cannot be setup from within Lightroom, and so it is necessary to edit the config.php file manually, before opening the gallery in Lightroom. To do this, we much open the ttg_highslidePro.lrwebengine package.

On Windows, the package behaves like a folder. Simply double-click the ttg_highslidePro.lrwebengine package in the Explorer to display its contents. On a Mac, Ctrl-click the ttg_highslidePro.lrwebengine package and select “Show Package Contents” from the menu.

Once inside, dig into the pro/cart/cart folder and open the config.php file in your favorite editor. The file is divided into three sections. These sections are well commented with instructions, which explain the appropriate use for each function and how to configure it. The first section, beginning at the top of the file, is for basic setup. To setup your cart, you will need to rewrite the values shown below in orange. Pay close attention to the comments for each function, and edit only the text shown below in orange.

Your Company');

// A unique identifier.  Customise this in order to have different carts at the same web site.
define('CART_ID', 'ttg_cart_01');

// The full price format.  Replace the '$' sign or 'USD' as needed, but leave the '[AMOUNT]' as a placeholder
define('PRICE_FORMAT', '$[AMOUNT] USD');

// An abbreviated price format.  Replace the '$' sign or add a currency (e.g. 'USD') as needed, but leave the '[AMOUNT]' as a placeholder
define('ABBREVIATED_PRICE_FORMAT', '$[AMOUNT]');

// Extra fields added to the Checkout page.  Remove or add as necessary.  The 'title' is the field name that appears on the form.  Set required to 'yes' or 'no' to control mandatory fields.  The 'errormessage' is displayed when a mandatory field has been left empty.
// An optional field, 'inputname', can be supplied to override the parameter name (which by default is based on the title).  This is to resolve issues such as punctuation preventing the form from functioning correctly. 

$ADDITIONAL_CHECKOUT_FIELDS = array(
		array('title' => 'Address', 'required' => 'no'),
		array('title' => 'Contact number', 'required' => 'yes', 'errormessage' => 'Contact number is required'),
		array('title' => 'Additional requests', 'required' => 'no', 'inputname' => 'additionalrequest')
	);

// The email address that you wish to receive orders at
define('SITE_EMAIL', 'you@yourcompany.com');

// The subject line in emails received by your customers.  [ORDER_NUMBER] is automatically replaced with the order number.
define('CUSTOMER_EMAIL_SUBJECT', 'Confirmation of order [[ORDER_NUMBER]]');

// The subject line in emails received by yourself.  [ORDER_NUMBER] is automatically replaced with the order number.
define('VENDOR_EMAIL_SUBJECT', 'A new order has been received [[ORDER_NUMBER]]');

// The sender's name for emails sent to your customers.  Replace this with your actual name or company name.
define('VENDOR_EMAIL_NAME', 'Your Company');

// The sender's email for emails sent to your customers.  Replace this with your actual email address.
define('VENDOR_EMAIL_EMAIL', 'you@yourcompany.com');

// The top text in the customer's order confirmation email.  [ORDER_NUMBER] is automatically replaced with the order number.
define('ORDER_EMAIL_INTRO', 'Thank you for placing an order with us.  We will contact you within 7 working days to arrange payment and delivery.  Should you wish to change your order kindly reply to this email quoting order number [ORDER_NUMBER].');

// Additional text in the customer's order confirmation email, placed immediately before the signature (if any).  [ORDER_NUMBER] is automatically replaced with the order number.
define('ORDER_EMAIL_OUTRO', 'text');

// The sender's email for emails sent to your customers.  Replace this with your details or leave as blank, i.e. '';
define('ORDER_EMAIL_SIGNATURE', 'Your Company http://www.yourcompany.com');

// The full directory path to save orders.  It is strongly advised to set this to a folder on your system in order to catch orders that you fail to receive via email.  This directory should be outside of your web folder, i.e. not underneath public_html, www or similar directories.  It should only be accessible via yourself using FTP.
// Discover your server path using the URL http://www.yourcompany.com/cart/?showpath to show the full server path to your cart; edit as needed to hit the right location for saving orders.
define('ORDER_SAVE_PATH', '/home/you/www/etc/');

/*

The second section of the config.php is for language localization. By default, the cart is setup using the English language. Should you wish to localize the cart in your own language, you may do so by translating the strings in this section. Again, change only those strings shown in orange below.

COPY CHANGES.  Change these to localise to your own language

*/

// The shopping cart
define('TEXT_ITEM', 'Item');
define('TEXT_ITEM_NAME', 'Item Name');
define('TEXT_ITEM_ID', 'Item ID - ');
define('TEXT_OPTIONS', 'Options');
define('TEXT_UNIT_PRICE', 'Unit Price');
define('TEXT_QUANTITY', 'Quanity');
define('TEXT_REMOVE', 'Remove');
define('TEXT_AMOUNT', 'Amount');
define('TEXT_TOTAL', 'Total');
define('BUTTON_UPDATE_CART', 'Update Cart');
define('BUTTON_CONTINUE_BROWSING', 'Continue Browsing');
define('BUTTON_PROCEED_TO_CHECKOUT', 'Proceed to Checkout');

// Checkout field names. Changes to the additional fields need to be made for the titles in ADDITIONAL_CHECKOUT_FIELDS above
define('TEXT_NAME', 'Name');
define('TEXT_EMAIL', 'Email');

// Checkout messages.
define('TEXT_NAME_REQUIRED', 'Your name is required');
define('TEXT_EMAIL_REQUIRED', 'Your email address is required');
define('TEXT_EMAIL_INVALID', 'Email address is invalid');
define('TEXT_DENOTES_REQUIRED_FIELD', 'denotes required field');
define('TEXT_YOUR_CART_IS_EMPTY', 'Your cart is empty');

// Checkout buttons
define('BUTTON_COMPLETE_YOUR_ORDER', 'Complete your Order');
define('BUTTON_CHANGE_YOUR_ORDER', 'Change your Order');

// Order email copy
define('TEXT_CUSTOMER_NAME', 'Customer name');
define('TEXT_CUSTOMER_EMAIL', 'Customer email');
define('TEXT_TOTAL_ORDER_PRICE', 'Total Order Price');
define('TEXT_ITEMS_IN_THIS_ORDER', 'Items in this order');
define('TEXT_ORDER_DETAILS', 'Order Details');

With the above sections completed, you should be ready to publish shopping cart galleries from Lightroom. If you are experiencing problems running the cart on your website, however, the debugging options below may be useful to you.

The third section of the config.php file includes some debugging and test options. In most cases, you will not need to change these lines. However, we may ask you to enable these debugging functions when requesting tech support. In such cases, you do not need to edit these lines within the ttg_highslidePro.lrwebengine package; it will be sufficient to make these changes in an exported gallery located on your web server, where we can debug a live shopping cart.

To enable the options, the lines must simply be un-commented by deleting the ‘//’ preceding each line, shown below in red.

// Uncomment the below line for demo mode.  Both the 'thank-you' and 'new order' emails will be sent to the customer's email address as entered in the checkout form.
//define('MODE', 'demo');   

// Uncomment the below line for to allow viewing of phpinfo at the URL http://www.yourcompany.com/cart/?info for debugging purposes
//define('ALLOW_VIEWING_PHP_INFO', 'yes');   

?>

There are also some debugging options in the index.php file that we may ask you to enable when requesting tech support. These options enable error reporting. To enable error reporting, un-comment the lines below by deleting the ‘//’ shown in red.

// remove the starting '//' from the two 'ini_set' lines below to force errors to print on-screen
//ini_set('error_reporting', E_ALL);
//ini_set('display_errors', 'On');

If you are having trouble running the cart on your web server, it is often helpful to enable error reporting, then to send the resultant errors to your website’s host company by opening a support ticket.

In closing, we do recommend that you use the cart on servers running the most up-to-date versions of PHP, as this will help to reduce the likelihood that you will encounter problems.

To see a demonstration of the shopping cart in action, check this out.