uShop Java Shopping Cart Software

USHOP 2.0

Table Of Contents

CGI SCRIPT TROUBLESHOOTING
1. Incomplete Set Of HTML Headers Error
MISCELLANEOUS ORDER PROCESS TROUBLESHOOTING
1. Nothing happens when I press the Order Button - I just get a "Please wait a moment for your order number" message.
SMTP ORDER APPLET TROUBLESHOOTING
1. No email received when using the SMTP Order Applets
GENERAL APPLET TROUBLESHOOTING
1. String Index Out Of Bounds Error

1.1 Server Error

Upon installing the script on your server, the first thing you should do is use your browser to test the script by typing in the URL of the script on your server. This should produce a copyright page such as when you visit:

http://www.uburst.com/cgi-bin/ushop_cgiscript.pl

If you are getting a Server Error instead, then the problem is usually one of four things:

The path to Perl is incorrect.
The Path to perl is specified as the very first line of the CGI script. Typical values are /usr/bin/perl, /usr/local/bin/perl/ and /bin/perl. If you do not know what the path to perl is on your server, then you can ask your web hosting provider. NOTE: When specifying this path to perl, you must include the "#!" in front of the path. Example: #!/usr/bin/perl
You did not include the "\" character in front of the "@" sign when specifying the store's email address in question 6 of the script setup.
When specifying the store's email address, instead of using the "@" sign in your email address, you must use "\@" - This is because the "@" sign is a special character in the Perl programming language and therefore must be preceded by a "\" character in this case. Note: If you used the uShop CGI Setup Wizard to create the script for you, then this special character was added automatically for you.
The file was transferred in BINARY mode (as opposed to ASCII or TEXT mode).
When transferring the CGI script to your server, you must transfer it in ASCII or TEXT mode - as opposed to BINARY mode. Your FTP program should give you an option to do this - so be sure to transfer the CGI script in ASCII or TEXT mode.
The script does not have execute permissions.
Once the CGI script is transferred to your CGI directory on your server, you must change the permissions to READ and EXECUTE (chmod 755). If your server is a UNIX server, you should be able to change the file's permissions via your FTP program. If your server is an NT server, then you may have to get your web hosting provider to make the file executable.

For additional assistance configuring the CGI script for your server, you may want to try out our uShop CGI Setup Wizard our

uShop 2.0 Reference Site

The uShop CGI Setup Wizard is a utility that will create personalized instructions and a custom CGI script ready for downloading to your server.

1.2 CGI Script is being displayed - not executed

Upon installing the script on your server, the first thing you should do is use your browser to test the script by typing in the URL of the script on your server. This should produce a copyright page such as when you visit:

http://www.uburst.com/cgi-bin/ushop_cgiscript.pl

If your server displays the script instead of actually executing it, then the problem is usually one of three things:

The CGI script does not have the correct file extension for your server.
That is, some servers are configured to only execute scripts that end in .pl and others are configured to only execute scripts that end in .cgi. Check with your web hosting server and rename the file if necessary.
The directory that you put the script is not configured to execute CGI scripts.
That is, usually your web hosting service will have to make a special directory for you to put your cgi scripts in such as cgi-bin or cgi-local. Again you can check with your web hosting provider.
The permissions on the script itself are not correct.
That is, you must make sure the script has read and execute permissions. This can be done with your FTP program on UNIX machines (chmod 755). People using NT servers, may have to get their web hosting service to change the permissions to executable for them.

1.3 CGI Script tries to be downloaded - not executed

Upon installing the script on your server, the first thing you should do is use your browser to test the script by typing in the URL of the script on your server. This should produce a copyright page such as when you visit:

http://www.uburst.com/cgi-bin/ushop_cgiscript.pl

If your browser tries to download the script instead of actually executing it, then the problem is usually one of three things:

The CGI script does not have the correct file extension for your server.
That is, some servers are configured to only execute scripts that end in .pl and others are configured to only execute scripts that end in .cgi. Check with your web hosting server and rename the file if necessary.
The directory that you put the script is not configured to execute CGI scripts.
That is, usually your web hosting service will have to make a special directory for you to put your cgi scripts in such as cgi-bin or cgi-local. Again you can check with your web hosting provider.
The permissions on the script itself are not correct.
That is, you must make sure the script has read and execute permissions. This can be done with your FTP program on UNIX machines (chmod 755). People using NT servers, may have to get their web hosting service to change the permissions to executable for them.

