LightSpeed Webstore: a way to have product images larger than 512×512

Let’s face it, as a web designer it’s not fun to have to tell a client that they can’t have something and if they’re using LightSpeed Web Store for their eCommerce solution ( developed by that venerable company, LightSpeed) they can’t have all the bells and whistles for their product images.

On the client’s side, the LightSpeed POS looks so flashy and so well, capable that they’re often flummoxed when they’re told they can’t have product images larger than 512 pixels, width/height. Make sure right off the bat you pony up that wobbler: 512 x 512 is the max photo size. But keep it a secret if you like explaining big caveats seconds before the launch.

“What’s all this fuss about. I sell products that sell themselves. My customers couldn’t care less about photos.” Really? What kind of products don’t even need a photo? The product photo is the only way to show customers… Wait, you do know we are talking about online stores, right?

“What’s all this fuss about. I only use the POS and couldn’t give less of a hoot.” Why are you talking to me, then?

“What’s all this fuss about. 512 x 512 is plenty big. In fact, if the photos were any larger customers would be able to see how bad my photographs are. Couldn’t have that. Might have to actually pay an actual photographer one day but for now my smartphone’s camera and I do the job. And it’s free.”

Do not get me started on cutting corners with product photography. Besides, just because other webstore owners could have larger images wouldn’t mean you’d have to also have larger images.You could keep uploading little photos.

All joking aside, while it’s not that important to brick & mortar retailers ( for obvious reasons I really hope), it’s very important, if not vital for online resellers to have larger product images. If I shop online I won’t buy an apparel product unless I can see a larger image of it. This goes for shoes, handbags, hats and jewelry. I suspect if covers furniture, art and table-top as well as bath appointments and fixtures and what ever else kinds of products where you have to be able to see the product enlarged in order to feel confident enough about it in order to add it to your cart.

What we can do with the template, right now, out of the box:
If we have the real estate and the desired look allows for it we can enlarge the product detail images area to accomodate a full size 512 x 512 image. But most of the time we don’t have that much space to work with.

But say we can squeeze the full-size in, then what?
If we’re restricted to just 512 w/h, we can’t use a zoom tool because we’d be zooming a 512 image and what we’d get is ugly not to mention useless because you’re supposed to zoom to a larger image than what is already visible not show the exact same image size in a lightbox window.

The “solution” that’s most widely used is to make the main image display at a smaller width/height so that the lightbox window actually shows a larger image… with well-shot additional images that close up on important details, it can work.

But if you can use it WordPress can fill in where LightSpeed leaves off.

First of all, I’m not suggesting you should install WordPress if all you’re going to be using it for is to have larger images. But WordPress makes it so damn easy to upload images, create posts and insert images in these posts and get the webstore template to show the posts in a lightbox/fancybox window that it wouldn’t be so nuts if you did install WordPress just for Larger Product Images. Not everyone uses an FTP client. At least,my clients certainly don’t. So if you go for “ease of use” over how much it’s going to be used I don’t think anyone would blame you. That much.

I registered a custom post type named Larger Product Images in my theme’s functions.php.
When I made my larger image posts I used a Featured Image and I inserted 2 to 3 inline images into the post editor.
As far as creating the single template went, the images inserted into the editor were the_content();.
The Featured Image, the_post_thumbnail(‘larger-image’); was declared in functions.php with add_image_size( ‘larger-image’, 600, 600 );.

I added a new template file to my theme called single-{name-of-post-type}.php. Since I wasn’t really concerned with the way the permalinks looked and I wanted a really, really unique post type name, I’d named my post type “lgr-imgs-gal” which meant my single template was named single-lgr-imgs-gal.php. Again you don’t have to be that precious about setting up the post type. You could do something as slight as this (in functions.php of your WordPress theme):

// register custom post type

