One button and two scripts

[SaranacLake]

Hello.  This is sort of an embarrassing question, but I guess it is something I've never done before.

In the past, whenever I had a command button on a webpage, I used a form and when the user clicked on the button I also just reloaded the same PHP script to process the $_POST request.  (I realize that a lot of people have the form on the 1st page/script, and the have a 2nd page/script to handle the form request, but that always seemed like overkill to me.)

 

With my new problem, I have one web page that has a subscription offer on it, with just some bullet points of why the user should be interested, and then a "Get this offer" button.

When the user chooses this button, what should happen behind the scenes is that I add the ProductID to the shopping cart - which is a database record - and then I redirect to my checkout page.

 

While typing up this thread, maybe I don't have an issue after all?  😕

I guess what i could do on trial-offer.php is have a form surrounding my "Get this offer" button, and when the user submits the form, my trial-offer.php script could add a shopping_cart record in the database and then I could use a re-direct to go to my checkout.php script, right?

 

But to my original question, if I did want to pass the ProductID to my "Checkout.php script, what would be the best way to do that?

Could I still use a $_POST and but just send the form to my other script (i.e. checkout.php)?  (This is the part I was unsure of above!)

Or would I be forced to use a $_GET which i don't really like or trust?

 

[requinix]

Having your checkout page support form data to add the offer does kinda make sense. You can do that.

If you have a page listing your subscription(s) then surely you have something to go with it like a subscription ID? Pass that to the checkout page. POST would be better since you're talking about something that modifies data.

[SaranacLake]

8 minutes ago, requinix said:

Having your checkout page support form data to add the offer does kinda make sense. You can do that.

Well, my checkout page will of course support form data since that is where the user enters in payment details, etc.

What I was asking about is sending the ProductID to the checkout page so it can add things to the shopping cart and then use it for checkout.

 

8 minutes ago, requinix said:

If you have a page listing your subscription(s) then surely you have something to go with it like a subscription ID? Pass that to the checkout page. POST would be better since you're talking about something that modifies data.

Okay, that is hat I was asking about.

So the whole time I have been using PHP, when I submit a form I always do this...

	<form id=login" action="" method="post">
	

which in turn sends control back to the same script.

 

If I anted to pass a ProductID/SubscriptionID from the trial-offer.php page to say my checkout.php page, is it as simple as tweaking the above code to say this?

	<form id=login" action="checkout.php" method="post">
	

 

And what exactly would that do?

Would I be physically sending the $_POST array to the heckout.php script, or is that revised code just sending control to the checkout.php script?

(Those are the parts I am unsure of since I have only ever worked with a single script to handle forms up until now.)

 

[requinix]

29 minutes ago, SaranacLake said:

What I was asking about is sending the ProductID to the checkout page so it can add things to the shopping cart and then use it for checkout.

I don't recommend using the checkout page as a way to add any product. Don't misunderstand: I'm not saying this subscription business should go in the checkout page. I'm saying it can go there - for your own ease of use.
(The alternative is having an AJAX-y way of adding products, then when that request completes the button navigates to the checkout page.)

What I would do is have the checkout page support adding a subscription product specifically. You can POST to it the subscription ID, then it adds the subscription to the cart if there isn't already a subscription in there.

 

29 minutes ago, SaranacLake said:

If I anted to pass a ProductID/SubscriptionID from the trial-offer.php page to say my checkout.php page, is it as simple as tweaking the above code to say this?

More or less, yes.

 

29 minutes ago, SaranacLake said:

And what exactly would that do?

It would submit the contents of the form to checkout.php instead of to the current URL.

Before you continue, you should probably familiarize yourself with HTML forms and how they interact with the server. That's some rather important knowledge to have.

[SaranacLake]

3 minutes ago, requinix said:

I don't recommend using the checkout page as a way to add any product. Don't misunderstand: I'm not saying this subscription business should go in the checkout page. I'm saying it can go there - for your own ease of use.
(The alternative is having an AJAX-y way of adding products, then when that request completes the button navigates to the checkout page.)

Maybe what I said wasn't clear enough.

