Using $_GET for multiple links in one php code - php

Php newb here. I have a registration form that when you have errors in registering, it just redirects back to the form, not telling what the error is. So I'm wanting to make an error.php, and make it, instead of redirecting to the registration page, redirect to the error.php?error=whatever.. Thing is, I'm not sure how to use the $_GET methods and whatnot. Any help?

On redirection
The best way to do this is IMO is to send the form data via AJAX to your PHP file, then have your PHP file respond with a yes/no on if the data is valid or not. Once the AJAX return says your data is valid, then proceed to the registration page (or wherever you're going).
This avoids the need for the user to go back and forth just to figure out what form data they did wrong.
On $_GET
See the $_GET section of the PHP Manual. You can access $_GET as an array, or get specific values from it.
This PHP...
<?php
echo $_GET['example'];
?>
...would retrieve and echo the value of the following text box.
<form method="get" action="targetFile.php">
<input name="example" type="text" />
</form>
Also, make sure you're running this on a server of some kind, even if it's local. A web browser alone cannot process PHP and thus will give you the "white page of doom." I use XAMPP.
I know some people hate W3schools, but if you're still struggling check out this guide.

Related

I'm trying to understand PHP_SELF vs ProcessForm.php in the Action field of a <form>

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.

Required form messages on same HTML page and PHP

I have an HTML 5 form page. I know the method attribute action in the form tag determines what to do once submit button his hit.
So far I have something like this: <form action="form_action.php" method="post". I know some form's in HTML5 have a required attribute, but I understand that the PHP code should also do the required checking for security purposes.
If a person hits submit, I would like the required messages to pop up on the same html5 form page rather than completely redirecting to my php code. Can someone please explain how to do this or provide references?
I read something about the superglobal _SERVER(["PHP_SELF"]) but if I use this, how do I pass variables to my PHP script? I will be doing some SQL in PHP too.
<form method="post" action="<?php echo htmlspecialchars($_SERVER["PHP_SELF"]);?>">
Any help appreciated. Thanks.
If you want to process the contents of a form before they are sent to the server (e.g. on the client side), you have to do it using JavaScript, not PHP.
For an introduction on how to do that, try to google "javascript form validation" or something similar. A good starting point could be this tutorial. You may also want to look at jQuery which makes writing JavaScript easier and has become the standard way of writing JavaScript code that works in all browsers.
You could use header("Location: first_page.php") on your action.php page to redirect to your first page (eventually with some options) if the inputs are not correct.

Prevent a line of source code from showing

How to hide this html line, that will not appear for the user in inspect element or view source.
<input type="hidden" name="kda" value="<?php echo $code;?>">
how can I do this?
You can't do that - everything you send to the browser can eventually be read and stored somehow.
What you can do instead, however, is using a session to store this information. Then, only a session identifier will be sent to the browser (and back to the server) while your sensitive information can stay on the server.
It's impossible to hide HTML from view source. Any HTML gets sent to the client and can be viewed in view source. Try storing it in $_SESSION, a PHP superglobal. It gives the user a cookie that tells PHP where to look to find that user's information in $_SESSION.
$_SESSION is an array. That means you can store $_SESSION['pies_bought'] = 7 and $_SESSION['cakes_bought'] = 3.
http://www.php.net/manual/en/session.examples.basic.php
If you "hide" it, it won't work.
You could surround in PHP comment so it's stripped when the server renders the page, but I think you are asking to hide the value of this hidden form field, and that you can not do as you are suggesting.
You could post the "viewable" form fields to another php script that then adds this "confidential" key, and then submits the form wherever it's going.
You could, upon submission of form, call an ajax request to get the value and submit all at once.
Many ways to skin a cat.
Set this flag as a PHP variable instead of actually including the hidden input field in the form.
You may use encryption if you still want to use it as a query parameter in your form otherwise session is your best bet.
<input type="hidden" name="kda" value="<?php echo some_php_crypt_function($code);?>">
When you receive kda on the server,just decrypt it and get the value.
This link http://www.php.net/manual/en/mcrypt.examples.php has examples of how to use encryption/decryption in php.

How do you make the browser re-post form data when using the back button?

I guess my question is in understanding the $_POST handling.
So I have two pages that handle 2 forms. Page 1 asks for some information that will be used in page 2. When submitted the form action uses the same page then redirects to next page upon validation, but only handles the data when $_GET variable ?usersubmit=1.
<form action="<?=$_SERVER['PHP_SELF']?>?usersubmit=1" method="post" name="form1">
<input type="text" name="field1">
</form>
So say I have page called form1.php. Upon submit its sent to form1.php?usersubmit=1. The page now assigns the posted data to session variables and then redirects to form2.php via header('location:form2.php').
<?
if($_GET['usersubmit']){
if($_POST['field1']){
#if valid then assign session variable and redirect to next form
$_SESSION['field1'] = $_POST['field1'];
header("location:form2.php");
}else{
#if invalid send error message
$error = true;
}
}
?>
My problem is in when users hit the 'back' button on their browser to edit data from a previous form. The browser doesnt re-post this data it just shows them a blank form. I'd prefer not to use $_SESSION data to fill out the forms because I suspect the re-post method may be a quicker and less problematic fix.
I also tried a javascript redirect instead of a header but browsers are smart enough to not send you back to a page that wants to redirect you so it doesnt work.
any help in understanding this would be greatly appreciated.
thanks.
The only way to handle it is via a session... HTML5 allows for storing of that kind of data but to be honest I wouldnt even look into it as a possibility just yet, altough it does work.
typically the back button will use all of the same get and post variables as was used on the previous locations page load. server side header redirect will not allow you to use the back button to get to the previous page since this redirection is done on the server side.
there are two ways to redirect using javascript window.location which will put your previous location into the browser history and therefore the back button will work, and location.replace which will not put a link in your history, and therefore not allow you to use the back button to get to the previous page.
alternatively, you could just use page two to process page ones form...
Also, you should use htmlentities() in your code. It closes a security vulnerability (see http://www.html-form-guide.com/php-form/php-form-action-self.html for more details).
<form action="<?=$_SERVER['PHP_SELF']?>?usersubmit=1" method="post" name="form1">
should change to something like this below.
<form action="<?=htmlentities($_SERVER['PHP_SELF'])?>?usersubmit=1" method="post" name="form1">

deal with undesirable behaviour when clicking the back button on my website

I've looked around for an answer to this problem, and I'm slowly accepting the fact that I've probably gone about things the wrong way, but here's a request for some wonderful pearl of wisdom that might help!
I'm working on a website which has a directory-style navigation bar on the left. So at first the user will only see two directories (Grammar / vocabulary - it's an English learning site) and by clicking on the directory, it will "open" to reveal its contents (other pages or directories).
The way I have this working is that each directory is a form submit button that reloads the page when clicked, but with a value in $_POST that tells the site to open or close a folder (this is done within an array in $_SESSION). It works great! The issue, though, is that if a user clicks the back button in their browser, they get the prompt asking if they wish to resubmit data, which is not something I want.
I was wondering if there was a way I can detect in php if the back button has been pressed, so that instead of reloading the page and making changes to the side bar, the side bar will remain the same and instead the user gets taken to the last page they had visited.
I'm aware that the real solution to this is probably just to rethink the side bar, and any advice on a better way to do that would be much appreciated also!
Michael
The reason you're getting the prompt is because POST is supposed to be used if the data being sent is going to modify something, so submitting a POST request using the back button might have unexpected behaviour (like duplicate data).
Replacing POST with GET should disable the prompt.
HTML
From:
<form action="page.php" method="post">
</form>
To:
<form action="page.php" method="get">
</form>
PHP
Change references from $_POST[''] to $_GET['']
DEMO: http://aseptik.net/php5/demo/deal-with-undesirable-behaviour-when-clicking-the-back-button-on-my-website
<?php
session_start();
if( $_GET['t'] == $_SESSION['token'] || $_SESSION['directory'] == $_GET['q'] || !isset($_GET['q']) ) {
echo "<h1><span>you going</span> forward</h1>";
} else {
echo "<h1><span>you going</span> backward</h1>";
echo "<p>should be <strong>{$_SESSION['directory']}</strong> directory</p>";
}
$token = uniqid();
$_SESSION['token'] = $token;
$_SESSION['directory'] = $_GET['q'];
?>
grammar
vocabulary
Back button re-submit form data ($_POST)
Prevent Back button from showing POST confirmation alert
As a general rule in web development you should only do a post when you are submitting data that you don't want to be resubmitted, or that you don't want to show up in your logs on the server. And once you do a post, you should redirect using get parameters or some other method.
If you use get parameters instead of post then you can just make the page navigation stateless and just fetch the page they ask for.
There are methods for detecting if the back button has been pressed, but they are difficult to make work consistently, and can be frustrating to the user, so it is recommended you go about it another way.

Categories