There are two most notable ways of inserting a row into a MySQL database using PHP:
Create a single PHP file which uses a loop to detect whether isset($_POST['submit_button'] has been submitted, and if the form has not been submitted then display the HTML form. If the form has been submitted, during the loop insert the data into the MySQL table.
Create the HTML form on page1.html and when the form is submitted parse the data and insert into the MySQL table on page2.php.
Both methods work perfectly fine - however, based on your own opinion, is one better than the other (such as security, maintainability etc...)?
Given the choice, I would choose neither. Instead I would opt for the Post-Redirect-Get (PRG) pattern, by which the form posts to a secondary page which only processes the input, but produces no output itself. Upon successful or unsuccessful completion of processing, the script redirects to a final page, which may be the original form page to display messages, errors, or request resubmission.
Typically, session variables would be used to pass information back to the final redirection point, whether that means values from $_POST to repopulate a form, or success/error codes.
This goes a long way toward solving issues with accidental form resubmission via the browser back button.
Your second method of posting to a different page is like an incomplete form of PRG.
I can say that from a usability standpoint, I prefer the first method, because it allows you to create sticky forms, i.e.
<input id="foo" name="foo" value="<?php echo $_POST['foo']; ?>" />
For cases where it is practical, I'd try to get away from having a second user pageload at all. page1.html submits via AJAX to a web service provided via page2.php. And yes, there are many cases where this isn't appropriate, but the most common patterns I can think of where the form handler is simply inserting rows into a database are well suited to an AJAX submit.
Related
I am new to developing PHP forms and currently trying to understand and learn how they are processed. If I understand it correctly, there are two approaches to using the "Action" attribute.
Method A: Use a separate PHP file to process the form. So in your first file (Form.php), you have the code for the form and submit button. Then in the ProcessForm.php file, you put all of your code for validating the data. In this case, you define the form as
<form method="post" action="ProcessForm.php" >
Method B: Use one PHP file for everything, including the code for the form, submit button, and all validation stuff (including output of error messages if form fields aren't entered properly). Here, you define the the form as
<form method="post" action="<?php echo htmlspecialchars($_SERVER["PHP_SELF"]);?>">
Right now, I don't understand if one of these methods is more correct or why you would use one vs the other.
I see a form as having four components: HTML for the form, PHP for connecting to MySQL, PHP for input validation/cleaning/error printout, and PHP for moving the data into the MySQL database. I want my form to be able to (upon submitting) work as follows:
If there are one or more errors in the submission process, stay on the same page (stop the submit process) and display relevant error messages, with the fields all still populated (as opposed to blank).
If there are no errors in the submission process, move the data into MySQL, and then display a blank page that says "your data has been submitted successfully" and a link back to my homepage.
Currently I am using Method B, and have implemented #1 above successfully. But I haven't achieved #2. So after this long story, my question is this: Where am I supposed to put those four components? In one file or two, and why?
Neither method is "more correct"; both are just as valid, the one you choose completely depends on the UX you are trying to achieve. Where you are supposed to put the four components depends on whether you are using method A or B.
For method A
If the form is on one page, and you're going to be submitting the data to another page via the action="example.php" attribute, the HTML for the form should (obviously) be on the first page, while everything else should be on the second (example.php) page (all the PHP and SQL). If there's a validation error, you can use header(Location: firstpage.php?error=something) to return users to the original page to fix their mistake.
For method B
If you're doing everything on one page (by putting action="<?php echo $_SERVER["PHP_SELF"]; ?>" or simply action="", both of which do the exact same thing), you should do the validation when a user submits the form on that one page, and if there are no validation errors, insert the data into the database and redirect the user using PHP's header() function.
As you're using method B, this is my more detailed step-by-step process of how I would handle such a form. In the example, firstpage.php is the page a user starts on, and secondpage.php is the page a user is taken to if all the information is correct.
Present the user with your form.
When a user submits the form, the data is submitted via POST or GET (depending on whether you want this information accessible via the URL. If you're not sure, use POST) to firstpage.php where the following PHP is:
PHP:
<?php
if (isset($_POST['submit']) {
// Some validation function
if (do_validation()) {
// Information is valid, insert into db
header(Location: secondpage.php);
die();
}
else {
echo "Error; the information you submitted is not valid.";
}
}
?>
When the user ends up on secondpage.php, you can tell them that the form was successfully submitted.
If you are posting to the script that generates the form itself then you don't even need an action. So method 3 is:
<form method="post">
which is the best version since it will not break and makes it clear that one script renders and handles the post for the form.
Neither of your other methods is ideal. Really you should be looking at (Smarty or something similar) to let you template the HTML and separate the display from the logic. Having said that both options 1 & 2 are perfectly acceptable - if you choose not to use the (superior) option 3 from above.
I can't speak to a "Best Practice", but of the 4 "Components" you mentioned, I think a missing key item is client-side validation as well (javascript typically). This saves you the "round trip" overhead of processing a form that could have already been validated before submitting to the server to handle.
With that being said (and because it's the approach I use), you'll be incorporating some javascript, so what I do is use javascript to validate my fields "on submit" (I override the form's default submit with a javascript event handler), then, if it validates, perform the submit. I do this with ajax, or you can use standard javascript to submit the form. You can even use javascript to set the "action" attribute dynamically (assuming you need to - see #Paul's reasoning why you may not need to).
The php file it submits to typically does 0 presentation work. It connects to the database, saves the "post'ed" info, closes the connection, and returns a status (which is typically why I like ajax because it's easier for me to handle that status response). Based on the status response, you can display an error message (like an alert, a bootstrap modal or info alert, etc.) or a success message/redirect.
While my answer does not offer code, I think the methodology above will serve you better based on your question. The "how" is the easy part once you understand the steps you want to take.
I have an application in which I display a form so a user can search for client records based on last name. After entering search parameters, the record or records (there could be multiple clients with the same last name) are displayed. I then want the user to be able to select a client record, possibly with a radio button, and hit one of two buttons: Display details, or Create Reservation. The Display Details button should cause a new display with details of the selected record. The Create Reservation button should cause a new form, with its own handling, to be displayed.
Now, I know I can set things up according to this login
<?php
if (display button was pressed)
{
php code to retrieve more data and display details
}
else if (create reservation button was pressed)
{
php code to generate and display the reservation form, with appropriate handling
}
?>
display the original form with the search results
The problem is, I end up with really ugly, hard to read code because the php code to generate and display the reservation form is lengthy, and needs its own validation, database interaction, and form handling. The code, to my Java-oriented eye, looks ugly and non-modular. Plus, the code for handling the reservation form is icky, with lots of flag setting to determine if we are in form entry mode or form handling mode. I would like a much cleaner way to do this. So my question is, what is the best practice for handling the situation where there are multiple buttons and the action associated with each button is complex?
I could call a function, obviously, but I still end up with the ugly flags determining which state the script is in (are we displaying the reservation form or handling it?). I could create another php file and include it, but the ugliness persists. Or, I could use header, and pass the client record id in a session variable to the new php script. But that would mean a second, unnecessary retrieve from the database to get the client information again.
All the code examples I see on the web show very simple processing after a form button is pressed. What is the best way to do complex processing and displaying a second form based on a button press?
Have you considered using a framework like Laravel for your site. It would seem to me that you must be doing this "manually". With the complexities you described, having a system with routes and "build-in" functionality (like Eloquent ORM) might serve to simplify things for you.
I would go for using ajax and a rich jQuery plugin (or some other framework) to do what you want.
Basically you will handle lists and the functionality that you mentioned with the php reading data and jQuery scripts to dysplay it. And the information that you have to show would be through ajax. Or when you want to edit.
Here is a cleaner example of what you need:
http://jqueryui.com/dialog/#modal-form
A very basic question. I have a form in one file form.php, I post it to another file processForm.php which does the server-side validation and processing. I am not using any framework.
Now, in case of form validation failure, I need to display the form again with all the values prefilled, without using a javascript history.back() from the processForm.php. What is the clean and proper way to do this so that I have all the posted values available again in form.php and can prefill them?
This is easy if the form submission happens to the same page, but this is how I got this and I cannot make the submission into the same page. So what would you do? Store the values in session? Curl post? Send the values using GET to form.php?
Why or why not? Please mention pros and cons.
Go read up on the MVC pattern.
You can't implement an interactive program without implementing a model, a view and a controller - the point is that your code should be structured to implement each of the three concerns as a single entity, be that as functions (or function trees), classes (or class trees) or files. And the three components within the pattern should be structurally grouped.
So if you want to the user to arrive at (say) second page after successfully filling in a form at first page, but to stay on first page when the form fails the validation, then a simple way to implement this would be to have first page implement the model view and controller, i.e. to both populate/generate the form and be the target for the form. Then if it receives a valid request sent from the form, send a redirect to second page.
This avoids the need for each page to load and process the MVC code for the preceding page as well as the current one - although that approach reduces the number of round trips to the browser which can help with performance.
NB using POST does not preclude the use of variables in the URL - indeed, I recommend using GET variables to indicate the data you wish to manipulate and POST variables to show how they should be manipulated.
I have a php page that generates a form. The action attribute of the form is the page itself. After the user submits the form, the same page is loaded, but this time a POST variable is set, so the page runs another script to deal with the incoming data from the form. I do this by using a conditional fork:
if(isset($_POST['var'])){
generate form
}else{
insert $_POST data into database
}
I'd like to know if this is ok or a bad idea.
I agree with Ignacio. Other than that it looks like a fairly standard approach if you don't need more complexity. One very important thing: make sure you are validating and sanitizing that data before it goes into the database.
The bad part is setting the action attribute to the script. Omitting it completely indicates to the browser that it should be posted to the same URL.
You might even want to go to the extent of checking whether the data was submitted thru AJAX to differentiate it from a regular form submission:
if ( $_SERVER['X_REQUESTED_WITH']=='XMLHttpRequest' )
// AJAX
I have a php page that has a form that asks for an e-mail. When you press the send button, it gets to another php page, which gets the form data and does its stuff. I need to then be able to go back to the old page (the one that contained the form) and give it some data so that it will be able to change itself and say "You've sent your e-mail successfully, and will not display the form.
How do I do it?
Sessions probably
http://us2.php.net/manual/en/book.session.php
You can either use sessions or cookies, to not depend on the URL cookies have always to be enabled.
Check the PHP Manual (Sessions and Cookies).
Options:
1) Set a cookie (or use a session variable, which is kind of the same thing)
2) Use a separate thank-you page. After you've processed the form, redirect to http://www.mysite.com/thankyou
3) Process the form on the same page as itself. If your form is at http://www.mysite.com/myform, then at the top of that page have a little
if ($_POST)
// process form
// display thank you
else
// display form
Good luck!
If the user is just seeing data that they've entered anyway, you can just use hidden form fields:
<input type="hidden" id="lang" name="lang" value="en" />
That way you can continue to POST new forms and pass the data down the lane. That's the easiest thing to do without having to write a single extra line of PHP code.
You could also store each section in a database and save each section as-added. That would give you the added benefit of having partial data in the case of a browser crash or whatever, depending on how many parts your form is. You could then pass just an ID to the DB table row and retrieve the data for display.