Chapter 8: Processing Input

Form handling basics

One way or another, you'll be using a script to process the inputs (name, email, etc.) from your form. It's very important to understand the different ways of doing this. In the last chapter, you saw a form that called "ad_proc.php" as the action of the form. This would be a PHP script that was a separate file from the HTML page.

On many sites, forms are handled by calling a CGI/Perl script. That script would filter and process inputs. Then it would add a subscriber, process an order to buy something, send an email or perform any number of other tasks. Then it would display something to the user to show that it had done its job - a "thankyou page", etc.

PHP scripts can do all that - provided the script contains all the code necessary to do all those little tasks. In particular, it must be able to either produce visible output on the screen. It might load a static web page (a "thankyou" page, for example) or it might produce a customized page. The point is that it cannot feed anything back to the .html or .htm page that called it. That's because web pages with the .html or .htm extension don't process any PHP code.

PHP web pages (those with the .php extension), on the other hand, can process both HTML and PHP code. This allows a lot of power and flexibility that you didn't have before. By putting blocks of HTML code into variables and using some "logic" written in PHP, you can do it all on one page.

Why is that important? Simply put - you can put your form (coded in HTML) and your form-handler (coded in PHP) together in one file. The file can call itself as the action of the form. Then it's able to display some or all of the original page - under software control. You can display the page exactly as before but with error messages to help the user complete the form.

You can also display the page without the form, perform whatever actions are expected and display the results to the user - all on the same page.

Checking for missing entries

First, you extract the values from the query string. Then you check them for validity, filter them and use them in some meaningful way. You don't have to ask for them. They are simply there whenever you need them. Once the items are local variables in your script, you can do whatever you like with them.

Now ... did you get values in all the required fields? It's easy to tell. You just compare each value to an empty string like this:

if ($fname == "") { $fail .= "Please enter your first name<br>"; }

Here I'm checking to see if the user entered anything in the field fname (where I want them to type their first name.) If $fname is empty, the if-statement is TRUE and the failure message for this error is saved in $fail. I've added a <br> tag to the end of the error message in case there are other errors.

I'll be displaying them on a web page and I don't want them to all just run together. A new web page containing the items that were entered plus the error message(s) will be displayed. The user can just continue filling in the form without having to start over. Users like that a lot.

Did you notice the operator I used to copy the failure message into the variable $fail? It's not the usual "=" operator; it's ".=". What it does is add the string on the right-hand side to whatever is already stored in $fail. Why did I do that? That's a good question. The answer is that it's impossible to know which errors the user will make.

You can't predict which error messages will be produced or which one will be generated first. This way you'll get them all regardless of which error is found first. Every error message will have a <br> tag after it. Each error will be on a separate line on the web page so they are easy to read. The user can tell at a glance how many errors remain to be fixed.

Validating the entries

Now we've got some required data items and possibly some optional items. But are they valid, reasonable and safe? Maybe they are and maybe they aren't. Let's see what we can do about that.

Since I'll be using the ereg() and eregi() functions a lot - I'd better explain them now. They are used to compare strings to see whether have anything that matches.

ereg("pattern", "string") returns 1 (TRUE) if "pattern" occurs in "string". The pattern might be something like "abc" and if those letters occur in that order anywhere in "string", ereg() will return a 1. If not, it returns a 0 (FALSE). There's an optional argument that will contain the number of matches that were found but you very seldom need that.

eregi("pattern", "string") does exactly the same thing but there is a small difference in how it works. It's not case-sensitive but ereg() is case-sensitive. So eregi() will see a match between "dog" and "Dogcatcher" but ereg() won't see a match between "dog" and "Dogcatcher".

Copyright © 2004 Steve Humphrey