Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 09/08/2020 in all areas

  1. It's just a normal HTTP request, just like anything else. Forms really are not anything special. It's just like a link using an <a> tag, except you can send more data by using method="post". So if your trial page outputs the form <form method="post" action="checkout.php"> <input type="email" name="Email" value="example@example.com"> <button type="submit" name="ProductId" value="1">Get trial</button> </form> When you click the button the browser will Open a connection to example.com Submit the http request POST /checkout.php HTTP/1.1 Host: example.com Content-type: application/x-www-form-urlencoded Email=example%40example.com&ProductId=1 If you don't understand the above, you should do some research on the HTTP protocol and learn how it works. As you can see though, your trial page is not referenced at all in those steps. The request is for checkout.php and the data is sent in the body of the request in the same format as a query string. This is not at all true. POST data is just as visible and open to manipulation as GET data. The only difference is where it's located in the request. This is why I said you need to get over your trust issue with $_GET. $_SESSION is the only thing you can generally trust as that data never leaves the server and cannot be manipulated directly by someone, they would have to exploit some vulnerability in your server or your code. It's a little bit of a semantics / being pedantic thing. Big picture, sure you are passing some data. Your not passing the trial pages $_POST array though. The trial page doesn't have a $_POST array unless your posting data to it in some way. By adding the action attribute pointing to checkout.php you're no longer posting any data to the trial page, your posting it to the checkout page. There's nothing wrong with using terminology like "pass the ProductId to the checkout.php page", but you should have the understanding of how that actually works. The language in your posts implied that you did not as you seemed to think that PHP was either sharing one $_POST between scripts (misunderstanding "global" I think) or somehow moving the $_POST array from one script to another which is not how it works.
    1 point
  2. Based on your last post it sounds to me like you still don't really understand the process, or maybe you do but just don't articulate it well. It sounds to me like you're thinking you are defining $_POST['ProductID'] on your trial page then have to somehow transfer that variable over to the checkout page. That's not really how things work though. Your trial page doesn't have a $_POST['ProductID'] variable. It generates a form as it's output. That form is submitted to the checkout page, and that form's data contains a ProductID field which makes it so that your checkout script will have a $_POST['ProductID'] variable. Taking a step back to basics again, every request you have to look at in complete isolation. The request has to contain whatever data your script needs to get stuff done, and there are a variety of places in a request that the script can look at for data. $_GET - Data from the requested URL's query string (side note, you should get over your trust issues, $_GET is fine for something like a product ID). $_POST - Data from the request's body content, assuming the body is form data. $_COOKIE - Data from any Cookie: headers $_SESSION - Session data is handled via a slightly more complex process. When your script ends, the data stored in $_SESSION is saved to the web server somewhere and a unique identifier is then passed to the client. The client passes that identifier back to PHP on the next request (usually as a $_COOKIE value) and then the data is looked up on the server and restored. Whether you use a database or not doesn't really matter. You'd give your checkout.php page an identifier of some sort via one of the above mentioned input options. Your checkout page would then use that input to do whatever it needs to do. You can provide your identifier via $_POST if you want to checkout.php, but you're not "transferring $_POST['ProductID']" from the trial offer script to your checkout script, at least not in the way it sounds to me like you are thinking. Your trial offer script does nothing more than generate a form with whatever data you need. Once that is generated and sent to the client the trial offer script is done and is no longer relevant. When the user submits that form then the browser would take the form's data and send it directly to checkout.php, no other script is involved in the process. Now, going back to your original question, you mention having a shopping cart, so you need to split your process into two parts. Add the item to your cart. Display the items in your cart. Whether you want to do that via two separate scripts or all in your checkout.php doesn't matter too much. You could have your trial offer page post back to itself like your normally do and add the item to the cart then just redirect. In that case your checkout doesn't need to do anything other than look at the contents of the cart and display them. Otherwise you could have an input to your checkout page that identifies an item to add to the cart. You'd then just have your trial page create a form that posts directly to the checkout page with the necessary data. Your checkout page should still logically treat this as two steps and add the item to the cart, then look at the contents of the cart and display it.
    1 point
This leaderboard is set to New York/GMT-04:00
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.