Home Uniquely NZ Travel Howto Pauline Small Firms Search
Howto Handle Form Output - Scripts

Introduction

The Howto Article on Forms covered the easy bit of producing the Form. The difficult bit is getting the Output from the Form to you. The best way for a personal user or small to medium sized firm running their site on somebody else's server is via an email. When the Form is Submitted (using the INPUT tag with TYPE attribute of SUBMIT) then the file at the URL specified in the FORM Tag by the ACTION attribute is run - this is normally a script file which determines whether it was a POST or a GET and suitably parses the associated data from the Form. In the old days this was most likely a CGI (Common Gateway Interface) script writen in PERL and was typically many hundreds of lines long and furthermore few ISPs would let you run such scripts on their machines in case they ran amok. When they did allow it the scripts were usually placed in a special directory ( /cgi/bin ) in a common area or on your site.

Options

Assuming you do not want to spend months developing a script in PERL what are the options. Firstly one has to find an ISP which will allow one to handle forms at all - most of the "free" ISPs do not allow one to run your own scripts for very good reasons and do not provide a common script for users. There are a couple of exceptions - Freezone (where www.pcurtis.com is hosted) has just provided a good and comprehensive script for forms (FormMail) in a common directory.

I have recently put FormMail onto a Clara.Net business server. Their business servers support PERL scripts in your own cgi-bin and they provide enough information to get you up and running - a quick look at their web site indicated they have a common copy of Formmail for their home users. These options for hosting will be discussed and compared more fully in a separate page so I will keep to Forms here.

Fasthosts are not free but are very flexible and you can do almost everything including PERL, ASP pages, Frontpage, Cold Fusion and iHTML. iHTML is so simple that you can write your own script to handle the form output and email it to yourself as easily as producing the Form in the first place - it just extends HTML with simple yet very powerful Tags. Please note that not all of the hosting solutions from Fasthosts allow scripts to be run - the basic version through UKReg does not allow scripts.

An Introduction to FormMail and derivatives

The examples here use Hypermart which is no longer free and only host business pages but it had a very large user community and very good support pages. I have left this section as a good introduction to FormMail and it was where I cut my teeth on forms. Users can run PERL scripts in their own cgi-bin and there is sufficient information for one to eventually work out how to do it. They also suggest the use of a freeware script called FormMail which is excellent and saves all the hard work. The original FormMail (version 1.6 or lower) however are wide open to hackers wishing to send spam mail and some ISPs insist you use more secure derivatives such as FormMail 2.14 from SourceForge which limits the email addresses it can send to. Check your ISP has a higher version than 1.9. The descriptions following cover both unless stated. They need very little configuration so you do not need to understand PERL and there is plenty of information on how to do the tiny bit of configuration needed for FormMail 2.14 on Hypermart. I use FormMail 2.14 for one of the sites I have set up on Hypermart and can not recommend it too much. The only catch is that FormMail only runs without modifications on Unix (and Linux) servers. An increasing number of ISPs now run various flavours of Microsoft Server such as the Internet Information Server (IIS) and I have not yet managed to make FormMail work under Windows although there is now an almost exact look-alike available using PHP which could be a good option.

FormMail 1.92 and 2.14 use a number of standard variables (Set up as HIDDEN inputs) for configuration for your own use. It can check that emails are valid formats and that important fields have been filled in before it will accept the Form and email it on - overall it allows a lot of configuration if required but will also do a good job with just the defaults. The only things you have to set up in the script file itself are the domains allowed to use it (to prevent everyone exploiting it on your web space), the location of the PERL compiler and the location of the Unix email program Sendmail on the server - everything else is by use of standard variables. FormMail 1.92 is available free in Matt's Script Archive at http://www.scriptarchive.com/formmail.html . In the case of the developed version 2.14 at SourceForge it is available at http://nms-cgi.sourceforge.net. We will now look at more details of how to use PERL and FormMail with Hypermart as the example

