Digital PressWorks Web Design & Web Development

ShoppingCart Frequently Asked Questions

IMPORTANT!! BACK UP YOUR DATABASE FILES REGULARLY!
No server is immune to hardware failure and data loss. Digital PressWorks Shopping Cart uses text files to store data. These files are only as stable as your server file system. It is possible for files to become corrupt or broken. Download your entire cartdata folder using FTP or SSH on a regular basis so that you don't lose your data.

What are the system requirements?
Digital PressWorks Shopping Cart uses text files to store data. It does not require an external database such as SQL to function. The program only requires a Unix or Windows based web server with a reasonably recent version of Perl installed to run. If you plan to use an Authorize.net compatible service or to store credit card information and run the transactions manually later you will need the ability to access the script through a secure server. PayPal and WorldPay provide a secure server to encrypt credit card data.

How many products will the shopping cart handle?
This depends greatly upon how robust your web server is, but you can expect the program to handle several thousand products quite easily. A more important question is how many orders will it handle. This version cannot be expected to handle more than 5 thousand orders in the order database at one time. You will need to remove archived orders from time to time to avoid putting a strain on your web server.

What type of payment options does the shopping cart support?
Digital PressWorks ShoppingCart allows you to accept payments in 5 different ways. You can provide more than one option for your customers or only one option.

The shopping cart will accept and store credit card information so that payments can be processed manually at a later time. (Our demo is set up for this option) Credit card numbers are rigorously checked for proper format and expiration, greatly reducing the chance of a card number being entered incorrectly.
The shopping cart can be easily configured to accept payments via PayPal.
The shopping cart can be easily configured to accept payments via WorldPay.
The shopping cart is compatible with any credit card processor that uses the Authorize.net Gateway. Because it is so popular, many card processing companies either use this system exclusively, or offer an emulation of it for compatibility.

Instead of processing the card automatically when an order is receive via Authorize.net, the shopping cart stores the credit card information with the order. When the order is viewed in the order database, a button is available for instantly submitting the card information to Authorize.net for payment of the order. This allows the merchant to view an order before deciding to process the credit card.

Although Authorize.net will allow you to process a payment automatically when the order is receive, we have determined after years of e-commerce experience that for most e-businesses it is more advantageous to process credit cards and payments when filling the order, rather than when taking the order.

The main reason for this is that the ability to view the order and determine if it can be fulfilled before charging the card makes customers a lot happier.

Another advantage is that there is no need to rely on Authorize.net being up and running to accept an order. If Authorize.net is down you can always wait and post the payment later.

The only disadvantage is that even though credit card numbers are rigorously checked by the program for proper format and expiration, occasionally the merchant will receive card information that cannot be processed. However, the customer will not be intimidated with rejection messages when placing the order and it is easy enough to contact the customer for an alternative payment method.
The shopping cart can take an order for someone who wants to mail in a check or money order. You simply hold the order in the database until the payment comes and then you process it.

If none of these methods of payment appeal to you, we can make customizations for compatibility with any credit card gateway.

Can the script interact with UPS or other shipper tables to calculate exact shipping charges?
No, but the program does allow you to create your own shipping calculation tables to cover your shipping and handling costs. You need to ask yourself, "Do I really need to pass on exact shipping charges to my customers?" I have never seen a large e-tailer that ever did. Shipping and Handling fees usually include enough to cover packing materials and labor associated with getting the product ready for shipping. They also include enough to cover the most expensive shipping cost for a product. Customers are used to being charged shipping and handling this way.

For example, when was the last time you ever saw a TV commercial advertising XYZ product that said: "Buy now for only $29.95 plus shipping that we will figure out after you tell us exactly where you live so we can give you an exact charge"? Never. It is always "$29.95 plus $5.95 shipping and handling" or something like that.

Will Digital PressWorks ShoppingCart work with a secure server?
Yes! A secure server connection encrypts data sent between the user's web browser and the server so that if anyone intercepts it, they will only receive garbled data. Use of a secure server is not required, but highly recommended if you are going to process credit cards manually. If you are going to use Authorize.net a secure server is required. However, if you are using PayPal or WorldPay, it is not really necessary because the actual payment transactions will take place on PayPal or WorldPay's web site and they already use a secure server.

Since encryption takes time and computing power, the shopping cart is designed so that only the checkout is encrypted to protect credit card information.

