Posted by Dustin on July 2, 2008 under Web Development, Websphere Commerce | 
So we recently started rebuilding our ProForm site (and by rebuilding I mean from the ground up…mostly), and lucky me I was placed on import duty. Well being the freakin’ genius that I am I realized that .csv files for WorkoutWarehouse would likely work on Proform since we generally don’t change them on the 6.0 stores (we tend to like to try to pretend we keep things standardized). So I grabbed me some WW goodness and commenced importing. I only had about 12 .csv files on me but it was enough to get a few products to test and build with.
Not long after the imports we noticed we couldn’t add products to the shopping cart, we kept getting some bizzarre error saying that it couldn’t resolve the product ID from the SKU.
MENTAL NOTE: when getting the aforementioned error check the “defining attributes”
I’d seen this error before on NordicTrack and I knew it has something to do with, you guessed it, the sku. However I was too involved in my own little world to do anything about it so Phil dug in and found that somehow our descriptive attributes from the .csv were placed in the wrong attributes section…instead they were placed as “defining attributes” which is bad because we all know that each defining attribute is a SKU. Once we deleted all defining attributes the products worked fine, however we were still stuck with the problem of what to do about the lousy imports that we would get should we try anymore .CSV’s.
Turns out the answer is quite simple…there is a certain DTD (wcs.dtd) that needs to be defined to do what you want it to do and in our case on ProForm it was not defined so well. the trick here is to steal one you know works for the site you are on. Which brings me to the whole point of this post, all I really wanted to do was plaster this path somewhere else so when I run into this agian I have a better chance of stumbling onto a solution before it’s too late. Sure I could go on about how to properly write a DTD and make it do what you want, but that would cut into my Reaper time?
the path you’ve all been waiting for, the path that contains all DTD’s from WorkoutWarehouse to Proform and everything in Europe is:
\\wcdev\QIBM\UserData\WebSphere\AppServer\V6\ND\profiles\wcdev6\nulltemp\catalogimport
Posted by Phil on June 17, 2008 under Javascript, Web Development |
One of the greatest jQuery plug-ins that I have stumbled on has been the pngFix plugin. This fantastic piece of code takes your png images and applies the AlphaImageFilter logic to make ie6 actually display them with the correct transparency (not that nasty gray-ish stuff) When I found it, I was ecstatic, when I first tried it I was overjoyed! Then I tried to develop with it.
While this may be uncommon for most users, it has a severe bug. In fact the bug was mentioned on the creator’s blog in the comments by one unfortunate user (Dj) who ran into the same thing I did. The problem arises when you use a png as a clickable object, or even as a background where your clickable object is going to be. As near as I can tell, when the pngFix executes, it grabs all the png files on the page and runs then through the image filter and then slams them back down on the page. On top of all of your links… on top of everything. I tried changing the z-index of my links, I tried changing the png image from a background to an img-tag. Nothing worked. I had almost given up hope (as there was no answer posted on the blog) when I found another site that mentioned the problem. Someone in there (Elbert Oh) had commented that they had found a possible solution and pointed users towards this site for examples.
By using the example site, I ended up with a working solution (this will be deployed in the new ProForm site)
Here is an example of the solution (with the correct code in place)
Here is the header image that will link back to the homepage
<div id="logo"><a href="http://www.proform.com"><span>ProForm.com</span></a></div> |
Seems simple enough right? Here’s the css that I used.
#logo {
margin-left: 531px;
height: 90px;
background: url('images/logo.png') no-repeat scroll 0px 3px;
}
#logo a {
display: block;
width: 459px;
height: 90px;
position: relative;
z-index: 1;
}
#logo a span {
display: none;
} |
What you should be able to see here is that I set the logo appear on the right side of the page (hence the fatty margin-left). Then I set the height of the object, and finally pointed it to the png image that I’m using as a background (that without the fix would be picked up, filtered, and then slammed back down on top of my clickable area).
I made the link take up the entire image area by making the display a block and setting the width and height to the same dimensions as the image. Then there’s the real magic of making this work. setting the position to relative, and then setting the z-index to 1. ((POSSIBLE BS ALERT)) Somehow the positioning gets tweaked when the transparency filter is applied and that is part of the reason for the links becoming unclickable. By setting the position to relative, and then setting the z-index to 1, it forces the image to stay where it is and leaves the links clickable. That may not be what is actually happening, but I think that’s what’s going on…
Anyway with those small changes, the site* is now working with clickable links and png images in ie6, ie7, Firefox 2, Firefox 3, Safari 3.1, and Opera 9.5 .
*The development site on my local server, not the actual ProForm.com as we have not launched the new site yet 
Posted by Dustin on June 2, 2008 under Web Development |
FYI, if you get a tasks asking you to change the price of a product on proform and said product has a duplicate (or _SUB product) DO NOT change the price of the _SUB product unless asked to, or asked to change the price of the ‘Beneplace’ product.
I suppose some will need a reason for this. It’s simply because the _SUB products are used for a hidden category that can only be reached by direct link. If you change the price of the _SUB product you will likely eliminate the special deals we give to those customers.