What is a cgi-bin ? Any Script file, even a well developed one such as FormMail is a program which you are running on the server - this could run amok and take the server down so often such programs in the past were often only allowed to be run from within a single directory in a carefully controlled manner. Programs put into this directory were very carefully tested and normal users would not be allowed to load programs unless they were very careful checked first. This directory was almost always called cgi-bin. Your server may contain scripts you are allowed to use in its main cgi-bin as is the case with Freeserve and Freezone. More recently the servers have allowed programs with extension .cgi to run in users directories so you may well find that if a PERL program (usually with extension .pe or .pl) is renamed to .cgi it can be run and that the server does sufficient runtime checking to avoid disasters - in the case of Hypermart the errors are trapped and you can even look at the error log.

Locations of PERL and Mail programs: I tried to get scripts to run on Hypermart and found that it was not as easy as all this would indicate and I had to spend a while going through all the support pages - the following notes will hopefully save you all that work. Firstly the script needs to know where PERL is located on your server - Hypermart seems to be fairly standard and has the latest PERL 5.003 located at /usr/local/bin/perl and for compatibility PERL 4 is also available at /usr/bin/perl - one of those two is usually a good bet. You also need to know where the mail program is located and in the case of Hypermart they tell you it is at /var/qmail/bin/qmail-inject . Many servers use SendMail rather than qmail-inject and I do not know where that would normally live.

Permissions and chmod : The next problem is that one has to set up permissions on the cgi-bin scripts so they can be read and executed by yourself and other parts of the system. This is done on a typical Unix server by a program called chmod and you find references to chmoding to 755 etc. This strange number seems to be an octal number and refers to setting the read, write and execute bits for yourself, your group and the world so 777 sets everything.755 allows everyone to execute the script but prohibits your group and the world from writing to your script - this is the normal setting for scripts. HTML documents and images are always set up for you but you do seem to have to set permissions for cgi scripts. Hypermart have utility on the site to do it otherwise WS_FTP can do it via a nice interface but only if you right click the file name you want to change - it does not appear on the menus. Take great care as you can remove your own permissions and then you can do nothing but get in touch with the web space provider and beg.

Uploading Perl scripts - use ASCII mode: After many hours and surfing round various FAQs etc I discovered that you must upload PERL scripts in ASCII mode, if you do it in Binary which is what I do with everything else they do not work and come back with error 503. I was also worried about editing the scripts but it seems that Microsoft Wordpad (present in all flavours of Windows) does no harm when editing text files and I could work on a .pe or .cgi file without problems provided I saved in Text format - I found it is best to make any copies and name changes before using Wordpad and then just using Save. Notepad has limitations on file size and is much more basic and even safer for small changes to scripts provided you can work with some strange line endings when the scripts were prepared on a Unix machine

PERL scripts for utilities and testing. I have spoken about scripts for FORMs but one does not want to use them for testing and I discovered various PERL utilities such as counters and time displays as well as the very important FormMail at Matt's Script Archive at http://www.worldwidemart.com/scripts/formmail.shtml I also did a short online tutorial at User Active at http://www.useractive.com where it takes you through the basics including uploading and running a simple CGI script in PERL. I saved that away for future tests. It looked much like HTML and the output was inserted into the HTML stream returned from the server to the browser.

Executing a PERL program as a SSI: A common way to run a PERL program is as a Server Side Include (SSI) which few of the free ISPs support but is supported on the Hypermart web space that I am using for this job and I did my first tests using simple PERL scripts run as SSIs. A typical way to do this is by having a statement like <!--#exec cgi="/cgi-bin/perltest.cgi"--> in your HTML page which asks the server to execute the cgi program perltest.cgi and puts it's output into the HTML stream sent to your browser when the page is accessed.

Forms and Secure Servers: If you intend to take sensitive information in your Form you should use a Secure Server which encrypts the details sent over the internet. Hypermart offer a Secure Server Interface for credit card etc transactions. It is very easy to use and one simply accesses the same pages you have uploaded but using the full address of https://serverxx.hypermart.net/yourname/yoursecurepage.htm instead of http://yourname.hypermart.net/yourpage.htm. They tell you when you register which server you are on. Relative addressing works after the first access but you should leave the secure area with a full http://...... URL after the transactions are complete as the secure area currently turns the banners off and you need a tidy return. Accessing a Secure Site requires that your browser has the matching Certificates to the server and that they are in date.

