<?
$message = "";
$emailclass = "basictext";
$username = "";
if ($_POST['process'] == 1) {
$pattern = '/.*@.*\..*/';
$email = $_POST['email'];
$urlname = urlencode($$_POST['username']);
if (preg_match($pattern, $_POST['email']) > 0) {
// Here's where you would store
// the data in a database...
header(
"location: thankyou.php?&username=$urlname");
}
$message = "Please enter a valid email address.";
$username = $_POST['name'];
$emailclass = "errortext";
}
?>
<html>
<style>
.basictext {
font-family: Arial, Helvetica, sans-serif;
font-size: 14px; color:#000066;
}
.errortext {
font-family: Arial, Helvetica, sans-serif;
font-size: 14px; color:#C00000; font-weight: bold;
}
</style>
<body>
<form action="email.php" method="post">
<? if ($message != "") {
print '<span class="errortext">'.
$message."<span><br>\n";
}
?>
<span class="<?print $emailclass; ?>">
Email address:</span>
<input name="email" type="text"
class="<? print $emailclass; ?>"><br>
<span class="basictext">Your name:</span>
<input name="name" type="text" class="basictext"
value="<?print $username; ?>"><br>
<input type="hidden" name="process" value="1">
<input type="submit" name="Button1" value="Sign up!">
</form>
</body></html>
How it Works
The first section is the processing section. Notice the trick: if the $_POST array contains a key called Process with a value of 1, then begin processing; otherwise, just continue on. In other words, the first time the user opens the page, processing will not take place. You can see farther down that the form includes a hidden field called process with the value 1. Thus, when the user clicks the submit button, the page will load again, but this time processing will take place. Voila! The problem of the chicken and egg has been solved!
(Note, however, that the purists might balk at the fact that I'm playing on a feature in PHP: ff the $_POST['process'] variable doesn't exist, as is the case the first time the page loads, PHP still lets me test it against the value of 1; I'll simply get back a false. If this bothers you, you can add an isset call to first check whether $_POST['process'] even exists.)
The processing here is simple. I threw together a simple regular expression to check for an email address. (However, please don't use this regular expression in your own production code, as it's not foolproof; for a better one, check out the PHP Cookbook.) If the email address matches the regular expression, then all is fine and I issue a redirect to the next page, called thankyou.php. If the address doesn't survive the regular expression test, then I stay on the page and store a value in the $message variable.
Next, notice how I play with the styles: I have two styles defined inside of the <head> tag. One is for the basic text, a basic dark blue. The other is for bold red text used with errors to attract attention to the problem. In the PHP code, I store the basic text-style name inside of the $emailclass variable. If the code encounters an invalid email address, it changes the value of $emailclass to errortext. Then, when I create the label for the email address and the text box for the email address, I use the class stored in $emailclass, like so:
class="<?print $emailclass; ?>">
Thus, when all is fine, the HTML displays regular text. When there's a problem, it displays bold red text.
Notice also that I store some defaults in the fields. Initially, $username holds an empty string. On the return trip through the file, if the validation fails, I put the $_POST['name'] value back into the $username variable. (Remember, and this is important: on the return trip through the file, you are running the program as if it's brand new. Any variables you set the previous time are no longer present, unless you use a session variable; see Session handling functions for more information.) Later down in the code, I stuff the $username value into the form, like so:
<input name="name" type="text" class="basictext" value="<?print $username; ?>"><br>
Thus, if the user enters an improper email address, when the form returns, it will have the username already filled in. This technique is extremely important for user-friendly forms, because if the user forgets an @ sign in the email address (or the AOL users just type a screen name without @aol.com), he or she doesn't want to have to retype everything else into the form. This way, the form will return already populated with everything the user already typed in. In this case, I also decided to fill in the email address box with what the user previously typed, just so he or she can see the incorrect value and fix it.
The final thing to show you about this code is how I pass the value of the username on to the next page. Notice first that the form uses a POST method. Whenever you're sending out passwords, you want to use a POST method, since a GET method will show the password in the URL (and in the history file). People wouldn't be too happy about that if somebody is glancing over their shoulders. Of course, I'm not using a password in this example, but you might be in your own project; thus, I used the POST method as a demonstration.
However, the next page (in this case, thankyou.php) might well need access to the data that the user entered. The easiest way to pass it is through a GET, like so:
header("location: thankyou.php?&username=$urlname");
(I called urlencode so that the spaces and any other unusual characters will make it across.) Yes, I'm using a GET method, even though I just raved about the importance of using a POST method. However, I didn't pass the email address. The reason is that you would probably go ahead and store or process the username and password right inside of the processing code before calling header, rather than waiting until you get to the next page, in this case thankyou.php. Why now? Because you're already doing all the verifying; you might as well do the real processing, as well. For example, in a signup form, you might need to test whether the chosen username already exists; if it does, then you'll issue a message to the user that the username exists and to try a different one. If all is fine, you could go ahead and store the information in the database, before proceeding to the thankyou.php page. (It's possible, then, that you won't have to pass anything at all to the thankyou.php page, and therefore won't even need the ?&username= portion of the URL in the header call.)
More Possibilities
Here are some things that you could do with this technique:
• Have the user enter an email address twice. In the processing, check if the two match, and if not, print a message stating that they don't match.
• When a user signs up for a new account, test the chosen username and password against the database. If the username already exists, start a loop where you add on some random numbers to the username until you locate one that doesn't already exist in the database, and then suggest this username to the user.
• Check if the user left any required fields blank. Add a message along the lines of, "Please fill in the missing fields," and note the missing fields with red labels, being sure to fill in the other fields with whatever the user previously typed in.
• Make sure the password's length is within the required size. If it's less than eight characters, for example, put a message stating that the password must be at least eight characters.
You can even get fancier. When a user logs out, you could send the user back to a login.php page, with an added message saying, "You have been logged out. Use this form if you wish to log back in." How would you do that? After logging the user out, redirect the user back to the login.php page, passing a unique value (such as 2) in with the URL, as in login.php?process=2. Then add an if block to the login.php page checking the $_GET['process'] for the value 2. If the comparison succeeds, set the message appropriately. That way, you don't need a separate login page just for the extra message. (You are free to mix $_GET and $_POST all within the same page. PHP handles it just fine.)
Conclusion
Using this technique, you can easily create some sophisticated web sites that don't require a lot of duplicate code and unnecessary processing, all while sticking to our beloved PHP without having to touch either JavaScript or ASP.
No comments:
Post a Comment