To my a ProductID and SubscriptionID are the same thing, although if you buy a T-shirt that would only be a ProductID - I am using the terms interchangeably here.

Also, my checkout page has a summary of all items in the shopping cart at the top - it's all one page.

So originally I was thinking of having trial-offer.php send a Product/SubscriptionID to the checkout.php script where it adds things to the shopping cart AND then reads the shopping cart to populate the "cart summary" portion used during checkout.

The more I think about things - and the way I have always done things in the past - I think I will have trial-offer.php write the SubscriptionID to the shopping-cart table, then redirect to checkout.php, and then checkout.php can read the shoping_cart table and populate itself.

"Six of one, a half-a-dozen of another", but I always prefer using the database as the "source of truth" so I wouldn't need to pass a Subscription/ProductID between web pages that way.

 

3 minutes ago, requinix said:

It would submit the contents of the form to checkout.php instead of to the current URL.

Before you continue, you should probably familiarize yourself with HTML forms and how they interact with the server. That's some rather important knowledge to have.

I will read up on things, but aren't the $_POST and $_GET arrays "global" so that when you submit a form from page-1.php it writes things to say $_POST and then page-2.php can automatically read $_POST?

Or does page-1.php physically pass the $_POST array to page2.php?

 

 

[requinix]

8 minutes ago, SaranacLake said:

To my a ProductID and SubscriptionID are the same thing, although if you buy a T-shirt that would only be a ProductID - I am using the terms interchangeably here.

That's fine, but a product and a subscription are not the same thing. You treat one differently than the other, not just internally but with the user experience too. And that distinction matters.

But I take back what I said earlier. It's okay to add products things within checkout.php. It makes sense as a single click operation: user wants thing, doesn't want anything more, goes to checkout which also adds that thing to the cart.

 

8 minutes ago, SaranacLake said:

The more I think about things - and the way I have always done things in the past - I think I will have trial-offer.php write the SubscriptionID to the shopping-cart table, then redirect to checkout.php, and then checkout.php can read the shoping_cart table and populate itself.

If you want.

 

8 minutes ago, SaranacLake said:

"Six of one, a half-a-dozen of another", but I always prefer using the database as the "source of truth" so I wouldn't need to pass a Subscription/ProductID between web pages that way.

You're comparing apples and oranges. The database is the "source of truth" regarding what is currently in the shopping cart. It is not the source of truth for how things get into that cart.

 

8 minutes ago, SaranacLake said:

I will read up on things, but aren't the $_POST and $_GET arrays "global" so that when you submit a form from page-1.php it writes things to say $_POST and then page-2.php can automatically read $_POST?

That is not at all what they mean.

You know how variables defined outside a function are not available inside a function? The $_GET and $_POST (and other) superglobals do not have that restriction.

 

8 minutes ago, SaranacLake said:

Or does page-1.php physically pass the $_POST array to page2.php?

There should never be any sending of POST data between your own PHP scripts.

[SaranacLake]

2 minutes ago, requinix said:

That's fine, but a product and a subscription are not the same thing. You treat one differently than the other, not just internally but with the user experience too. And that distinction matters.

This relates back to my debate with Gizmola a few months ago.  I decided to have a super-type Product table and then sub-type tables like Membership_Plans, eBooks, Gear.

So there will be a productID for anything you buy for me.  And yes, a subscription is obviously treated different than say a T-short.

But as far as the shopping cart is concerned (or the checkout page), everything is referenced by its productID.

 

 

2 minutes ago, requinix said:

But I take back what I said earlier. It's okay to add products things within checkout.php. It makes sense as a single click operation: user wants thing, doesn't want anything more, goes to checkout which also adds that thing to the cart.