Example of FormMail on Hypermart. Once I had got to the point of getting cgi scripts to run it was simple to utilise all the various facilities in FormMail to check the Inputs and Format the email output as I wanted. The start of the Form I developed looks like this when running with the secure server.

<form ACTION="https://server25.hypermart.net/yourwebsite/cgi-bin/formmail.cgi" METHOD="POST">
<input type=hidden name="required" value="email,title,lastname,arrival,depdate,adults">
<input type="hidden" name="recipient" value="bookings@yourwebsite.co.uk,yourwebsite@freezone.co.uk">
<input type="hidden" name="redirect" value="https://server25.hypermart.net/yourwebsite/complete25.htm">
<INPUT TYPE="hidden" NAME="subject" VALUE="Booking Form for the Your Site">

This is all that is needed to run the script, check several variables are present and when everything is OK email the Form contents to two places with a title set in the email and then continue to a specified URL. For completeness the lines of my formmail.cgi from Source Forge which have been changed look like:

#!/usr/bin/perl -wT
$mailprog = '/var/qmail/bin/qmail-inject';
@referers = ('www.hypermart.net','server25.hypermart.net','yourwebsite.hypermart.net');
@allow_mail_to = ('bookings@yourwebsite.co.uk','yourwebsite@freezone.co.uk');

The @referers has a list of domains which can send the Form - this limits other people from accessing and using your cgi script.

The @allowmail has a list of email addresses to which the form can be sent - I understand that 'yourwebsite.co.uk' will allow any addresses to be allowed at the site.

I hope that the above is enough to save users of Hypermart a lot of time and convince people that one does not need to be frightened of Forms on a Unix server if one uses Shareware utilities such as FormMail.

Forms on Clara.Net - FormMail again

I have recently set up FormMail on a Clara.Net business server. They make it clear in their instructions that you upload your scripts to the cgi-bin directory which is already present in ASCII mode and CHMOD to 755 as for Hypermart. I edited a freshly downloaded copy of FormMail using notepad to change three lines as below:

#!/usr/bin/perl
$mailprog = '/usr/sbin/sendmail';
@referers = ('www.pcurtis.com','www.yourwebsite.co.uk');

The @referers has a list of domains which can send the Form - this limits other people from accessing and using your cgi script.

When correctly uploaded in Ascii and with permissions set using CHMOD 755 it all worked immediately both from a form on the same domain and from my domain which I had included in the @referers list.

I made contact with the Clara.Net business support whilst I was setting up the script and they were very quick to answer the telephone, helpful and knowledgeable. They even responded to an email. They clearly offer the sort of support that a small firm needs but very few firms deliver. I do not have their prices but it could well be worth paying a premium for such good support from Clara.Net.

Forms on Freezone - FormMail yet again

Freezone are commited to the business community as well as their free services and support PERL, cgi etc on their commercial sites. They will also support SSL on the commercial sites for an additional fee of about 19 per year for a shared secure area or 49 for an area on your own domain. For a period they provided a copy of Formmail in a common cgi-bin for the users on their free service and personal services. The personal services now provide a cgi-bin of their own and I am not sure if and where the script now resides but the following again shows how easy forms are if the FormMail script is available. I slightly modified their example and the complete code for the page using the common cgi-bin follows. You will see that it is very similar to the one for Hypermart as you would expect as they were both writen for FormMail version 1.6.

