I have forgotten my login, lost my pass word for the admin section.
Don't despair. You have a few options.
1). This will get you back in by resetting your username and password. Download this file (if you cannot download it, create a file named adminpass1.file and enter the text you see when you click on the download link. The username and password are separated by a tab, not spaces). Then upload it to the following directory on your server :
where [scriptname] is the name of the script you purchased and [$FolderPass] is the variable you set (or was set for you) in either the _cfg.cgi or _key.cgi file. You should recognize the folder when you see it. In it, you will see a file named adminpass.file. It contains your username and encrypted password. View it, looking at the username may jog your memory. The password is encrypted so that won't be much help. If you still can't remember, upload the file named adminpass1.file so it's in the same directory as adminpass.file. Then rename it adminpass1.file to adminpass.file so that it overwrites the original adminpass.file. This renaming method is used because there are sometimes permission problems when you attempt to upload and overwrite in one action.
Once the file has been overwritten, your new username and password will be :
Username : 111111
Password : 111111
2). Your second option is to re-run the _setup.cgi your received when you purchased your scripts. If you still have a copy of it, upload it to your server in ASCII mode and then CHMOD it to 755. Load it in your browser and follow the prompts. The set up file will NOT overwrite any of your data files except of course the username and encrypted password file.
How do I transfer my scripts from one website server to another?
This is a common question raised as many of customers either move scripts to a new server, or transfer their website from one host to another. First we should let you know that we offer hosting that supports all of our scripts, guaranteed. www.linuxhostingplans.com While we don't have the lowest fees, we have the support you often need when it comes to hosting, and we guarantee our scripts will run, and we offer a Plesk Control panel on our dedicated servers with VERY stable connectivity.
There are two groups of files that need to be transferred, in some cases (Build a FAQ) three groups.
The CGI scripts. These must be transferred in ASCII mode to any CGI executable folder on the new server and then CHMOD (have their permissions set) to 755, as per a normal installation.
The data files. These are located in the /psjs_datalogs directory which is located at the root of your web space (your home directory or the directory your home page resides in). Inside the /psjs_datalogs folder, you will find one or more sub-folders. Each folder inside the /psjs_datalogs folder is dedicated to one of our scripts. These sub-folders are named using an acronym for the scripts, followed by the $FolderPass variable which is set in the _key.cgi file. For example, if you purchased Attachment Mailer Plus, you'll have a CGI file named amp_key.cgi. Inside amp_key.cgi you'll find a variable named $FolderPass.
$FolderPass = "1111222234";
So you'd have a folder inside the /psjs_datalogs folder named:
Transfer, in ASCII mode, the entire /psjs_datalogs folder and all of it's sub-folder and files to the new server. CHMOD all of these to 777 on the new server.
Ensure that the $FolderPass in the _key.cgi script on the new server matches the sub-folder name you transferred. If they do not match, you'll not be able to log in to the Admin section, as the scripts will not be able to find your data files which include your encrypted password for log in.
In most cases, that is all that's necessary. In some cases, especially with scripts that perform file uploads, you'll need to update the paths to your File upload directory (often defined in the Web Admin settings) so that they match the new server's path. You can ask your host for the correct path, or you could download and install E-Vars from our download page to try to determine the correct path.
If transferring Build a FAQ, you'll also need to transfer the folder you have defined as the folder to store your static FAQ pages. The default is /ourfaqs located in your home directory. This folder and it's contents should also be transferred in ASCII mode and CHMOD to 777 on the new server.
If transferring Upload Gold or Upload Pro, you need to transfer the File upload folder you have defined in the Web Admin settings. This folder and all of it's content should also be CHMOD to 777.
I need help. Often, you may be better off install a fresh copy of the scripts. If you need to retain the data files, and cannot complete the transfer successfully, you'll now need to Order installation. We'll do our best to install and retain all data, and of course only charge if successful. The standard installation fee applies for standard transfer and set ups. If you have a large amount of data which you require us to also transfer, additional fees will apply.
Why can't I upload files larger than XX Megabytes?
Our upload scripts have been circling and powering the Internet for well over 6 years. Our programmers coded the renowned PSUpload, a free ground-breaking Perl Upload Script, and continue to play a part in it's development even today.
For over 6 years, Customers whose servers do not permit unlimited data transfers, have written to us under the false impression that the problem lies within the Perl Script they purchased. For over 6 years, we've repeatedly written back to Customers insisting the problem lies with the Server and it's limitations imposed by the Host Provider. And we can honestly say, that when the Customer says something to the effect of "I can upload files smaller than XX MegaBytes, but cannot upload files larger than XX Megabytes", the problem has been with the server each and every time.
You'd think that after 6 years, we'd create a canned response. Well guess what? We have, and this is it. Here to enlighten not only you, but in some cases the Host Provider also.
You see, our scripts can theoretically transfer files larger than your hard drive, larger than your web server's hard drive and larger than the Internet itself. That's pretty large in anyone's book. Theoretically, as long as a connection between the client (the computer uploading the file) and the server (the computer receiving the file) is present, and the server's hard drive (or receiving folder) has the capacity to store the file, there is no limit to the size of the transfer unless you yourself specify one within the script.
The problem is in the server limits imposed by the Host Provider. These are limits consciously set on shared servers by your Host Provider to ensure one single process does not utilize all of the server's available resources, which would adversely effect all other websites hosted on the same server.
The three main reasons why a file upload or transfer would fail are :
1. Post Max limit
2. Uploads disabled
3. Timeout setting
1. Post Max Limit
All of our Upload scripts utilize the CGI Perl Module (CGI.pm). This can be found at CPAN
The CGI Perl Module is resident on all servers that have Perl installed. It enables the Host Provider to limit the number of bytes (the data) that can be Posted by any Form. It works by reading the total size of the data being transmitted by Forms using the Post Method including the size of any files selected. The Post Method is required for large data transfers, because the Get Method (the method of transmitting data in the URL) is often limited by Web Browsers to a size insufficient to transfer even a small image file such as a company logo. If the data size exceeds the defined value in the CGI Perl Module, the transfer will fail with the error message "413 Request entity too large" returned by the CGI Perl Module. However, according to the author of the CGI Perl Module "it isn't clear that any browser currently knows what to do with this status code".
You cannot change the CGI Perl Module's $POST_MAX variable unless you have root access to the server. The Module is installed in the Common Perl Library folder well above a website's web space, so the one copy can support all websites. If you do not have root access to the server, you must write to the Host Provider and ask that they check this, and if required, increase it also.
2. Uploads disabled
The CGI Perl Module can also flatly deny all file transfers. It will however process the Form's other fields as normal. As with the Post Max Limit, unless you have root access to the server, you cannot alter this Setting.
3. Timeout setting
Each server also has a configuration file which enables the Host Provider to set a process Timeout. That is, each request made to the server, be it a request for a Web Page, a request for a file or a request for a server side script (such a Perl script capable of transmitting multipart form data or file uploads), can be limited to XX seconds. The default Timeout setting is often 300 seconds. Unfortunately, this setting is also often left unchanged. In this case, if you're attempting to upload a file which would require a transit time greater than 300 seconds, the server would terminate the process prior to it's completion resulting in a "Server 500" error or a "This page cannot be displayed" error. This makes sense, because the server returned nothing back to the Browser for it to display. The communication between the client and the server side script was severed.
You cannot change the Timeout setting unless you have root access to the server. The Timeout setting is found in the server's configuration file which can reside anywhere on the server, but is often found in the /etc/httpd/conf folder in a file named httpd.conf
In summary, contact your host, as we cannot help you. Your host controls the server and what it's prepared to accept. Point your host to this page if you like, because often they will disregard your request for help for various reasons including the belief that the problem lies within the script. This is justifiable, as we've seen many shoddy scripts on the Internet written by novice programmers who often have good intentions, but lack the experience required to develop software for the open market.
What is a server timeout and how do I increase it?
Servers usually set a maximum time limit for the processing of cgi scripts. Karl Johnson of www.colorado-artist.com was kind enough to let us know that Earthlink, one of the largest ISPs in the US has their time out set to 5 minutes. To increase your server's time out, you must direct the request to your hosting provider. CGI scripts can not modify your server's configuration without root permissions.
Which text editors can I use to edit cgi files?
Use simple text editors such as Notepad or SimpleText. Do not use rich text editors such as Word as they will corrupt the cgi file, which is essentially a plain text file.
How do I update my existing copy of scripts that have been updated?
In most cases, and unless you have made custom modifications to the script, you will need to change one variable in the _cfg.cgi file. The variable is usually on line 34 (or if using the latest versions of our scripts you'll find it in the _key.cgi file) and looks like this :
$FolderPass = "jjkknew1qw";
You must make sure that the $FolderPass in the new script matches the $FolderPass in your original copy. This is so the data files can be found. This change will only be necessary if we send you the _cfg.cgi file as part of the update.
After making sure the $FolderPass variable matches, upload and overwrite your existing scripts. Then refresh your admin page and you're done.
If we sent you the _admin.cgi or [script].cgi scripts, without the _cfg.cgi scripts, you do not need to make any edits. Just upload and overwrite your existing files.
When I call Perl program from browser, the source code appears, why?
That is most likely because you do not have Perl installed. All Perl Scripts require Perl to be installed on the server. Without Perl, the script is just a text file.
Once I log in to a script, I'm taken back to the login page when I click on any other link. Why?
This could be one of two things. If you have a firwall set up, turn it off and see if you can then log in and move around. If you do not have a firewall, make sure you have session cookies enabled in your browser. Session cookies are automatically deleted when you close the window or when you log out. See next Question also.
Our scripts use session cookies to identify the user logged in and as a security measure to ensure the cookie set matches the password on record.
To enable session cookies in...
File - > Preferences -> Privacy
Edit -> Preferences -> Advanced
Edit -> Preferences -> ( Double click ) Privacy and Security -> Cookies
Internet Explorer 4
View - > Internet Options -> Advanced -> Cookies
Internet Explorer 5
Tools - > Internet Options -> Security -> Internet -> Custom Level -> Cookies
Internet Explorer 6
Tools - > Internet Options -> Privacy -> Advanced or Edit
How do I set my server to execute scripts in a directory other than the cgi-bin?
This siwll only work if your server has been set to allow the overriding of the main configuration settings.
You need to create a .htaccess file and place it in the directory you want to execute scripts in. Inside the .htaccess file enter the following two apache directives :
AddHandler cgi-script .cgi
Options Includes ExecCGI
If you already have a .htaccess file in the directory, edit it and place the two directives at the top. If the above fails to execute scripts in the directory, your server's httpd.conf file probably has something like this :
Deny from all
In this case, you'll need to either contact the server admin or modify your server's httpd.conf file if you have permission. It's usually located well above your web space in a directory called : /etc
When I load the admin section or any of the scripts I see the following : "Pragma: no-cache Content-type: text/html", why?
This is because your server is printing headers when it's actually the script's job to print headers. A problem usually occurring on Windows servers that have not been properly configured for the web. You'll need to contact your host and ask them to remove the headers. Until the problem is corrected by your host, you will not be able to log in because the cookie header must be printed (by the script) before the Content-type header. This is impossible if the server is printing headers.
You may see something like :
Set-Cookie: un=username; Set-Cookie: pass=OY6jdhGw7TM;
That is the script requesting two session cookies. Normally you would not see that because it's printed before the output stream is sent to the browser. However, when the server starts the output stream prematurely (with the Content-type header), it's too late to set cookies.