Archive for August, 2014

Whether you have 1,000 visitors to your website a day, or just 100, if your website displays images, it is important that those images are optimized for file size (how many KB’s the file is) as well as the image size (800 pixels wide by 800 pixels high).

As I mentioned in a post about 4 years ago, even if your image size is 800 px or smaller width or height wise, the file size can still be huge.  Huge image files eat up huge amounts of bandwidth which can cause your website to be suspended for excessive bandwidth use.  We do Zen Cart Hosting for our clients, and use Zen Cart for our websites, so we completely understand the importance of having high quality product images as well as additional images for your products.  However, you can still have great quality images that are not huge in file size or image size.

I recently had to optimize some images for a client because the website was up to 45 GIGABYTES in bandwidth and we still had another 1 1/2 weeks left in the month.  When going into the hosting account cPanel, clicking on AWSTATS  and looking under the Monthly Report section I saw the following:

awstatsmonthlyshistory

This told me that some time in July, something happened to almost triple the bandwidth usage from the previous months.  I then scrolled down to the File type section and saw that 95% of the bandwidth was being eaten up by .jpg files.  That gave me the place to start to get this bandwidth back under control.

awstatsjpg

Oncfolderse I identified the problem and contacted the customer who gave me permission to fix the problem, I downloaded to my computer all files in the images folder that were 50 bytes in file size and larger.

From that point, I opened each image individually using a free image software called IrfanView and re-sized them to be no larger than 800 pixels high or wide.  This took the file size down dramatically – but not enough.

Then, because the images were a mixture of .JPG (all caps), .jpg, .png, .TIF (all caps) and .tif, I separated all the images into respective folders with those extensions.  There is a method to my madness on this which you will see soon.

Once separated, I created a new folder under each of the separated folders – each folder was simply named “optimized”.  Then I opened another free software called Radical Image Optimization Tool (RIOT) and, using the batch function, pulled in all the images in one folder.  I set up the OUTPUT folder to be the /optimized sub folder, then clicked to optimize the images.  WOW what a difference this made in the file sizes!!!  Wen I got to the folders that were ALL CAP – RIOT automatically renames the file the way it SHOULD have been – which is all lower case.  However, because the Zen Cart is looking for the all caps extension, I had to then use another free software called File Extension Changer to change the files to all upper case extensions.

Whew!!  That was A LOT of work – took almost 2 hours!  But the final results were something to write home about!  This site started out with an image folder that was 94,288,507 bytes and ended up being 22,089,757 bytes after my optimization!  That is more than 75% reduction in file sizes!

What does this mean?  It means that the site is going to load MUCH faster, all images will be served up and visible, AND the site is no longer hogging bandwidth!

I hope this post helps you in your endeavor to make your website fast and not hog bandwidth.

 

 

 

 

 

 

One of the many great features to Zen Cart is what is called EZ-Pages.   EZ-Pages allows you to add information to your website that does not really “fit in” on a product page, category page or your standard Shipping, Privacy, etc. pages that are found under Tools>Define Pages Editor in your admin area.

I have seen sites with over 100 EZ-Pages in my line of work.  And I have seen sites that don’t have any.  It really just depends upon the needs of individual businesses.

In versions prior to 1.5.2 of Zen Cart, you could leave an EZ-Page “disabled” by not putting a sort order number under header, footer or sidebox.  BUT, you could still LINK to that page and it would show up for everyone to see.  It just did not have a link in the header, footer or sidebox.

ezpage

Recently, when doing an upgrade for a customer from 1.5.1 to 1.5.3, my customer discovered that if the link was clicked, it went to a dreaded white page – and no error log was created.

After doing a quick file comparison between version 1.5.1 and 1.5.2, I discovered a “fix” to be able to continue doing a direct link to a disabled EZ-Page.  The fix is as follows:

Open includes/modules/pages/page/header_php.php and scroll down to about line 29

Change the following code:
// comment the following line to allow access to pages which don’t have a status switch set to Yes:
$sql .= ” AND (status_toc > 0 or status_header > 0 or status_sidebox > 0 or status_footer > 0)”;

To this:
// comment the following line to allow access to pages which don’t have a status switch set to Yes:
//$sql .= ” AND (status_toc > 0 or status_header > 0 or status_sidebox > 0 or status_footer > 0)”;

Since there is no “override directory” for this file, be sure to change the original header_php.php filename to header_php.php.txt to save it as a backup just in case something messes up.

Once this code is changed, you should now be able to link successfully to deactivated EZ-Pages