What are the system requirements for ABCgi Cart?
ABCgi Cart runs on web servers with Perl 5 or higher installed
(an extremely common setup). It runs equally well on Unix or Windows
based servers. The script requires NO additional database software
because data is stored in simple pipe delimited text files.
How many products will the shopping cart handle?
I estimate the cart should handle up to approximately 10,000 products
without any serious lag. This is dependent upon how robust the
server is, of course, and also how detailed your product descriptions
are. The cart has been tested with about 3,000 products on a reasonably
robust server with no noticeable lag.
What type of payment options does the shopping cart support?
ABCgi Cart allows you to take payments in one of 3 different ways
1. ABCgi 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)
2. ABCgi Cart can be easily configured to accept payments via
PayPal. PayPal is great if you are on a tight
budget and can't get or don't want the responsibility of a credit
card merchant account with a financial institution. Unfortunately,
in my opinion the interface is a little clumsy and confusing
for novice internet users, and customers must be directed away
from your web site to PayPal.com in order to pay. Whether you
get them back again or not is a question mark so, unfortunately,
you still need to manually verify orders in the shopping cart
database by checking against your PayPal payments.
3. If you are ready to step up to Real Time Credit
Card Processing, ABCgi 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.
If you are looking for a merchant account with a provider that
is compatible with ABCgi Cart, we recommend the following: Quick
Commerce
The integration with this system is seamless and it appears
to the user that they never really leave the shopping cart program.
Credit cards are processed in real time and if a card is declined,
the order will not go into the database. The data is already
entered so nobody needs to type it into one of those credit
card processing machines.
Of course, we can make customizations for compatibility with
any credit card gateway.
Can you make modifications to the shopping cart for me?
Absolutely. Contact us for a custom programming quote.
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 etailer 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 ABCgi Cart 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 for most situations! Since
encryption takes time and computing power, the shopping cart is
designed so that only the checkout is encrypted to protect credit
card information. If you intend to do real time credit card processing,
secure server access is a must. However, if you are using PayPal,
it is not really necessary because the actual payment transactions
will take place on PayPal's web site and they already use a secure
server.
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/store.cgi
vs secure -> https://secure.myhost.com/mywebsite/cgi-bin/store.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 perfomance
lag, but usually this is not very noticeable.
I am in the UK (or other country) and want to use £
instead of $. How can I do this?
The latest version of the script allows you to define the currency
symbol in the configuration file. On earlier versions just do
a text search and replace on the store.cgi file. Search for \$
and replace with £. Be sure to use the \ before the $ otherwise
it will mess up the code.
What permissions should be set on the scripts?
Windows servers do not require any file permissions, but your
web server must allow CGI programs to execute and your script
must be able to read and write to the folders you define for authentication,
customer data, photos, and working data.
Unix servers do require file permissions, but requirements can
vary from server to server. Normally all the scripts should be
set to 755 with the exception of config.pl which can be set to
644. This grants the scripts permission to execute and config.pl
can be read. Again, your script must be able to read and write
to the folders you define in config.pl (usually the default settings
will do, if not, start with 777 and work your way down).
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.
The office script seems to be working at first, but when
I try to log in I get sent back to the login screen or I get a
blank screen. Why?
Assuming you entered the right user name and password, this is
likely a permissions problem (see above). The script cannot write
to the auth folder and create a session file for authentication
so it can't verify that you are logged in. Make sure you have
created the auth folder, defined it properly in config.pl and
that it has read and write permissions. You can start with chmod
777.
I can't get the photos to upload. How do I fix it?
There are several potential problems. It could be a permissions
problem (see above). 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 config.pl)
Photos can only be uploaded in JPG format. As a security measure
the program checks to make sure only files with the .jpg extension
are uploaded. Any other image format will not work.
upload.cgi uses CGI.pm, a Perl library. In some rare cases this
library might not be installed on your web server. If this is
the case you may need to ask your sysadmin to install the library
or upgrade to the latest version of Perl.
Lastly, there is always the tiny possible that your web hosting
company will not allow http uploads. If this is the case, you
are out of luck. Check out our hosting services.
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 (which you should), 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 are big browser compatibility traps
too. I recommend using them sparingly. (Actually, I recommend
that whether you are using the script or not, but that is just
me! Heh, heh.)
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.
Lastly, Netscape's latest version 6 has purposefully steered
away from browser compatibility and offers all kinds of problems
for web developers. It looks like their business strategy is to
eventually force web programmers to design sites that are compatible
with either IE OR Netscape and thereby force every computer user
to have both browsers on their systems. Currently 80% of Internet
Users use IE so in my mind, that has to be the priority.
Is there a way to modify the program to be able to remove
items one at a time from the cart instead of removing all of them
at once?
OK, I finally gave up in on this and added this feature to the
latest version of the shopping cart. I think I was able to implement
it in a way that will be easy to use and not too confusing.
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 following section properly. There is a tendancy
to 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/store.cgi?action=link&sku=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, however, it is worth repeating here.
A nice feature of this program is the ability to link to any
product or product category externally or internally. A sample
link would look like this:
<a href="store.cgi?action=link&sku=25">Click
here for pink sneakers!</a>
"action=link" tells the program that this is a direct
link and "sku=25" tells it which product to display.
sku stands for Stock Keeping Unit and a sku number is a unique
identifier for each product in the store.
Below is a sample of how to link to a product category:
<a href="store.cgi?action=search&category=Pink+Shoes">Pink
Shoes</a>
"action=search" tells the program that this is a search
across the products in the store. "category=Pink+Shoes"
tells the program that it's search should only display products
in the "Pink Shoes" category.
The product description fields will accept HTML code so you can
imbed these types of links into the description of your products.
For example, on the page displaying pink sneakers you might want
a link to yellow sneakers or to all shoes.
This also enables a web developer to create main categories with
static HTML pages and then link to sub categories created within
ABCgi Cart.
