How to get the customer’s LightSpeed Webstore minicart to show in WordPress Theme

For ages I’ve known how to get WordPress stuff to show up in my Webstores. But getting Webstore stuff to show up in my WordPress themes seemed to be beyond me.
I’d tried and tried and given up many times. So today when working on a client project I don’t know what made me try again. I just felt like I knew more now than I did and this time I might be able to do it. And I did it. Amazing.

Enough with the chitter chatter here is how I did it.

Went to (where webstore is installed), opened index.php and found this: require_once(‘includes/prepend.inc.php’);.

Then I made a copy of my_webstore_location/templates/my_template/minicart.tpl.php.

And in my WordPress theme I created a new file called “webstore-minicart.php”.

In webstore-minicart.php I pasted the contents of minicart.tpl.php.

And webstore-minicart.php, after the first < ?php, I pasted require_once('/path/to/webstore_location/includes/prepend.inc.php'); The path to file prepend.inc.php is very important. It has to be 100% correct or you'll get a nasty error or just a white page. You don't want that. If you don't know the server path to your webstore location ( where your webstore files are) here's the easiest way to find it out: create a file named info.php in the same directory where your shop is installed. If it's in /shop place info.php in /shop. In info.php paste: [php] <?php phpinfo();?>[/php] Then load the file in your browser by going to www.your-domain.com/shop/info.php Find PHP Variables and locate _SERVER["SCRIPT_FILENAME"] everything before the actual name of the file is the server path to the file. On one server the path to the file could be /home/user/username/htdocs - just for example. On another server it could be /blah/blahbla/public_html. In any case if you load info.php you ought to be able to find it out. Note: PHP errors will include the path so if you get the path wrong pay attention to any errors that occur. Whew. So now that we know where the file is and how to tell PHP where to find it we can display the minicart in our WordPress theme! [php] <?php get_template_part('webstore-minicart');?> [/php] Unfortunately, I have had to be secretive when it comes to customizing LightSpeed Webstore because there are very large multiple person team companies that do the same work as I do and charge a lot more than I do and get more customers than I do but never ever share their code! So I'm not going to post webstore-minicart.php for you on this site but if you contact me and ask me for it I will send it to you.

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="http://www.your-domain.com/your-wordpress-location/lgr-imgs-gal/<?= 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="http://www.your-domain.com/your-wordpress-location/lgr-imgs-gal/<?= $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:

$(document).ready(function()
{
	$("#xlsSearch").bind('keyup',autosuggest);	
	$("a.iframe").fancybox();	
});

Right after:

$("a.iframe").fancybox();

Paste this:

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

  });

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

     evt.preventDefault(); 

$("#main-image").empty().append(

 $("<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(); ?>>
<head>
<meta charset="<?php bloginfo( 'charset' ); ?>" />
<meta name="viewport" content="width=device-width; initial-scale=1.0">
<title><?php
	
	global $page, $paged;
	wp_title( '|', true, 'right' );			

?></title>

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

<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>  
</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="http://ajax.googleapis.com/ajax/libs/jquery/1.7.2/jquery.js"></script>
<script type="text/javascript"> 
 jQuery(document).ready(function($) {
     $("#thumbs a").live('click', function(evt) {
     evt.preventDefault(); 
     $("#main-image").empty().append(
     $("<img>", { src: this.href}));
   
     }); 

  });     
    

 
</script>		

</body>
</html>

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 http://mydomain.com OR http://www.mydomain.com, not both. So go to WordPress > dashboard > Settings > General and check the wordpress address and the site address. They should be either http://mydomain.com/ OR http://www.mydomain.com. 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 www.mydomain.com. and was trying to load a gallery located with just http://mydomain.com. 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.

Embed Audio files for music product in LightSpeed web store

Out of the box, LightSpeed web store is not as robust as some other eCommerce solutions. But that doesn’t mean there aren’t ways to make it more robust. One such example: creating a solution to hear music samples in a Single Product detail page on the web store. We didn’t want to just click over to an external site (like the vendor’s wholesale page which had provided the samples). In my solution the customer does not leave the page to hear them.

I created a custom post type in WordPress for each CD/album title being sold on the web store. Each post has its own music player loaded with a playlist (of song previews). The .mp3 samples were uploaded with the Media Uploader and a music player WordPress plugin called Haiku was activated to play the samples. Then the links to the single custom posts were embedded in the appropriate LightSpeed Product Cards and then web store was updated.

When the link in the product description is clicked, the custom post loads and plays the samples in a lightbox window (using Fancybox which ships with web store), so the customer never has to leave the product details page to listen before they buy. All you have to do is embed the link to the custom post type in the product description and voilĂ .

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?