Leaderboard

until you get your code to work for one form field, there's no good point in writing out php code and html markup for all the form fields, that you will need to make multiple changes to before getting it to the point of working. pick one field, such as the visitor's last name (most people have two names and your form and database table needs two fields, so that you can distinguish between the first and last name, for example is someone Martin Ross or Ross Martin.) in the php code, there's actually only one line worth keeping, e.g. checking if a post method form was submitted. you should - have any error related settings in the php.ini on your system so that ALL php detected errors will get reported. the initial php syntax errors present will prevent your code from running at all, so any error related settings in your code won't take effect. use 'require' for things your code must have for it to work and include/require are not functions. the () around the filename are unnecessary clutter. keep the form data as a set, in a php array variable, then operate on elements in this array variable throughout the rest of the code, i.e. don't copy variables to other variables for nothing. this is just a waste of your time typing. as has already been mentioned, use $_POST for the post input data. you also have a mistake in the syntax for $REQUEST (there's an under-score after the $, which is another good reason to get your code to fully work for one form field, before worrying about all the code needed for the rest of the fields.) trim all the input data, mainly so that you can detect if it consists of all white-space characters, before validating it. after you do item #3 on this list, you can trim all the data at once using a single line of php code. validate all the input data before using it, storing user/validation errors in an array, using the field name as the array index. after the end of all the validation logic, if there are no errors (the array will be empty), use the submitted form data. you should switch to the much simpler and more modern PDO database extension, especially since you will be converting this query to be a prepared query in order to prevent any sql special characters in the values from being able to break the sql query syntax, which is how sql injection is accomplished. you should use exceptions for database statement errors and in most cases simply let php catch and handle any database exception. the exception to this rule is when inserting/updating duplicate or out of range user submitted values. in this case, you code should catch the exception, test if the error number is for something that your code is designed to handle, such as a duplicate index error for fields that must be unique, e.g. the email field, and setup a message telling the visitor exactly what was wrong with the data that they submitted. for all other error numbers, just rethrow the exception and let php handle it. list out the columns you are providing values for in the insert query. this will let you eliminate things like the id column, which the value you are currently attempting to provide doesn't exist, e.g. there's no id field in the form and any php code referencing it will be producing php errors. if you were putting values directly into the sql query statement (you won't be when using a prepared query), you would need to put single-quotes around any literal string values, so that they don't produce sql errors about non-existent columns named the same as the data values. not sure why you are applying nl2br() to a value that doesn't have any new-line characters in it. after the end of all the post method form processing logic, if there are no errors, you would preform a redirect to the exact same url of the current page to cause a get request for that page. any redirect needs an exit/die statement after it to stop php code execution. to display a one-time success message, store it in a session variable, then test, display, and clear the session variable at the appropriate location in the html document. if at item #7 or #13 on this list, there are errors, your code will continue on to redisplay the html document, display any user/validation errors, redisplay the form, repopulating the form field values/selections with the existing values, so that the user doesn't need to keep re-entering data over and over when there are errors. any external, unknown, dynamic value that you output in a html context should have htmlentities() applied to it when it is being output, to help prevent cross site scripting. there's no good point in closing database connections since php will automatically destroy everything that was created on a page when your script ends.