You define your secure server URL in the configuration file. The most common hosting setups allow you to access the same files and folders securely or non-securely just by changing the URL through which they are accessed. Example: not secure -> http://www.mywebsite.com/cgi-bin/cart.cgi vs secure -> https://secure.myhost.com/mywebsite/cgi-bin/cart.cgi

I have access to a secure server, but it is on another machine or a separate place from my normal web hosting. How do I make that work?
The script can still work for you, only you will have to install everything on the secure server and run it exclusively from there. The only disadvantage to this is that while normally only the checkout pages are secure, every page created by the store will be secure. Since encryption takes time, there will be some performance lag, but usually this is not noticeable.

I keep getting a script error that says the permissions are wrong. What permissions should be set on the scripts?
This information is detailed in the readme.txt file included with the program.

If you are still confused about file permissions on your web server, contact your sysadmin and ask him or her what the correct permissions settings are for what you want each script and folder to be able to do.

I'm getting an error that says "file cartconfig.pl not found" or something similar.
Make sure your cartconfig.pl file is in the same folder as the rest of the scripts. If it is, your server may require full paths.

You will need to change the require statements at the top of all the scripts from

require "cartconfig.pl";

to something like

require "c:/websites/mysite/cartconfig.pl";

On the admin.cgi script do the same thing with the require "authorize.pl" statement.

The admin script seems to be working at first, but when I try to log in it tells me my user session is expired. Why?
The working folder that you define in cartconfig.pl must have read and write permission (Normally 777). If it doesn't, the script will not be able to write your session data. Also, check to make sure your paths are defined properly in cartconfig.pl. Paths do not start with HTTP!

I can't get the photos to upload and display. How do I fix it?
All of the upload subroutines for the cart have been rewritten as of 1-8-04. Former versions used the CGI.pm Perl module for uploads. Microsoft released a new version of Front Page Extensions for Unix servers in late 2003 which has a serious conflict with CGI.pm uploads. As a consequence, uploads stopped working for many users with the scipt running on these servers. If you have this problem make sure you are using the latest version of the script.

Other problems may be as follows.

It could be a permissions problem. Your photos folder must have read and write permissions (Normally 777).
It could be a problem with the path and URL information in cartconfig.pl. Check them to make sure they are set correctly.
It is possible that your server will not allow normal http access to images in your cgi-bin folder. If this is the case, you will need to move your photo directory outside of the cgi-bin. (don't forget to specify the path changes in cartconfig.pl)
Lastly, there is always the tiny possibility that your web hosting company will not allow HTTP uploads.

If you have tried everything and can't get the uploads to work, use FTP, or SSH to upload all your images to a folder on your site. Then you can use the optional image URL fields to specify the URLs of your photos. They will display in the shopping cart just as if you had uploaded them with the script.

The program works great in Internet Explorer, but it chokes sometimes in Netscape. What is wrong?
The HTML output of the script is very basic HTML code that should be easily interpreted by most browsers, but there are a few things to keep in mind.

First, the script pulls in the HTML code that you define with your template.html file for the look and feel of your shopping cart. If your template.html file is not compatible with multiple browsers, then the script won't be either. Netscape can be particularly frustrating because if it doesn't like your code, sometimes it won't display anything at all.

Keep in mind also that if you are using SSL to secure checkout, your template page has to work using that URL as well as a non-secure URL. Definitely check the template.html for browser compatibility through a secure URL before you put the shopping cart into production. If you are using Authorize.net you must use full secure URLs for all the images and links on your template page or it won't work correctly in any browser!

Style Sheets can present big browser compatibility problems too and must be checked on multiple browsers. If you are linking your style sheet to your template.html file, make sure the URL works on a secure server if you need it to do so.

Second, if you are linking to categories from static HTML pages you must use a + instead of a space in the URL. This only matters in categories that have more than one word, of course. IE doesn't really care, but Netscape will choke if there is a space in the URL.

All of my customers see the same shopping cart. Why is that?
More than likely you have not followed the linking instructions detailed in the readme.txt file properly. DO NOT just copy the URLs from the browser address window when creating hyperlinks to the store. The addresses that appear in the address window will not work properly unless modified.

You must remove any reference to the uid variable in the URL. For instance, a URL such as this: http://www.myserver.com/cgi-bin/cart.cgi?action=link&product=1&uid=5 will force every customer to be assigned uid 5. Therefore, every customer will see the shopping cart for user 5. You must remove all references to uid in your URLs so the script can automatically assign a unique user identification.

How do I link directly to products and categories of products?
This information is available in the readme.txt file distributed with the scripts.