For subscription, when a user chooses one I go directly to the checkout page since I want to get them to become a member before they change there mind.  So that is sorta like a "Buy it now" button which I think you are referring to.  (I also offer that option on the product details page for things like T-shirts.  ("Add to Cart" or "Buy it Now")

 

 

2 minutes ago, requinix said:

If you want.

Yeah, in reflection, I prefer working from the database when possible.

 

2 minutes ago, requinix said:

You're comparing apples and oranges. The database is the "source of truth" regarding what is currently in the shopping cart. It is not the source of truth for how things get into that cart.

True, but my point was it is easier to work from one source (i.e. shopping cart) versus working with a variable and the database and keeping them in synch.

If you add items to the database (i.e. Add-to-cart), then read from the database (checkout) then you never get out of synch.

 

 

2 minutes ago, requinix said:

That is not at all what they mean.

You know how variables defined outside a function are not available inside a function? The $_GET and $_POST (and other) superglobals do not have that restriction.

That is what I thought.

Okay, so let's say trial-offer.php has this code...

	<form id="trial-offer" action="checkout.php" method="post">
	<input id="" name="offer" type="text" value="mp1234" />
	

(Hopefully I remembered the correct syntax above)

 

When the use clicks "Get this offer" in "trial-offer.php" then that chocie gets put in the $_POST array.

And I guess you are saying by virtue of using a gloabl variable like $_POST that my other script, "checkout.php" can automatically reference that variable, right?

If so, then what does action="checkout.php" accomplish other than sending control from "trial-offer.php" to "checkout.php"?

 

Sorry, I haven't actively coded in PHP in like 5 years...  😑

 

2 minutes ago, requinix said:

There should never be any sending of POST data between your own PHP scripts.

 

[requinix]

1 hour ago, SaranacLake said:

That is what I thought.

Sorry but no, it is not what you thought. Seems a quick primer is in order.

PHP handles exactly one page request at a time. When it finishes with a page, it completely forgets everything that happened. You can't set a variable on one page and get it in another page. Obviously that would be a huge limitation to making a website work, and that is why things like databases and cookies and sessions exist.
That means there is no transfer of "control" between pages. PHP doesn't remember that the user was on trial-offer.php and is now going to checkout.php. All it knows is that someone is trying to request checkout.php, and they may or may not be sending data too.

$_POST is not a database or cookie or session. It's a variable. A variable that you can reference from anywhere in your code, but just like every other variable, it's only usable for that one page. If you made any changes to it (which is a bad practice so don't do that) then you could see those changes for the rest of the page, but whatever you do will not be available on another page. Same for $_GET.

$_GET gets its information from the query string - the stuff after the question mark in the URL. PHP looks at the query string, parses it, and shoves the data into $_GET for your convenience.
$_POST gets its information from POSTed form data. The most common way to send POSTed form data is with a <form> whose method=POST. PHP looks at the data sent to the server, parses it, and shoves the data into $_POST for your convenience.

If you have a form with an action="" then the browser will be nice and assume you meant action="(the current URL)". That's how form data goes back to your page: because the browser told your server that it wanted the same URL with some POSTed data.
If you have a form with an action="checkout.php" then the browser doesn't have to assume anything, and it will tell the server that it wants checkout.php with some POSTed data.

[SaranacLake]

24 minutes ago, requinix said:

Sorry but no, it is not what you thought. Seems a quick primer is in order.

PHP handles exactly one page request at a time. When it finishes with a page, it completely forgets everything that happened. You can't set a variable on one page and get it in another page. Obviously that would be a huge limitation to making a website work, and that is why things like databases and cookies and sessions exist.
That means there is no transfer of "control" between pages. PHP doesn't remember that the user was on trial-offer.php and is now going to checkout.php. All it knows is that someone is trying to request checkout.php, and they may or may not be sending data too.

Thanks for the refresher - I told you it's been a l-o-n-g time since I've done PHP!

So in my case, when the user clicks on "Get this offer" on the trial.offer.php page, if I wasn't using my database to store things, then how would I send the ProductID - corresponding to whatever trial offer exists at that the time and hard-coded into my page - to the checkout.php page so it knows what the user wants to buy?

You are saying I can't use $_POST to transfer that information from trial-offer.php to checkout.php.

And I only use cookies to store the SessionsID.

So would I have to "pass" the ProductID in the $_SESSION variable?

(And I thought e-commece sites often used query strings to pass data, or is that just to request data like in a product search?)

 

24 minutes ago, requinix said:

$_POST is not a database or cookie or session. It's a variable. A variable that you can reference from anywhere in your code, but just like every other variable, it's only usable for that one page. If you made any changes to it (which is a bad practice so don't do that) then you could see those changes for the rest of the page, but whatever you do will not be available on another page. Same for $_GET.

$_GET gets its information from the query string - the stuff after the question mark in the URL. PHP looks at the query string, parses it, and shoves the data into $_GET for your convenience.
$_POST gets its information from POSTed form data. The most common way to send POSTed form data is with a <form> whose method=POST. PHP looks at the data sent to the server, parses it, and shoves the data into $_POST for your convenience.

Apparently in the past I was able to do pretty much everything I needed using one web page at a time....

 

24 minutes ago, requinix said:

If you have a form with an action="checkout.php" then the browser doesn't have to assume anything, and it will tell the server that it wants checkout.php with some POSTed data.

I'm confused by that last statement...

If I have a form on the trial-offer.php page and it has action="checkout.php" then it will tell the server it wants checkout.php and pass along the $_POST array?  (Because when you end that with "...with some POSTed data" that implies you are passing along the $_POST array from one web page to another.)

Is that what you meant?

 

 

 

 

 

 

[kicken]

4 hours ago, SaranacLake said:

Thanks for the refresher - I told you it's been a l-o-n-g time since I've done PHP!

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.

 

4 hours ago, SaranacLake said:

So in my case, when the user clicks on "Get this offer" on the trial.offer.php page, if I wasn't using my database to store things, then how would I send the ProductID - corresponding to whatever trial offer exists at that the time and hard-coded into my page - to the checkout.php page so it knows what the user wants to buy?

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.

 

4 hours ago, SaranacLake said:

You are saying I can't use $_POST to transfer that information from trial-offer.php to checkout.php.

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. 

1. Add the item to your cart. 
2. 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.

 

[SaranacLake]

@kicken

3 minutes ago, kicken said:

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.

You may be correct in that I don't understand things...

I thought that if I created a form on trial-offer.php, that when you submitted that form - which in my case would likely just be a hidden field containing the "ProductD" - that things got put into the $_POST array like $_POST['ProductID'].

And based on what @requinix  said, I thought the scope of the $_POST array was local to, in this case, trial-offer.php.

 

 

3 minutes ago, kicken said:

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

On a side note, how is the form data transferred to action="checkout.php"?

I was always under the impression that POST data was basically hidden and safe from the outside world, including hackers...  And I guess I thought the $_POST array somehow securely "wrapped" your submitted form data and sent it to its end destination.  (Then again, since as long as I have been using PHP, I just submit forms to themselves, I guess I haven't had to really think how things work!!)

 

3 minutes ago, kicken said:

, and that form's data contains a ProductID field which makes it so that your checkout script will have a $_POST['ProductID'] variable.

Let me repeat...

So if I do like in the past and have...

	<form id="" action="" method="post">
	

then every field on my form gets submitted back to the same calling script (e.g. "trial-offer.php"), and all of that data gets nicely packaged into a $_POST array that is *only* accessible to - in this case - "trial-offer.php", right?

 

But if my action statement was action="checkout.php" then you are saying that all of the form data gets sent to - in this case - "checkout.php" and the data is wrapped in a nice $_POST array that is *only* available to - in this case - "checkout.php", right?

 

 

3 minutes ago, kicken said:

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.

Okay, yes, I vaguely remember these things, although I worked almost entirely with $_POST and $_SESSION in the past.  (A little $_GET, but never $_COOKIE).

 

 

3 minutes ago, kicken said:

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.

Yes, understood.

Because I am most comfortable with databases - and I think they are safer as far as not losing data/maintaining control in relative terms - I was thinking of doing this...

	- User is on home page
	- User clicks the "One month for $1" button
	- System loads "trial-offer.php"
	- User clicks "Get this offer"
	- System submits hidden field containing ProductD = 1234 via the form back to trial-offer.php
	- trial-offer.php writes this to the shopping cart table.
	- trial-offer.php redirects to checkout.php
	- checkout.php finds the SessionID and queries the shopping cart table for the user's shopping cart items (e.g. trial offer)
	- checkout.php populates the shopping cart items onto the checkout pages and builds the rest of the checkout page
	- and so on...
	

 

My earlier questions to @requinix was more just to learn/re-learn how I might do the same thing by merely "passing" the ProductID directly from trial-offer.php to checkout.php if I didn't want to use my database here.

And clearly my understanding of how forms and $_POST works were off!!  🙂

 

 

3 minutes ago, kicken said:

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.

Okay this is where I clearly didn't understand (or remember) things...

So it sounds like you are saying that even though the user is ON "trial-offer.php", because I have defined action="checkout.php" it is like trial-offer.php isn't even there, right?

In this case, I think you are saying that my trial-offer.php form data - whether that be one hidden field or 20 name/address/interest fields - gets shipped over imemdiately to checkout.php in a nice container of the $_POST array, but it's all about checkout.php at that point, right?

(Again, I have spent my entire short PHP career submitting forms/PHP pages back to themselves, so that sorta *warped* my understanding/view of how things were working...  Like when you log in on my website, I load login.php which displays the form, you enter your credentials, then click "Log in" and that form data gets sent right back to login.php.  From there I dissect $_POST and compare the $_POST['username'] and $_POST[password'] or more like hash against the database and then my login.php script either logs you in and redirects you or you get an error message on login.php!)

 

Submitting a form on Page-1 and letting Page-2 is an entirely new concept to me - as embarrassing as that may be?!  🙂

 

3 minutes ago, kicken said:

Now, going back to your original question, you mention having a shopping cart, so you need to split your process into two parts. 

1. Add the item to your cart. 
2. 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.

Right.  if I add the chosen item - in this case the "Trial Offer" - directly to the database from trial-offer.php then I could do like I have always done.

And as you say, just let checkout.php load the shopping cart item(s) when that page loads - which it would upon being re-directed to from trial-offer.php.

 

Again, i was just curious how I could "pass" ProductID to checkout.php without using MySQL.

 

Earlier I think you said that trial-offer.ph would not "pass the $_POST array" to checkout.php, BUT you did make it sound like trial-offer.php DOES pass all of the form data to checkout.php because I would have action="checkout.php"

 

Can you help me better understand the "mechanics" and proper language to describe what does happen getting data from point-A to point-B?

 

This is an interesting discussion!!  👍

[kicken]

45 minutes ago, SaranacLake said:

On a side note, how is the form data transferred to action="checkout.php"?

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

1. Open a connection to example.com
2. 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.

55 minutes ago, SaranacLake said:

I was always under the impression that POST data was basically hidden and safe from the outside world, including hackers...

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.

1 hour ago, SaranacLake said:

Earlier I think you said that trial-offer.ph would not "pass the $_POST array" to checkout.php, BUT you did make it sound like trial-offer.php DOES pass all of the form data to checkout.php because I would have action="checkout.php"

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. 

 

[SaranacLake]

@kicken 

 

5 minutes ago, kicken said:

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

1. Open a connection to example.com
2. 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.

Okay, thank you, that is helpful!

 

 

5 minutes ago, kicken said:

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. 

Okay, point taken.

 

 

 

5 minutes ago, kicken said:

 $_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.

Yeah, in the past I relied more heavily on $_SESSION, although with any data, I always try to check it against the database to make sure it wasn't manipulated!

 

 

5 minutes ago, kicken said:

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.  

I welcome being corrected on semantics, and "pedantics" makes for better programmers!  🙂

Based on what you said above, I guess what is happening is that the user requests trial-offer.php and the server serves that page up to the user's browser which in turn displays the web-form.

When the user submits the web-form on trial-offer.com, it's not like data is being copied from trial-offer.php to checkout.php, but rather that the user is requesting checkout.php AND is appending some data on the end of that request - similar to a $_GET query - and so that USER-DATA gets sent to checkout.php but it's not like you have intra-webpage data transfer like I made it sound...

 

How does that sound?

 

Likewise, it sounds like the $_POST array doesn't really come into the picture until after checkout.php has received the USER DATA.  Is that correct?

 

 

5 minutes ago, kicken said:

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. 

 

Yes, I was WRONG in both conceptions of how things actually work!!

 

Thanks for helping to clarify those subtle, yet important differences!!