The last post about PHP form handling (forms with php) focused on the basics - the HTML syntax and simple PHP necessary for an operating form. There were several pieces that I glossed over in the explanation for the setup of that form that I want to go over in more detail now. You can create a form using many different techniques... but some practices are better than others.
Use Standard Elements
First, if you don't provide graceful degradation, there's a good chance that your tweaks may make your form unusable by more basic browsers and systems (like screen readers!). Second, users are used to certain standards within their browser. If an element looks like a form input, they know to click and type within the box. However, if you make it appear to have cool rounded corners or heavily modify the behavior, a user may become confused and leave the form behind.
Use 'post' Over 'get'
One of the optional attributes of the form element is the 'method' setting, which can have either a 'get' or 'post' value. By setting this to get, all of your form parameters will be passed through the URL address. Unless you're interested in unique URLs for SEO, this is probably not the best way to handle forms. There are character limits for the URL string (varying by browser) that may cut off some of the form input. Also, someone could re-submit the form just by visiting a specific URL with parameters passed in. If you use 'post' for your forms, than you keep your parameters relatively secure, URLs clean, and form data intact.
Keep the Form Submission on the Same URL
The 'action' attribute of the form element is a required field. This defines where the form values are sent after the 'submit' button is pressed. It is common for web developers to send this information to a separate script on their server, which validates and processes the form values. However, if a field does not pass validation, the error will than show up on a separate page and force the user to go back to the form page to try again. It is much better to show the error right next to the form, or having the form processing happen under the same URL that the original form existed on. By keeping the 'action' attribute blank, the form values is sent to the same page that the form is on, keeping all of your form logic under a single script and giving the user a better form experience.
Check 'submit' Element Before Other Form Elements
A good thing to check for first with a validation script (especially if the validation is occuring on the same page as your form) is if the form was actually submitted or just accessed by the correct URL address. You could check individual fields from the form, but they may not have been filled out. The best way to check to see if a form has been submitted is via the 'submit' button, which also has a name and value defined in the HTML. This also gives you the option to have separate submit buttons with different values, which could pass to different processing options in your script.
Validate Everything Several Times Over, Consistently
There are many ways to perform validation checks depending on the expected values from your form (preg_match, php validation filters, is_numeric, etc). It's important to be thorough during this process, especially when checking to make sure that a value was passed in from the front-end. The values '0', 'false', and '' could all return false if you check if($_POST['name'])... Which is why you need to check if isset(), strlen() (if needed), followed by an actual validation check. Think of the potential return values of both the form element and how your statements may convert it to a boolean during the processing stage.
If you're using ajax validation, it's a good idea to utilize the same checks for both the ajax checks and php submission (even if you have ajax form submission). Don't rely on the ajax 100% to catch all potential issues, and don't confuse your users by setting two separate standards with the ajax and php validations.
There are other best practices to keep your eyes out for, but these are some good starter ones. In my next post I'll be introducing the form logic I use with my MVC, with plenty of OO goodness to boot.