1.4 Server Error when trying to place order

Upon installing the script on your server, the first thing you should do is use your browser to test the script by typing in the URL of the script on your server. This should produce a copyright page such as when you visit:

http://www.uburst.com/cgi-bin/ushop_cgiscript.pl

If you get the copyright page successfully, but get a Server Error when trying to actually place an order, then the problem is usually that the path to sendmail is incorrect (on UNIX servers) - double-check the path with your web hosting service.

1.5 Unable to create socket Error

The "Unable to create socket" error indicates that you may not have the correct $AF_INET and $SOCK_STREAM settings for your server. We have found most NT servers use $AF_INET = 2; and $SOCK_STREAM = 1; but if those settings do not work for you, try editing the ushop_cgiscript.pl and change the settings to $AF_INET = 1; and $SOCK_STREAM = 1; (configuration question #5 at the top of the ushop_cgiscript.pl).

Note that if you are still having this problem after playing with the $AF_INET and $SOCK_STREAM settings in question #5 at the top of the ushop_cgiscript, the problem may just be that your server cannot connect via sockets to your mail server. Instead, your server may be configured to use something like Blat or WindMail...two email utilities that are common to NT servers. If your server does use Blat or WindMail....let us know, we have special versions of the ushop_cgiscript that have been modified to use Blat or WindMail to send the email notifications.

1.6 Unable to open ./orders/.... Error (UNIX Server)

If upon trying to place an order you get an "Unable to open ./orders/U123456789" error, it means that the CGI script cannot create the unique order file. That is, the uShop CGI script will try to write an order file to the "orders" directory each time an order is placed. Therefore, the "Unable to open orders..." error is usually caused by one of two things:

The "orders" directory does not have "WRITE" and "EXECUTE" permissions.
The $order_directory setting is incorrect.

Here are a few things to try to correct error:

Check to make sure that you created the "orders" directory. If you used the CGI setup wizard to generate a CGI script for you, then this "orders" directory should be a subdirectory of your CGI directory.

NOTE: The location of this directory is specified by the $order_directory parameter in the CGI script, so you can make the orders directory whereever you want provided the $order_directory setting in the CGI script is correctly set to point to that directory. The default value is: $order_directory = "./orders/";
Be sure to give the "orders" directory WRITE and EXECUTE permissions. That is, use your FTP program to give the "orders" directory WRITE and EXECUTE permissions (chmod 733).
If you are still getting the "unable to open orders...", then you may need to edit the CGI script - using any text editor such as WordPad or NotePad - and change the $order_directory setting to reflect the FULL path to the "orders" directory. This is NOT the URL (http://..), but rather some full path such as "/www/htdocs/cgi-bin/orders/".

For example, try editing the script and changing the $order_directory setting in questions #10 from:

$order_directory = "./orders/";

to the full path to the directory:

$order_directory = "/www/htdocs/cgi-bin/orders/";

(You may need to ask your web hosting provider how to specify the full path on your server)

1.7 Unable to open ./orders/.... Error (NT Server)

If upon trying to place an order you get an "Unable to open ./orders/U123456789" error, it means that the CGI script cannot create the unique order file. That is, the uShop CGI script will try to write an order file to the "orders" directory each time an order is placed. Therefore, the "Unable to open orders..." error is usually caused by one of two things:

The "orders" directory does not have "WRITE" and "EXECUTE" permissions.
The $order_directory setting is incorrect.

Here are a few things to try to correct error: (One of the first 4 options usually works for most people)

Check to make sure that you created the "orders" directory. If you used the CGI setup wizard to generate a CGI script for you, then this "orders" directory should be a subdirectory of your CGI directory.

NOTE: The location of this directory is specified by the $order_directory parameter in the CGI script, so you can make the orders directory whereever you want provided the $order_directory setting in the CGI script is correctly set to point to that directory. The default value is: $order_directory = "./orders/";
Make sure that the "orders" directory has WRITE permissions. You will probably have to get your web hosting provider to change the permissions on the directory for you since most FTP programs will only change the permissions on UNIX servers - but not on NT servers (although they don't give you any error indication). So get your hosting provider to give the directory WRITE permissions.
If you are still getting the "unable to open orders..." error, you may need to edit the uShop CGI script (using any text editor such as WordPad or NotePad) and change the $order_directory parameter in question #10 from:

$order_directory = "./orders/";

To

$order_directory = "orders/";

(This is because some NT servers don't like the first "./" to refer to the current directory.)
If you are still getting the "unable to open orders..." error, you may just need to just use the FULL path to the "orders" directory. This is NOT the URL (http://..), but rather some full path such as "c:/mydirectory/cgi-bin/orders/".

For example, try editing the script (using any text editor such as WordPad or NotePad) and changing the $order_directory setting in question #10 to be the FULL path to the "orders" directory, such as:

$order_directory = "c:/mydirectory/cgi-bin/orders/";

(You may need to ask your web hosting provider how to specify the full path on your server)
If you are still getting the "unable to open orders..." error, then it may be because your server does not allow you to write to subdirectories of the cgi-bin. We have seen this before, so some people ended up moving the "orders" directory from being a subdirectory of the cgi-bin - to being at the same level as the cgi-bin (In other words, they moved the "orders" directory up to their main document directory).

Of course, you would again have to set the permissions on that directory so that it has WRITE permissions.

In addition, you will have to edit the ushop_cgiscript (using any text editor such as WordPad or NotePad) and change the settings of configuration question #10 at the top of the script. Change this path according - such as modifying the relative path to look up one directory from you cgi-bin:

$order_directory = "../orders/";

Or better yet, to the full path to your "orders" directory (if you know it) - for example:

$order_directory = "c:/mydirectory/orders/";

(Be sure to use forward ("/") slashes in the path instead of backslashes (\) - since backslashes are special character in Perl.
And finally, if that still doesn't work, are you using IIS 4 to set the permissions? If so, you may need to find a different way to set the permissions. That is, below is an exert from an email from someone who was getting a similar problem with IIS. Apparently IIS 4 has a problem setting the permissions correctly, so perhaps you can use a different way to set the permissions. This person had his own server, so he was able to just use NT Explorer to do it - perhaps you (or your web hosting provider) to do the same.

"... the short version is. I discovered on my local NT server, with IIS 4 that if you set write permission to the ./orders/ directory from the IIS manager, you got the error unable to open ./order/U123456789 when you run the script, but if you set the permissions from NT Explore it works fine."

1.8 Order is placed - but I don't get any email (UNIX Server)

If upon trying to place an order you successfully get the order receipt page - but you never receive any email notifications - then there are two scenerios to check based on whether the order files are being created in your "orders" directory. That is, each time an order is placed, an order file will be created in the "orders" directory that you made on your server. Take a look on your server and see if the order files are being created and then follow the appropriate scenerio below.

Scenerio 1 - No Email and No Order Files

If the order files are not being created and yet you still successfully get the order receipt page, then you may just have the "scriptpath" parameter of your order applet pointing to the ushop_cgiscript on our www.uburst.com server. That is, check the HTML of your order applet and make sure that the "scriptpath" parameter is pointing to the ushop_cgiscript on your server.
Scenerio 2 - OPTION 1 - No Email but the Order Files Are Successfully Being Written

If the order files are successfully being written to your orders directory - then the email problem may have to do with the sendmail configuration on your server. uShop uses the standard UNIX mail utility "sendmail" to send the email notifications, however, some UNIX servers do not like the "-n" option to be used with sendmail. If this is the case with your server, you can try removing the "-n" option from the sendmail command line in the ushop_cgiscript. To do this, follow the following steps:
1. Open the ushop_cgiscript file with any text editor such as WordPad.
2. Locate the following line in the script (it will be just a few lines after the configuration questions at the top of the script):
  
  $mail_program = $sendmail_path . " -t -n";
3. Remove the "-n" by changing that line to:
  
  $mail_program = $sendmail_path . " -t";
4. Save the file and try it out on your server again.

Scenerio 2 - OPTION 2 - No Email but the Order Files Are Successfully Being Written

If the order files are successfully being written to your orders directory - then the email problem may have to do with the sendmail configuration on your server. That is, on UNIX servers, uShop uses the standard UNIX mail utility "sendmail" to send the email notifications. If for some reason, sendmail is not sending any email (perhaps because it is not correctly mapping the email address with the DNS table), you can try using SOCKETS to send the email via your regular mail server.

That is, the only difference between setting the $server_os to "UNIX" or "NT" (question #2 at the top of the CGI script)- is how the script sends the email. For "UNIX", the script uses "sendmail". For "NT", the script uses SOCKETS. So if sendmail is not working on your UNIX server, then perhaps opening a socket to your mail server will work. To try this, you will have to open the ushop_cgiscript with any text editor (such as WordPad or NotePad) and make the following changes:

At the top of the script, set question #2 to:

$server_os = "NT";
Set question #4 to your mail server's IP address, something like:

$smtp_address = "123.456.789.0";
Adjust Question #5 accordingly. You may have to play with these settings, but usually just uncommenting the first three lines and commenting out the second two lines will work for UNIX servers. That is set #5 to:

use Socket;
$AF_INET = AF_INET;
$SOCK_STREAM = SOCK_STREAM;

#$AF_INET = 2; # Comment out these lines with a # sign.
#$SOCK_STREAM = 1;

And that should do it!
1.9 Order is placed - but I don't get any email (NT Server)

If upon trying to place an order you successfully get the order receipt page - but you never receive any email notifications - then there are two scenerios to check based on whether the order files are being created in your "orders" directory. That is, each time an order is placed, an order file will be created in the "orders" directory that you made on your server. Take a look on your server and see if the order files are being created and then follow the appropriate scenerio below.

Scenerio 1 - No Email and No Order Files

If the order files are not being created and yet you still successfully get the order receipt page, then you may just have the "scriptpath" parameter of your order applet pointing to the ushop_cgiscript on our www.uburst.com server. That is, check the HTML of your order applet and make sure that the "scriptpath" parameter is pointing to the ushop_cgiscript on your server.
Scenerio 2 - No Email but the Order Files Are Successfully Being Written (BLAT OPTION)

If the order files are successfully being written to your orders directory - then the email problem may have to do with the socket/mail server configuration. As an alternative to using sockets to send email on NT servers, we do have a version of the script that uses BLAT to send email. BLAT is an email utility that is common to most NT servers, so if your server can use BLAT, try using this script:

uShopBlat.zip

(Right-click on the link and choose SaveAs)

(English version only).

Notes about the BLAT script:
1. You can rename the script to "ushop_cgiscript.pl" or to whatever you are currently using.
2. You will have to open the script with any text editor (such as WordPad or NotePad) and answer the configuration questions at the top of the script -- Use the settings at the top of your current script as a model.
3. And be sure to configure the new setting on line #7 of the script to point to BLAT on your server, such as:
  
  $mailprog = 'c:/Blat/blat.exe';
4. At this time, this BLAT script is only available for the English Versions of uShop, but we are working on making a BLAT script for the international versions of uShop as well.
Scenerio 3 - No Email but the Order Files Are Successfully Being Written (OTHER OPTIONS)

If the order files are successfully being written to your orders directory - then the email problem may have to do with the socket/mail server configuration. If using the BLAT alternative to send email (as described above) is not available on your server, then let us know what the prefered method is to send email from your server. We have several other versions of the ushop_cgiscript that use different methods to send email - such as a version that uses WindMail. Let us know and we may already have a version of the ushop_cgiscipt that uses the email utility you need.

1.10 Order is placed, I do receive an email, but no orders are being written to my orders directory

If the order does appear to be placed successfully and you do receive and email, however, no order files are being written to your orders directory - then the problem may be related to the "scriptpath" setting of your order applet. That is, check the "scriptpath" parameter of your order applet and make sure that it is pointing to the ushop_cgiscript on your server (It may still be pointing to our server - but it should be pointing to your server).

Follow this link for some general information about the "orders" directory: About the orders directory.

1.11 Unable to bind Error

The "Unable to bind" error usually indicates that you may not have the correct $AF_INET and $SOCK_STREAM settings for your server. We have found most NT servers use $AF_INET = 2; and $SOCK_STREAM = 1; but if those settings do not work for you, try editing the ushop_cgiscript.pl and change the settings to $AF_INET = 1; and $SOCK_STREAM = 1; (configuration question #5 at the top of the ushop_cgiscript.pl).

Note that if you are still having this problem after playing with the $AF_INET and $SOCK_STREAM settings in question #5 at the top of the ushop_cgiscript, the problem may just be that your server cannot connect via sockets to your mail server. Instead, your server may be configured to use something like Blat or WindMail...two email utilities that are common to NT servers. If your server does use Blat or WindMail....let us know, we have special versions of the ushop_cgiscript that have been modified to use Blat or WindMail to send the email notifications.

1.12 Incomplete Set Of HTML Headers Error

An "Incomplete Set of HTML Headers" error usually indicates that you are using an incompatible version of Perl. Ideally, try using Perl 4. You may need to check with your web hosting provider about the various versions/paths to Perl that are available on your server.

2. MISCELLANEOUS ORDER PROCESS TROUBLESHOOTING

2.1 Shopping Cart is empty when I go to the secure server - NOT Using uShopOrderButtonCGI Applet

If you want to keep your store pages on your public server and just the order form on your secure server, you must use the uShopOrderButtonCGI applet to handle transferring the data from the shopping cart on the public server to the shopping cart on the secure server.

See the Making Transactions Secure reference page for instructions on how to setup the uShopOrderButtonCGI applet.

2.2 Shopping Cart is empty when I go to the secure server - Using uShopOrderButtonCGI Applet

If you are using the uShopOrderButtonCGI applet to transfer shopping cart data from your public server to your secure server but the shopping cart on your secure server is always empty, then the problem will more than like be due to the format of your order applet. In particular, the first .html line of your order applet must be all on one line - DO NOT let the line wrap around to the next line (A problem that is common when using Microsoft Frontpage to edit the files).

The uShop CGI script will automatically insert a hidden data parameter immediately after the first .html line of the order applet, so it is important to keep the first .html line of the order applet on a single line. Manually edit the page with a text editor such as NotePad or WordPad, if necessary.

Example - Wrong (Letting the first line wrap to the next line)

Wrong!

Example - Right (The first line does NOT wrap to the next line)

Right :^)

2.3 "Unknown Order Page" Error

This error may occur when setting up the uShopOrderButtonCGI applet to transfer shopping cart data from you public server to your secure server. It is caused when the order page cannot be found on the secure server. To correct this there are a couple things to check:

Did you put the order page on your secure server?
You must put the order.html page or the order.template page on your secure server so that the CGI script can read it when transferring data to the secure server.
Is the order_page parameter of the uShopOrderButtonCGI applet correct?
This order_page parameter must be specified as path to the order page on your secure server. You can specify this path as a relative path to the CGI script on the secure server such as:
```
<PARAM NAME=order_page  VALUE="../classes/order.template">
```
or as the full directory path of the order page on your secure server such as:
```
<PARAM NAME=order_page  VALUE="/usr/local/htdocs/classes/order.template">
```
You may need to ask your web hosting provider what the full path to your directory is....It will be something like /usr/local/htdocs or /www/htdocs.

NOTE: DO NOT specify the order_page parameter as the URL of your order page.

WRONG: <PARAM NAME=order_page VALUE="http://www.mydomain.com/classes/order.template">

As a final option, and perhaps the easiest, you can just put your order page into the same directory as your CGI script on your secure server then set the order_page parameter of the uShopOrderButtonCGI applet to:

<PARAM NAME=order_page  VALUE="order.template">

Where order.template is the name of your order page.

2.4 Applets do not appear on the Secure Order Page

If the order page on your server is successfully being found, but the applets are not being loaded on the order page, then the problem is usually that your codebase parameter on your order page is missing or is incorrect. For the applets on your secure order page, You must specify the CODEBASE parameter. That is, in order to find your classes on the secure server, you must specify the CODEBASE parameter of all applets on the secure order page. This codebase parameter must be the FULL URL of the classes. For instance, if you put all of the uShop .class files in a directory called "classes" on your public server, then you would specify the codebase parameter of the applets on your server as something like this:

codebase="http://www.yourdomain.com/classes/"

So your order applet would be something like this (Note the CODEBASE parameter in the first line):

Observe The CODEBASE Parameter

Be sure to see the Making Transactions Secure reference page for more information on this.

2.5 Nothing happens when I press the Order Button - I just get a "Please wait a moment for your order number" Message

If upon pressing the order button, nothing seems to happen other than the message "Please wait a moment for your order number." being displayed, then the problem is one of two things:

In the code for you order applet, be sure that you specified the scriptpath parameter. Note: Also watch out for little typos like forgetting to put the first less-than-sign < at the start of the scriptpath line. Example:
```
<PARAM NAME=scriptpath VALUE="https://www.uburst.com/cgi-bin/ushop_cgiscript.pl">
```
In the code for your order applet, be sure to check that you specified the scriptpath parameter as the full URL of the script - not a relative path to your CGI script. Example:
```
<PARAM NAME=scriptpath VALUE="https://www.uburst.com/cgi-bin/ushop_cgiscript.pl">
```

3. SMTP ORDER APPLET TROUBLESHOOTING

3.1 SMTP Order Applet Discussion

We have provided a series of uShopOrderSMTP applets with uShop that do not require the use of any CGI script. These applets, however, send the orders via regular SMTP mail so orders placed with these SMTP applets are not necessarily secure. To ensure secure transactions you should use the uShopOrderCGI applets in correlation with the ushop_cgiscript and the uShopOrderReaderCGI applet. We thought about not including these SMTP order applets with uShop, however, they can come in handy if you just wanted to give customers a way to contact you or give them other options besides payment by credit card (e.g. payment by check, money order, or a previously configured account).

In any case, not everyone can use the SMTP order applets - they are pretty much hit-or-miss. That is they will either work on your server or they won't work on your server. They are very limited due to Java security restrictions.

The requirements to use these SMTP order applets is:

The server you are hosting the web pages on must also be a mail server which uses port 25 to send SMTP mail. To test this, open a DOS window and type:

telnet [yourdomain] 25

If it connects AND the domain name that appears is your own, then you MAY be able to use the SMTP order applets.
Your server must also be configured to send mail outside of their domain. That is, some mail servers are configured so that they do not relay email to mailboxes other than their own.

But, the best way to see if these SMTP order applets will work is to just go ahead and put one on your server and try it out. If you don't get a "connection problem" AND you do receive an the email notification...Hurray, it works! If not, then you will have to use the uShopOrderCGI applets and the uShop CGI script - Be sure to check out our uShop CGI Setup Wizard at our

uShop 2.0 Reference Site

for assistance setting up the CGI script.

3.2 "Connection Problem" when using the SMTP Order Applets

As described above, the uShop SMTP Order applets are pretty much hit-or-miss. That is, they will either work on your server or they won't work on your server. They are very limited due to Java security restrictions.

A "CONNECTION PROBLEM" usually indicates that your web server is not also a mailserver setup to send SMTP mail on port 25.

3.3 No email received when using the SMTP Order Applets

As described above, the uShop SMTP Order applets are pretty much hit-or-miss. That is, they will either work on your server or they won't work on your server. They are very limited due to Java security restrictions.

If you are not getting a "CONNECTION PROBLEM", but you never receive an email notification of the order, then the problem is more than likely that the server is not configured to send mail outside of it's domain. That is, some mailservers are configured so that they do not relay email to mailboxes other than their own.

4. GENERAL APPLET TROUBLESHOOTING

4.1 Bad Magic Number Error

If the applets on your website do not start, but instead indicate a "Bad Magic Number" error in your browser's status bar, the problem is usually caused by when the uShop .class files are uploaded to the server in ASCII or TEXT mode - as opposed to BINARY mode. So try transferring ALL of the uShop .class files to your server again and be sure to select BINARY (or RAW) transfer mode.

4.2 Browser Locking Up with IE5

We have found that in the Java Virtual Machine that was included with Microsoft's Internet Explorer (starting with IE 4.72 and also in the first release IE 5 - JVM builds 3165 & 3167) - there was a problem with multi-threaded applets locking up. (uShop's shopping cart applet was multi-threaded). Microsoft did fix this problem in the latest version of IE 5 which included JVM build 3177 -- but not until after we spent the time to develop a work around in uShop for it. The work around consisted of modifying uShop to not use any multi-threaded applets - which should improve performance on all browsers. So although Microsoft fixed the problem in IE, we went ahead and incorporated the work-around into uShop 2.0 anyway. We recommend upgrading to uShop 2.0 (or later).

NOTE: We also incorporated this fix into uShop Lite, so if using the trial version, use uShopLite version 2.03 (or later).

4.3 money_sign parameter not working properly

Non-U.S. Stores Only: In order for the money_sign parameter to work properly, it is important that the customer views a web page with a shopping cart applet on it before adding any items. That is, since the "money_sign" setting gets set in the shopping cart applet, that means that the shopping cart applet must be viewed by the customer at least once for the setting to take effect. This is normally not a problem if you are using the SMALL view of the shopping cart that appears in a frame or on each store page. If you are NOT using the SMALL view of the shopping cart in a frame or on every page, then the customer could technically add an item to the cart before actually viewing the cart....in which case the text in the shopping cart will show the default "$" because the money_sign was not set yet. A work-around for this is to put the shopping cart applet on the page that most visitors will enter the store through. Set the size to WIDTH=1 and HEIGHT=1 if you don't really want the applet displayed.

4.4 The images do not display in my Image applets

If you are using any of uShop's image applets (the applets with "Image" in the name - such as uShopInputImageButton1) and are having a problem with the image not loading when the applet starts, then it may have to do with where your images and classes are located on your server. That is, for these image applets, the "image" parameter must be specified relative to where your .class files are. This gives you several options:

The easiest option is to just put the image files (.gif or .jpg) in the same directory on your server as the .class files. This way, you can just specify the name of the image file as the value of the applet's "image" parameter.
Another easy option is to just specify the value of the applet's "image" parameter as the full URL of the image on your server. This allows you to put images in any directory on your server. The disadvantage to this is that you won't be able to test your store pages out from your desktop computer....unless you are connected to the internet. (So that the images can be loaded from the specified URL on your server).
A third, and only slightly more difficult option is to put the images in an "images" directory, and then specify the value of the applet's "image" parameter as the path relative to where the .class files are located. For instance, if you have a "images" directory on your server that is at the same directory level as a "classes" directory, then you would have to specify the value of the "image" parameter as "../images/myimage.gif". That is, the "image" parameter is specified relative to where your .class files are located.

TIP: Follow this link for some ideas of organizing the .class files on your server: Managing the .class files.

4.5 I'm upgrading from uShop Lite to the full version, but the applets do not start

If your store and applets were working properly before upgrading to the new applets that are included with the full version of uShop, then the problem may be that you did not replace ALL of the uShop Lite .class files. That is, be sure to delete all of the uShop Lite .class files from your server and then transfer over all of the newer .class files to your server. If you don't replace all of them, then you will usually see a "Check Trial Version" error in your browser's status bar. Again when upgrading, be sure to replace all of the uShop Lite .class files with the .class files that were included with the full version of uShop.

For more information on upgrading, see Upgrading From uShop Lite.

4.6 Check Trial Version Error

If you are in the process of upgrading your store from uShop Lite to the full version of uShop and your store's applets were working properly before upgrading, then the problem may be that you did not replace ALL of the uShop Lite .class files with the newer .class files that came with the full version of uShop. That is, be sure to delete all of the uShop Lite .class files from your server and then transfer over all of the newer .class files to your server. If you don't replace all of them, then you will usually see this "Check Trial Version" error in your browser's status bar. So again when upgrading, be sure to replace all of the uShop Lite .class files with the .class files that were included with the full version of uShop.

For more information on upgrading, see Upgrading From uShop Lite.

4.7 Illegal Constant Pool Error

If the applets on your website do not start, but instead indicate an "Illegal Constant Pool" error in your browser's status bar, the problem is usually caused by when the uShop .class files are uploaded to the server in ASCII or TEXT mode - as opposed to BINARY mode. So try transferring ALL of the uShop .class files to your server again and be sure to select BINARY (or RAW) transfer mode.

4.8 Using the CODEBASE Parameter

The CODEBASE parameter can be used to help organize all of your store's .class files. We have added a page to our reference site that contains a complete description of using the CODEBASE parameter with uShop and organizing your store's pages in general. Check out "Managing The Class Files" at:

codebase.html

4.9 String Index Out Of Bounds Error

If you are getting a "String Index Out Of Bounds Error" that is preventing an applet from starting, the problem is usually caused by one or more of the applet's parameters not being in the correct format. Check the uShop Applet Reference and make sure that each of the applet's parameters are in the expected format. If the applet that is not starting is an order applet, then 99% of the time the "String Index Out Of Bounds Error" is caused by an extra semicolon at the end of the shipping parameter... so double-check that.