function register_custom_post_types() {	
	// register custom post type
	$labels = array(
		'name' => 'Product Larger Image Galleries',
		'singular_name' => 'Product Larger Image Gallery'

	$args = array(
		'labels' => $labels,
		'public' => true,
		'capability_type' => 'post',
		'exclude_from_search' => true, 		
		'supports' => array('title','editor','thumbnail','custom-fields'),

register_post_type('lgr-imgs-gal', $args);

add_action('init', 'register_custom_post_types');

This post type doesn’t need an archive and the URLs don’t have to make any sense human-readable-wise. All it’s doing is showing larger images in the webstore. Also, the theme never has to call the file in the WordPress part of the site, meaning you aren’t going to be showing the larger image galleries in a custom page or anything like that. As far as visitors looking through your site are concerned this post type doesn’t exist except to show larger images in the webstore via a “simple” link (placed somewhere logical in product_details.php).

The “simple” link:

<a class="fooey view" href="<?= strtolower(preg_replace('/[^A-Za-z0-9-]/', '',$this->prod->Name));?>/"><?php _xt("Larger Images");?></a>

Most of the URL is hard coded because it can be. The part that can’t be hardcoded is the name of the product so we have to use code to get that. Luckily that’s included in the template file for us. The new code will take all the spaces and make the product name all lowercase. This should make linking to the single galleries by name easier.

To create the titles of the posts all you have to do is hover over the link that the code above creates. Go to your webstore, click through to a single product and hover over the link text – you’ll see what the revised name of the product is. Use the revised name as the Title of the larger image gallery Post.

You can even copy the link and paste it into the Title area of the Post Editor and delete everything up to the actual name if you’re still not sure what it is.

If you want to be more careful about things ( say you have 2 products with the same name for some reason but they have different product codes) you could put the product code in the URL and use that as the post title.
Just replace $this->prod->Name with $this->prod->Code. We went with names because it seemed easier to understand. If your product codes are strictly numerical you don’t even need the part of the code that removes the spaces and makes it all lowercase ( since all lowercase only applies to alphabetical characters). In that case you could probably get by with just this:

<a class="fooey view" href="<?= $this->prod->Code));?>/"><?php _xt("Larger Images");?></a>

Where your webstore is installed, locate assets/js/webstore.js.
If you haven’t edited this file you should be able to locate lines 42 to 46:


Right after:


Paste this:

'width': '100%',
'height': '100%',
'type': 'ajax',
'ajax': {   
dataFilter: function(data) {
return $(data).find('#largesse')[0];


$("#thumbs a").live('click', function(evt) { 



 $("<img>", { 
 src: this.href 

All the above does is make the link load the single galleries in a lightbox-ish window using fancybox which is a jquery plugin that is loaded with webstore by default. *Meaning I didn’t add it, they did so it’s approved to be used in webstore.

*About that little comment:
Whenever possible I try to avoid adding new stuff to webstore because every so often my clients have an issue with the Point of Sale & webstore and the 1st thing they hear is “well, your template is custom, must be a problem with the code in it”. Sometimes this is true. But since I’ve gotten very very very careful when making custom webstores it’s not as true as it used to be :).

In fact you should never mention your webstore is custom when contacting support. Not to be mendacious ( anyway they’re going to look at your store in a browser and see it’s customized) but to stop the support thread from stopping at “well, it’s customized”. If you EVER contact support about something in the webstore not working be sure to tell them that you recreated the issue you’re having with a completely clean webstore. That means the template was switched FROM the Custom template To Deluxe, Basic or Framework and each of these templates are 100% unedited and virgin. It also means removing any other edits you made to any other file anywhere else. And for the sake of everybody’s sanity please actually do this, don’t just say you did it! That’s not fair to support and you won’t get to the bottom of the issue (probably). The whole point of this advice is to make sure they talk to you about the actual issue not about the fact that you webstore isn’t using Deluxe, Basic or Framework.

What about single-lgr-imgs-gal.php?
Won’t the lightbox window load a complete page when we only need to get the galleries not the whole page?
Here is the template:

<!DOCTYPE html>
<html <?php language_attributes(); ?>>
<meta charset="<?php bloginfo( 'charset' ); ?>" />
<meta name="viewport" content="width=device-width; initial-scale=1.0">
	global $page, $paged;
	wp_title( '|', true, 'right' );			


<link rel="stylesheet" type="text/css" href="<?php bloginfo( 'stylesheet_directory' ); ?>/larger-image.css" />

<body class="single-lgr-imgs-gal">

<?php if ( have_posts() ) while ( have_posts() ) : the_post(); ?>
<div id="post-<?php the_ID(); ?>" <?php post_class(); ?>>									

<div id="largesse" class="larger-images-entry larger-images">
 <div id="thumbs"><?php the_content(); ?></div>					
  <div id="main-image"><?php the_post_thumbnail('larger-image');?>
</div><!-- .entry-content -->

<div class="entry-utility">					
<?php edit_post_link( __( 'Edit', 'coclico' ), '<span class="edit-link">', '</span>' ); ?>					
</div><!-- .entry-utility -->					
</div><!-- #post-## -->					

<?php endwhile; // end of the loop. ?>

<script type="text/javascript" src=""></script>
<script type="text/javascript"> 
 jQuery(document).ready(function($) {
     $("#thumbs a").live('click', function(evt) {
     $("<img>", { src: this.href}));




The code in webstore.js is only going to load div#largesse in the fancybox window.

Everything else such as normal document structure,css and javascript (to make the thumbnails in the gallery load into div#main-image stage) is so that the galleries – if they get loaded outside the fancybox – will work and look nice.
You’ll still have to add the css for the galleries into webstore/yourtemplate/css/webstore.css.

Anyway I hope this helps someone out. I beat my brains out doing it but I’m glad I did it because it works really well.

One last thing: make sure to use OR, not both. So go to WordPress > dashboard > Settings > General and check the wordpress address and the site address. They should be either OR It seems to make a difference with how fast the larger images galleries load with fancybox. I could be out of my mind. But I tried it out and I definitely saw some serious slow loading or never loading when I was in and was trying to load a gallery located with just If you switch to www. in Settings > General you’ll get logged out. But you’ll be able to log back in with the same password and username, don’t worry.

Theme Authors Beware: WordPress 3.2 needs MYSQL 5 and PHP 5.2.4

Like WordPress states on their WordPress 3.2 pre-release page client’s hosts need to be using MySQL 5 and at least PHP 5.2.4. There’s a plugin called Health Check that will let you know either way. I’d hurry and install this plugin because if the environment is not OK you’re going to have to login to the client’s cpanel and see if you can upgrade both or if you have to contact their host and ask them to make this an option.

The other big change is that WP 3.2 uses jQuery 1.6.1. You may be using jQuery plugins or random JavaScript functions that will not work with 1.6.1. I beat my brains out for a while before I realized that something I had written or included was the reason my custom slideshow wasn’t loading. I knew it was a Javascript error because an alert popped up instead of the slideshow and all it said was undefined. So now I have to track down what is not compatible or undefined. Yay! But I needed the site to work right now so I replaced WP’s jQuery 1.6.1 with jQuery 1.4.4 to buy some time until I can find out what is not right with my scripts. But I’m not betting much on fixing the scripts and will probably just phase out using them in new projects… too bad because some of them worked really well.

Oh I forgot to say whether replacing WordPress jQuery 1.6.1 with jQuery 1.4.4 causes anything to break. I’ve tested the Widgets and Menus manager and everything works as expected.

Using WP 3.1, jQuery, Cforms & WP-E-Commerce? Frustrated by Javascript Errors?

The main error I’ve seen when using these 2 plugins and using WordPress’ jQuery is “jquery form.product_form .livequery is not a function” which makes it look like the wp-e-commerce plugin is at fault but it actually isn’t. I know it isn’t because I de activated all my plugins and re activated them one by one until the error came back. With my specific set up the error only came back when I had cforms and wp-e-commerce activated at the same time.

You’ve learned how to enqueue jQuery plugins with WordPress’ jQuery without errors.WP-E-Commerce relies on WordPress’ jQuery. CformsII uses jQuery 1.4.2. WordPress uses jQuery 1.4.4. So now you’ve got 2 versions of jQuery being loaded at the same time which we all know means Javascript errors.

The easiest thing to do is FTP into your server, go to wp-content/plugins/cforms/js, open jquery.js and paste in a copy of jQuery 1.4.4. Doing this will not disrupt cformsII on the backend or submitting forms on the frontend.

If you upgrade cforms you’ll have to do this all over again. But since you’re not editing lines of code this is a snap to repeat.

* Note: Just because FireFox Web Developer or Firebug are reporting JS errors doesn’t necessarily mean things are not working as they should be. But you should remember that Internet Explorer is going show a nasty message: “error on page” or “done, but with errors on page” that your clients and their customers will see. But if you fix it before they see it it can be one less thing you’ll have to hear about.

This advice can be used with other combinations of plugins. If any plugin is enqueuing its own copy of jQuery that is not 1.4.4 and you’ve already enqueued WordPress’ jQuery you can just empty the plugin’s jquery.js so that its enqueuing an empty file or paste in 1.4.4. You’ll have to make sure doing this doesn’t stop the plugin from functioning, I’ve only tested this “fix” with cformsII.

In any event as long as everyone is using the same version of jQuery there won’t be any errors.

How are you dealing with Javascript errors?

Another Featured Content Slider Tutorial

All of my latest projects have involved putting a featured content slider of some kind on the home page. Everybody wants one. There are plenty of plugins both Jquery and WordPress (and Joomla and Drupal) that will build a slideshow for your images. You get a little less to choose from if the content being “slidered” is text and images.
And if using WordPress, you want to be able to use posts, featured images and the_ excerpt or the_content, right?

I’m using loopedSlider by Nathan Searles which has very recently been renamed Slides. I choose this plugin because it lets you choose from several different kinds of of transition effect for the sliding animation, has paging and can handle divs. In short it is highly flexible and extremely simple to use. Thank you, Nathan Searles for creating it and offering to the public.

If it’s so easy why do I need to write a tutorial? Because it got a little complicated when it came to using this plugin for WordPress posts. Here is a code example of a featured content gallery or slider that grabs 6 Posts according to a Tag. The amount of Posts is optional as is the Tag. The example code is not using the Loop and is safe to use in a theme file that is using the Loop – not in the Loop itself – that goes with out saying, I hope.

<div id="featured-slider" class="bigbox">  
<div id="slideshow">       
 <?php global $post;
   $tmp_post = $post;
   $myposts = get_posts('tag=featured&posts_per_page=6');
 	foreach($myposts as $post) :
     setup_postdata($post); ?>
<div id="post-<?php the_ID(); ?>" <?php post_class(); ?>>    
   <span class="slideimage">      
      <?php the_post_thumbnail('big-slider');?>      
      <span class="slidetext">       
      <h2><?php the_title();?></h2>       
      <span class="excerpt"> <?php the_excerpt();?></span>

  <?php endforeach; wp_reset_query();?>

    <div class="bottom-slider-content">
      <div id="slidernav"></div>
</div><!--/.bigbox #featured-slider-->

Purists will not like the use of heading tags inside span tags but I found it somewhat easier to use span tags so that the slider knew when to stop sliding things.

Of course you have to download the slider JavaScript from the Slides Web site. Of course you have to be using Jquery in your theme. On the Slides Web site you will find many option examples and implementation codes. Here is how I configured mine. Note: I built this slideshow using loopedSlider so it might be helpful to visit that page as well for examples.

		.after('<div id="slidernav">')
			fx: 'scrollDown', 
// choose your transition type, ex: fade, scrollUp,scrollLeft,scrollRight, shuffle, etc...
			speed:    1500, 
// defines the number of milliseconds it will take to transition from one slide to the next.
			timeout:  9000, 
// specifies how many milliseconds will elapse between the start of each transition
			pause: 1, 
// so that pauses when user hovers over a slide
			delay:  9000, 
// set a delay before 1st slide starts transitioning
			pager: '#slidernav' 
//instructs the plugin to create navigation elements,
 one for each slide, and add them to the container
 identified by the value of the pager option.

Using the Featured Image in the Content Slider

If you look at the content slider code carefully you’ll notice I am using a Featured Image size named big-slider. I added this to my theme functions.php in order to be able to use a specific image size in the slider. Very useful for a consistent look.

Please backup functions.php before editing it!

add_theme_support( 'post-thumbnails' );       
    add_image_size( 'big-slider', 600, 315, true ); 

If your functions.php already has the add_theme_support code don’t add it in again. Also, you can choose whatever size you want.
The first number is the image width, second is the height. You’re supposed to be able to have an open size , example: add_image_size( ‘big-slider’, 600, 999, true );

But I have had difficulty with this.

And then of course you can skip this and just put an array for the featured image directly into the slider query code,
example: the_post_thumbnail(array(600,315) );
instead of the_post_thumbnail(‘big-slider’);.

If you choose to do this you don’t need to add an image size to your functions.php but you should still take a look to see if your theme supports them. I know this is said over and over again but the image size you choose either in the query or the functions.php code does not work on already uploaded images.

In order to have the size you set kick in you must re upload the image and then choose it to be the featured image.

Download the example Featured Slider Example (1798)

For CSS (styling) and Javascript please visit Slides or loopedSlider.