Update!

I just wrote this post about getting the minicart from Webstore to show (with cart content intact). Now I’m thinking, using similar methods, what other features of Webstore can I bring into a WordPress theme? For instance, to get the Webstore menu – can I just copy menu.tpl.php into a WordPress theme file named menu.php and then call it with get_template_part(‘menu’);? Would surely be a lot easier than how I currently do it using code I wrote relying on Simple HTML Dom to get the menu! And I wouldn’t get chastised by snotty programmers about SHD using file_get_contents! Ha.

Anyway, I’ll let you know how it goes. But to me, this is very exciting. No doubt if the experiments work out super fast & easy Webstore & WordPress customizations will be possible for practically every project.

Update For the Update:

Sooo, experimenting didn’t go very far. Seems requiring prepend.inc.php is able to get the cart
– probably because at the top of minicart.tpl.php there’s this neat code:
[php] $cart = Cart::get_cart();
$items = $cart->GetCartItemArray(); [/php]

but if you need more you’d have to require webstore index.php. Because it loads the functions for the category menu. I think. Experimenting doing just that however led to an error that read: Template file is missing. Because of course webstore’s index.php was trying to find various template files (like index.tpl.php) in WordPress which I’ve got installed in the root. Webstore is installed in /shop. When I have more time to fool around with this I’ll have time to move WordPress into a sub-directory of the webstore location – like /shop/wordpress… The good news about all of this is that it seems as if the outlook is good. I couldn’t successfully get the webstore menu to show up in my WordPress theme by using get_template_part(‘webstore-menu’); which of course was just a copy of menu.tpl.php…
But I also didn’t run into any PHP errors. Makes me think that if everything is in the right order and place t might work out. One day. I’ll beat this one day!
Happy coding.

Legacy Code Notice

Don’t use:
[php] $cart = Cart::get_cart();
[/php]

Do use:
[php] $cart = Cart::GetCart();
[/php]

get_cart(); can get the cart but it will fill your error logs with statements about using legacy code.

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):

[php]// 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’);
[/php]

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:
[php]<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>[/php]

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:

[php]<a class="fooey view" href="http://www.your-domain.com/your-wordpress-location/lgr-imgs-gal/<?= $this->prod->Code));?>/"><?php _xt("Larger Images");?></a>[/php]

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:

[php]$(document).ready(function()
{
$("#xlsSearch").bind(‘keyup’,autosuggest);
$("a.iframe").fancybox();
});
[/php]

Right after:

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

Paste this:

[php]$(‘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
}
));
});
[/php]

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:

[php]<!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>
[/php]
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.

Your Spelling Mistakes Keep Me Up At Night

The work I do depends on spelling words correctly. The work I do depends on naming things consistently.

I can name an element “fragglerock” not very semantic but we have to remain entertained. We have to keep our spirits up.

If I write code that needs to be able to find “fragglerock” but I’ve gone and created object “fraggelrock” – the code looking for fragglerock will die.

If I write out an element name in the HTML outline and then try to style it in the stylesheet but I misspelled the name in one of the locations nothing will happen. Nothing happening is a harmless result. Nothing happening is a lot better than things breaking or not working. I’ll take nothing happening over breaking any day. Plus since I’m the one in control of both the HTML outline and the stylesheet I can find my spelling mistake and correct it. And then things will happen. Good things.

If I spell something one way and base code around that particular spelling and then you spell it another way, the code won’t get to do its job. Poor little code.

Any coder knows this stuff, by the way. I think we might come off as crotchety, old schoolmarms to “normal” people because we harp on endlessly about consistency. It’s because we need and require and apply consistent spelling or naming of things in order to do our work and to have our work, work.

If we hand off a site to someone and ( God forbid) some of its features require consistent spelling when the site is updated, we will probably get an email in a few weeks (or days) saying the site is not working.

Consistency when naming things and correct spelling when typing those names of the things, will result in those things always being named and spelled the same way. That is not only a statement of the obvious it’s also a redundant statement.

If I require a normal person to be consistent about naming things to the point of acquiring an OCD I can expect the work to fail. Recent case: the chosen eCommerce solution didn’t provide large enough product images. I decided to use the name of the product to create a url that linked to a gallery of larger images which I devised via the implementation of another thing you might have heard of: WordPress. In their local application they can type the product name any way they want but they have to type it the same way in the WordPress side. This worries me in particular… The code “reads” the product name in the template for the eCommerce solution and the code I wrote creates URLs out of these names but the viability of the URLs depends on the galleries being named (and spelled) the same as the product name. If this system fails new image galleries won’t load in the eCommerce template.

Fragglerock or Fraggelrock, but never both.