Sometimes a little additional troubleshooting is necessary to get the program up and running. If you are not familiar with FTP, File permissions, CGI or Unix, read the section entitled Web Essentials elsewhere in this document.
This is the most common problem that occurs with CGI scripts. It means the program crashed somewhere for some reason. 95% of our support questions are answered in the next several paragraphs. Start with (1.) and work your way down.
The first line of every Perl script (sometimes affectionately called the “shebang” line) must contain a pound sign (“#”), followed by an exclamation point (“!”), followed by the path to the Perl interpreter on the server. If there is ANYTHING before this line, or if the path is incorrect, the program will bomb. Your Web host can give you the correct path to Perl, however most systems will work with either of these two paths:
In some cases you must specify a particular version of perl in the shebang line.
This is unusual, but has been necessary for some installations.
All of the perl scripts must be executable by the webserver. This might be 755 or 711, depending on your server configuration.
The data directory (and all other web directories) should be searchable and writable by the webserver. This might be 777 or 755, depending on the server configuration.
The data files should be writable by the webserver. This could be 666, 644 or 600, depeding on the server configuration.
The output files should be writable by the webserver. This could be 666, 644 or 600, depeding on the server configuration.
All of the other files should be read-only. This could be 644 or 600, depending on the server configuration.
Finally, some servers WILL NOT EXECUTE scripts if the directory permission is higher than 755. Make sure the surfshop directory is set to 755 and try again.
Moving files across platforms will sometimes result in newlines being converted into newline-carriage return. Often this confuses the FTP program into thinking the file is a “binary” file, and the incorrect line endings get transferred to the web server. This will almost always cause the script to fail.
Try opening the script in a different text editor and re-saving it to your hard drive before FTPing it using the ASCII method.
Some editors add extraneous characters that will cause the script to crash. Whatever you do, DON'T use Word, WordPerfect, or any other 'word processing' program. You should only use a basic text editor like WordPad, Pico, SimpleText, or the like to work with any kind of program script. We suggest using a Developers Editor like BBEdit or CodeWarrior, both of whom have powerful search and replace features.
Try uploading the files to your server again, this time making sure you use the ASCII Text method for all scripts and HTML files. Most FTP programs will automatically convert the line endings to UNIX format.
Autoconfig.cgi attempts to detect the system variables, but you may need to modify them. Your Web host should be able to provide you with the correct file paths. Make sure that you have included or omitted slashes where required. Refer to the “Installation” section for specific details.
If you are using a secure server, make sure that the “Secure URL” setting does not contain the
http:/ prefix or any trailing slashes. The “Path to Document Root” path is sometimes the culprit. Do not assume that the default path that SurfShop generates is correct! Try entering a single forward slash (“/”) for this setting.
SurfShop automatically checks the origin of any request to complete an order against the list of “valid” cardservice (Payment processing) providers. There are two possible causes of this error:
We strongly recommend using SSL with Surf Shop. Not doing so is a potential security risk and liability for your business. See Security.
One or more of the URL settings is incorrect. Run autoconfig.cgi and make sure you have entered all of the URL fields correctly. If you have set a password, delete the “.p” and “.l” files that were installed by autoconfig.cgi and start over.
ssdata/1/data/.private/.p ssdata/1/data/.private/.l ssdata/1/data/.private/.auth ssdata/1/data/.private/.htpasswd ssdata/1/data/.private/.htaccess
Because of the countless variations of server configurations out there, it is necessary to specify all four of the following: Non-secure path to SurfShop™, Secure Path to SurfShop™, Non-secure path to the Document Root, and the Secure path to the Document Root. If you are installing SurfShop™ on a secure server ONLY, leave the “Non-secure” settings BLANK.
In order for SurfShop™ to function, autoconfig.cgi must write a file called “.datadir.dat” in the surfshop directory. A few servers do not allow cgi scripts to create files in the cgi-directory. If yours doesn't, try uploading a blank text file named “.datadir.dat” to the surfshop directory, setting its permission to read/write (666), and running autoconfig.cgi again.
This occurs when the browser receives a valid header, but does not receive any other information from the server.
Make sure that the following lines contain values:
Often is caused when SurfShop tries to create a page from a template or file that is empty or does not exist, or is not where SurfShop thinks it is. Check that all the files are installed correctly.
Sometimes this is caused when a server is maxed out on memory or requests.
This is either because the “mail program” setting is incorrect in autoconfig.cgi, or the mail template used to generate the mail message is incorrect.
1. Double check the path to your server's mail program. The most common paths are:
/usr/lib/sendmail - or - /usr/sbin/sendmail
Some servers are run qmail instead of sendmail, which will have the following path:
2. The default mail templates may have inconsistent line endings causing the mail to be formatted incorrectly. Using the “Edit Email Messages” admin, make sure all the fields have values and submit the form to rewrite them.
To: <! Ecom_BillTo_Online_Email> This is the recipient of the message From: <! YourMail> This is the "reply-to" address Subject: Your Order This is the subject line. Body: Thank you .... [etc.] This is the body of the message.
This is SurfShop™'s standard error message. If you see this message, then you know the program is working, however one or more of the configuration settings is incorrect. Review the instructions for correct installation of SurfShop™ .
Either your permission settings are incorrect or the data directory has not been installed correctly. Review the instructions for correct installation of SurfShop™ .
This means either the files are not where they are supposed to be, the file paths are incorrect, or the permissions are incorrect. If your server configuration is different than the SurfShop™ defaults, you may need to manually set the
<form> tags in the sample.html page and/or your catalog pages to make the program work.
SurfShop™ is set up to detect if anyone is trying to send it data from somewhere other than your host computer. If you are getting this error with legitimate CGI calls, then check the “domain,” “card service URL,” and “secure URL” settings in autoconfig.cgi for accuracy.
Microsoft Internet Explorer will not pass the referring URL from a SSL-enabled site to a non-secure site. This will cause the script to generate this error when returning from a payment processor. The work around is to remove the referring url from the “Cardservice Domain” global setting field. The referrer check is bypassed when this field is empty.
First, make sure the image in question is where you think it is. Most of the time the URL in the web page is incorrect. If you know it is correct, try making your URL's relative to the “root” rather than the “document,” that is, place a forward slash before the path to the image:
SurfShop™ uses a special place holder,
<! imageurl>, to generate a URL which will change for secure and non secure protocol. Try using this instead of a hard wired address in your HTML code:
<img src="<! imageurl>/images/thispicture.gif">
SurfShop™ was designed for shared hosting configurations that allow access to both secure and insecure web directories from a single server. To utilize a separate secure server, you will need to modify all of the html templates as well as the catalog pages that call the program:
Non-secure path to SurfShop directory: Secure Path to SurfShop Directory: secure.your-other-server.com/login/cgi-bin/surfshop Non-secure path to Document Root: Secure Path to Document Root: secure.your-other-server.com/login/
This is a common configuration for SSL. Your secure server may be able to access your data files because they reside on the same machine, but cannot run the same scripts because the secure and non-secure directories have not been “symlinked.” Many hosts set it up this way for security reasons. You can either:
Run autoconfig.cgi on the secure server and point the program to the ssdata directory you set up on the non-secure server. Complete the installation to make sure that there are no permission issues with the scripts under SSL.
This problem occurs most often when using SSL. If you are certain your scripts are executable (chmod 755), then it is caused by an incorrect configuration in your server's httpd.conf file. Contact your Web host and ask them to set up your directories with CGI execute permissions. Tell them that you are unable to run CGI scripts on your server and that you are receiving “method not allowed” errors.
This is the diagnostic message generated by the CGI::Carp module. IF YOU EVER RECEIVE THIS MESSAGE, CONTACT US IMMEDIATELY. It indicates a logic flow or system security problem with the script itself. We will work quickly to resolve any such errors and will deliver upgrades and patches free of charge.
If you forget your Administrator username or password, you will have to delete the password file and reconfigure the store using autoconfig.cgi