<html><head><title>Freezone Form Example</title></head><p>
<center><h2> This is an example of a form.</h2></center>
<form METHOD=POST ACTION="/cgi-bin/formmail.pl"><p>
<input TYPE=hidden name="recipient" value="admin@yourname.co.uk"><p>
<input type=hidden name="required" value="name, email"><p>
<input TYPE=hidden name="subject" value="Example web site form" ><p>
<input TYPE=hidden name="redirect" value="http://www.yourname.co.uk/form_response.htm" ><p>
Name:<br>
<input NAME="name" size=35><p>
Email address:<br>
<input NAME="email" size=35><p>
Phone Number:<br>
<input NAME="phone" size=35><p>
Comments:<br>
<textarea NAME="comments" ROWS="5" COLS="30"></textarea><p><br>
<input TYPE="submit" VALUE="Submit">
<input TYPE="reset" VALUE="Erase">
</form>
</body>
</html>

There are lot of configuration options which can be set by hidden variables when using FormMail. The above uses "required" which means the fields have to be filled in and, in the case of email, a valid address.

Forms on Fasthosts using iHTML

It took me tens of hours to understand enough of cgi and PERL to get my forms working on Hypermart despite all their excellent support files and the use of FormMail although the set up versions provided by Freezone and Freeserve were easy to use. I failed completely to get FormMail to work on the Microsoft IIS server used by Fasthosts despite finding various pages on the web telling one how to convert and use Blat (an equivalent on NT servers to Sendmail on a Unix server. Eventually I gave in and rang their support line to find out if they had any examples of use of Blat and instead they pointed me towards some examples of scripts on server sophie. They however strongly advised that I should look at iHTML (or ASP) rather than CGI. I was very glad I followed their advice and my first three attempts at trial scripts all worked first time - almost unknown to me after 30 years of programming! I was ready to start on the real Forms after perhaps three hours and they came together very quickly after that and enabled me to present a much better feedback to the user than I could before even and a much easier to read email than even with FormMail.

iHTML is very simple in the way it works on the server - it just extends HTML with simple yet very powerful Tags. When the Fasthosts server finds a page with a .ihtml end and a <!ihtml> Tag on the first line it is sent to the iHTML script processor. The iHTML tags are placed directly into regular HTML files to extend HTML to: access databases; perform math calculations; define IF/THEN constructs; LOOPS, Error handlers and more. This extension to HTML makes it more of a programming language than a simple script language. Combined with Java Script within the same page, some powerful combinations of server and client-side programming are possible. The iHTML grammar is interpreted at the web server and the iHTML tags are detected, and resolved into data. The iHTML tag resolution process is continued until the document contains only standard HTML tags so when the document arrives at the browser, it is HTML compliant. This eliminates the need for anything other than a normal browser to access the features of this extension to HTML (no plug-ins etc are needed) so all users will be able to access the full functionality of your Web pages. The place to go for information on iHTML is not surprisingly http://www.ihtml.com . If you go to http://www.ihtml.com/learning there are examples and a very useful Users Guide (Manual21.doc (2.3 Mbytes and 250 pages)) to download.

Forms processing with iHTML. We need very little of the power of iHTML to handle our forms. The iHTML page automatically identifies that it has been accessed by a post and sets up all the named variables sent to it. Any word on the iHTML page starting with a : is checked against the variable list and the value is substituted before sending on to the browser - that could not be easier. The only caution is that if a variable is not defined then the :xxxxxxx remains in the stream hence my define defaults of null strings in many INPUTs in the Form earlier (One can also check in the iHTML but I like a simple approach). We also need to email the results and that can be done using a single powerful Tag <iMail>> which takes a number of attributes (mostly optional) and sends everything between it and the closing </iMail> tag as an email.

Example of iHTML form processing. The example which follows shows the power of iHTML. The section of the source code here formats and displays the complete contents of a Form input and sends the same formatted information as an email with the REPLY address set to be the one provided on the Form ready for a Reply. It should be possible to cut and paste the code into an existing HTML page, add a <!ihtml> tag on the first line and rename it to be .ihtml and you should be away - the various variable names are mostly self explanatory and can be gradually added to the Form as you develop it.


My name is<b> :title :forename :initial :surname</b><br>
I am a<b> :visitor_type </b><br>
Please can you<b> :action    ( :Urgency )</b> <br>
My preferred response is by <b>:response</b><br>
My Email address is - <b> :email</b><br>
My Telephone is - <b> :telephone</b><br>
My Fax number is - <b> :fax</b><br>
My Mobile Number is - <b>:mobile</b><br>
My address is<br>
<b>:address0<br>
:address1<br>
:address2<br>
:town :county<br>
:postcode<p>
:input_type</b> follows:<br>
<b>:commentbox</b><p> Thanks<b> :forename :surname </font><p>

<iMAIL HOST="smtp.myfasthostsite.co.uk" FROM="website@myfasthostsite.co.uk"
TO="enquiry@myfasthostsite.co.uk" CC="sales@myfasthostsite.co.uk"
REPLYTO=":email" SUBJECT="ENQUIRY SENT TO MYFASTHOSTSITE.CO.UK">

My name is :title :forename :initial :surname
I am a :visitor_type
Please can you :action
This is :Urgency
My preferred response is by :response
My Email address is - :email
My Telephone is - :telephone
My Fax number is - :fax
My Mobile Number is - :mobile
My address is -
:address0
:address1
:address2
:town :county
:postcode
:input_type
:commentbox
Thanks :forename :surname

</iMAIL>

NOTE; There has been an important change since this page was first written and the mail handler address changed from mail.fasthosts.co.uk to smtp.fasthosts.co.uk - even this does not work on all the Fasthost servers and it is safer to use the user specific alternative of smtp.myfasthostssite.co.uk as above.

Checking the Email address is valid in iHTML Ideally the iHTML should check that the sender of a Form has given you a properly formulated email address before you use it in even as a reply address. I use a simple check that the address contains an @ followed by at least one dot. Suitable iHTML code follows:

<iEQ NAME="emailtemp1" VALUE=<iSTRKEEP src=":email" keep="@."> >
<iEQ NAME="emailtemp2" VALUE=<iSTRIN src=":emailtemp1" dst="@."> >
<iIF COND=":emailtemp2" >
<p>
<iELSE>
<font color="#ff0000">Warning: </font>The Email you submitted is not in a valid format - please use the Back Button on the Browser to return to the Form and complete the email address.<p>
</iIF>

You should be able to cut and paste the above into your forms and replace the bits in red with your own code. If you want to add your own checks I would advise developing them using simple tests with temporary variables which you display at each stage. The iSTRKEEP tag only keeps the characters in the dst="@." - the iSTRIN tag looks for @. in the resulting string and returns 0 (False) or the position it was found (True) for the if, then, else.

Further Form Validation

It is best to do the checks before the form is sent using JavaScript which is the subject of Form Validation - which covers how to validate the important fields to check they filled in and that an email address is valid, before the the form is submited.

 

Form scripts using PHP - Freezone and Fasthosts

PHP was not readily available on servers when I first wrote this page but now virtually every paid for ISP offers PHP version 4.2 or higher. It is as easy or easier to use than iHTML which I fear may be phased out eventually at Fasthosts. I was tempted to cut and past the words about how easy iHTML was here as they are very similar although PHP is probably even more powerful. I quickly started converting my scripts from iHTML to PHP.

PHP files, not surprisingly must have extension .php to be recognised and parsed. To find out if PHP is on your server and get lots of useful information create and upload a file called phpinfo.php containing the single line

    <?php phpinfo() ?>
and then enter your.web.site/phpinfo.php in the browser - that will probably be the simplest script program you will ever write and you will use it often for useful information! Another one liner sent me a trial email message.

PHP is very simple to get to grips with. Typing is very weak and you can drop in and out of PHP as often as you like. There are lots of useful functions with meaningful names. Perhaps the only thing to note is that Strings can be enclosed in "  " or '   ' quotes but variables which always start with a $ are handled differently in the case of " " the enclosed variables are recognised and substituted whilst with ' ' this does not occur. Try this simple program - put in a file called strexample.php and upload it to your site. It will not work locally as PHP is server side scripting and runs on your web server to deliver an HTML page to the browser so it is a good job it is so easy!


<?php
$example = "Hello World";
echo " $example "; // gives Hello World
echo ' $example'; // gives $example
?> 

The following is the 'guts' of the new code for my feedback form for PHP which can be dropped into the body of an HTML page. It is well commented and the PHP functions are mostly self explanatory from their names. You can look them up at uk.php.net - only a dozen or so functions and environment variables are used here which demonstrated the power of PHP. If you forget all error checking and security I think you could do a form to email in a single line!


<?php
/* The following code can be added to reduce the chances of the script 
being cached by generating raw HTTP headers and must be before any HTML at the top of the file even before the <!DOCTYPE declaration to work /*

header("Cache-Control: no-cache, must-revalidate"); // HTTP 1.1
header("Expires: Mon, 26 Jul 1997 05:00:00 GMT"); // Date in the past
header("Pragma: no-cache"); // HTTP 1.0
?>


<?php
/* This script carries out some error checking to make avoid
being used as a spam relay however the main checking of the 
parameters should be done by JavaScript before the form is 
submited as there is no provision to correct errors. 

It first strips out invalid characterts from the form input to 
prevent hacking. It then checks that the script has not 
been called directly and checks it is called from a permitted 
domain. For security all of these are 'hard wired' into the script.
*/


/* Strip out invalid characterts from the email input to prevent hacking.
You will have to add the actual parameters you use. */

$email=htmlspecialchars($_POST['email']);
$commentbox=$_POST['commentbox'];
$feedback_page=$_POST['feedback_page'];

echo "<center><h3>Form from $email on $feedback_page</h3></center>";

/* Set up for domain checks */

$domain1 = 'yourdomain';
$domain2 = 'yourseconddomain';
$referrer=strtolower($_SERVER["HTTP_REFERER"]);
$pos1 = strpos($referrer, $domain1);
$pos2 = strpos($referrer, $domain2);

/* Check that the script has not been called directly */
if (!isset($_POST['email'])) {
	echo "<p>Error - possibly called directly 
rather than from a web page</p>\n";
	}
/* Now check it is called from a permitted domain */
	elseif (($pos1 === false) && ($pos2 === false) ) {
    echo "Not called from a valid domain</p>\n";
	}
/* Then check required parameters are set */
	elseif (empty($email) || empty($commentbox)) {
    echo "<p>Required parameters were not completed 
- please use back button and try again</p>\n";
	}
/* and finally check email address is reasonable ie do we have 
alphanumeric characters + an @ sign + a . + 2 to 4 alpha characters. 
Thanks to tim at rocketry dot org for this code */
	elseif(!eregi("^[[:alnum:]][a-z0-9_.-]*@[a-z0-9.-]+\.[a-z]{2,4}$", $email))
 { 
    echo "<p>$email - This is not a reasonable email address 
- please use back button and try again</p>\n";
	}
	else {

/* Success - write what you are sending to the page then send out the email */

/* This code first converts the string to HTML characters then changes
various forms of line end to the hTML break tag to avoid a spagetti
output from the form input. It processes \r\n's first so they
aren't converted twice. It then compacts multiple breaks. 
Additional backslashes are removed */

	$str = str_replace( array("\r\n","\n","\r"),'<br>',htmlspecialchars($commentbox));

	for( $i = 5 ; $i >=0 ; $i -= 1 ) {
	$str = str_replace( array("  <br>","<br>  <br>","<br> <br>","<br><br>"),'<br>' , $str);
	}
	$str = stripslashes($str);
		
/* Write to the page */

	echo "An email with your input has been sent with: <p>";
	echo "<b>SUBJECT:</b> Form from $email on $feedback_page<br>";
	echo "<b>REPLY-TO:</b> $email<br>"; 
	echo "<b>CONTENT:</b> $str<br>"; 

/* Finally send the emails using mail() Note that a few servers 
are not complient to the appropriate standard (Windows ones of course)
and may require a \n only rather than a \r\n (CRLF) as separators */

	mail("you@yourdomain","Form from " . $email . "on" . $feedback_page , $commentbox , 
"From: website@yourdomain\r\nReply-To: " . $email . "\r\nX-Mailer: PHP/" . phpversion() ); 
	}

/* Please acknowledge that this is based on a PHP Script
 provided by Peter Curtis at www.pcurtis.com */
?>

The following code can be added to the page to reduce the chances of the script being cached. It works by generating raw HTTP headers and must be before any HTML at the top of the file even before the <!DOCTYPE declaration. For some reason do not have any comments in it or you may lose output!

<?php
header("Cache-Control: no-cache, must-revalidate"); // HTTP 1.1
header("Expires: Mon, 26 Jul 1997 05:00:00 GMT"); // Date in the past
header("Pragma: no-cache"); // HTTP 1.0
?>

PHP Email Scripts on Freezone and Fasthosts Servers

There are few restrictions that I have found when this is used on Freezone Servers and everything worked almost immediately - I have not found limitations on the addresses available hence all the care I have taken to reduce the chances of highjacking for spam.

A number of additional local checks are done by Fasthosts to prevent spamming. The To or From addresses should be on a Fasthosts domain and on the Windows servers an extra line to set the From address is required before mail() is called ie.

	ini_set("sendmail_from", " email@yourfasthostdomain ");
	mail("address@yourfasthostdomain","Form from " . $email  ,  $message , "From: email@
yourfasthostdomain\nReply-To: " . $email . "\nX-Mailer: PHP/" . phpversion() ); 

Form to File Scripts

The alternative to sending the output of a form as an email is to put it into a file on a protected area of ones web site to download later, having perhaps notified oneself by sending an email. With PHP, Secure (SSL) web space and password protected private folders becoming more readily available this is an option when forms contain confidential information. Freezone's Plesk servers offer private password protected folders as standard on all the package I use and I have been experimenting with PHP scripts to write files. It is not to a point of providing scripts here but I have found that it is easy in PHP to read .htm files and one can write and append to files almost as easily - including those in the password protected areas - provided that they already exist and that the permissions have been set to read and write for the owner group and other in advance. This can be done using the Freezone Plesk control panel's file manager or ones FTP package if it has the facility (In WS_FTP LE right click on a remote file to get to CHMOD (unix only)).

As far as I can tell one can not create new files or change permissions from a PHP script on the Freezone Plesk servers - a reasonable and sensible restriction on the grounds of security but one which does limit one to 'log' type files. I have not experimented on the Fasthosts servers as I do not have the password protected folders on them to make it worthwhile.

The functions to look up on PHP.net to start you off are fopen(), fread(), fwrite() feof(), fclose() and the test functions file_exists() and is_writable(). NOTE file_get_contents() is only available on PHP 4.3 or higher and file_put_contents() is only on PHP 5.0 and higher. Freezone uses PHP 4.3.11 and Fasthosts PHP 4.3.2. PHP.net not only has a very full description of every function but there are also feedback areas under each one and one will find lots of code and discussion.

Conclusions

It is very important to use an ISP to host your site who provides an easy way to handle Forms. I have managed to use Forms on Freeserve, Hypermart, Freezone and Fasthosts but it took a lot of time to get to grips with those where one had to write or load ones own scripts despite the support provided. The hints above will ease things considerably on Hypermart and Fasthosts should be easy once you know to use iHTML. Freezone should not present many problems and Formmail can be very powerful and is easy to use - I was already well up the learning curve have used FormMail on Hypermart and my test Form worked first time. The way ahead is definitely to use PHP and I will progressively convert all my and my customers forms from use of FormMail and iHTML to PHP on Freezone and Fasthosts servers. From starting to investigate PHP to having done conversions on all my own form scripts including tests etc took a little over a day although I have spent more time tightening the security as I converted my customers.

If you use any other host for your site you need to be very sure to check what support is given - some say they provide a number of ready to run scripts in a cgi-bin but make sure they include a good handler for forms such as FormMail and preferably support for PHP. You do not want to get involved in cgi scripts and PERL from basics unless you are already an experienced programmer - iHTML and PHP are so like HTML that it should not be the same problem.

Link to W3C HTML5 Validator Copyright © Peter & Pauline Curtis
Content revised: 8th July, 2020