Welcome to our community support forums! We're here to help - but if you have an urgent request for a Pro Plugin, you will get a prioritised response through our Premium Support page.
December 5, 2011 at 3:42 am #8840jlaryszParticipant
This issue is probably ignorance on my part, but my web site is slow after importing lots of products using the importer. The site doesn’t seem to be using all the size-specific thumbnails that the importer generates.
The importer generates 4 thumbnails in my case for each product uploaded. For example, the product image file Thumbnail-DSC_6875.jpg will end up with these thumbnails:
with the actual image size burned into the filename.
However, if I bring up the products page in the site admin, then a product thumbnail image will have html that looks like this:
It’s not using the 38×38 pixel size thumbnail file.
I’ve looked in eCommerce and the importer for a configuration setting but failed to find it. What am I missing here?December 7, 2011 at 2:54 am #8849jlaryszParticipant
Here’s my interpretation of the problem.
eCommerce generates several thumbnails when a product is uploaded. You specify a primary thumbnail – say a-thumbnail.jpg. According to how you have set up your site, eCommerce knows that it will need thumbnails of sizes (for example) of 31px X 31px, 38px X 38px, 148px X 148px, and so on. The site could generate these dynamically when the thumbnail is called up, and this is the fallback position. However, to avoid this, eCommerce generates thumbnails as part of the upload process. It names these a-thumbnail-31×31.jpg, a-thumbnail-38×38.jpg, a-thumbnail-148×148.jpg – you see the pattern. I think these are recorded in the database, but I’m not sure. What I am sure of is that even if these files exist, eCommerce doesn’t always use them. One circumstance is when using images that come from a Nikon camera. Some better Nikons names image files as X – for example, 311X2000.jpg. I think that eCommerce is interpreting the file basename as an image size and thus screwing up. I put a kludge into eCommerce in the code that works all this out so that there is a final check on whether an appropriate thumbnail file exists, and if it does my patch forces the code to use it. It works for my site but I didn’t generalize the file location part, it was getting too hard to be worth it. Doing this precludes ever upgrading eCommerce again unless eCommerce fixes it of course – it’s a rotten way to do things but it’s all that left to me.
I might be wrong in my reading here. Does anyone else have a better idea?
I don’t know how to put a ticket into ecommerce development – who owns that thing anyway?December 7, 2011 at 3:23 pm #8850Michael VisserKeymaster
Hi jlarysz, thanks for raising this. WP e-Commerce is maintained by Instinct and other developers, you can raise an issue over on Google Code.
I suggest creating an issue and requesting either a fix or adding a filter so that you can patch this while allowing Plugin updates; especially for security. 🙂
- The topic ‘[Resolved] Web Site Performance’ is closed to new replies.