Are Hidden Variables $_POST variables?

If you pass some variable values from one form to another using hidden variables, how do you subsequently refer to those variables? For example, through a form on the first page the client indicates their country, so that value would be a $_POST variable (?)...

Code:

---

<input type="hidden" name="country" value="<?php echo $_POST['country']; ?>">

---

then on the second page they enter their email address and an email is sent to them showing all their data. When replacing variables for use in the email, is the value of $country referred to as a $_POST variable or as just $country? Which is correct? This...

Code:

---

$body = str_replace('%country%',$country, $body);

---

or this?

Code:

---

$body = str_replace('%country%',$_POST['country'], $body);

---

Or is there a better way to accomplish this?

Thanks.

Assuming your forms are using the POST method, yes.

PHP Code:

---

<input type="hidden" name="country" value="<?php echo $_POST['country']; ?>">

---

As for getting the value, your second example will work, though I prefer doing it like this (cleaner, in my view):

PHP Code:

---

$country = $_POST['country'];
$body = 'You live in country'; // I assume you have something like this that the line below modifies
$body = str_replace('%country%',$country, $body); 


---

Thanks, traq. Exactly what I needed to know! :)

Something I have always wondered... if you refer to a variable as $_POST['country'] and the value has already been put in a regular variable like $country, will it still work? For example if you load $country from a database and refer to it as $_POST['country'], will the value come through?

You mean like:

Code:

---

INSERT INTO Persons (country)
VALUES ('".$_POST['country']."')

---

If so - yes. It will always be there.

The reason I prefer to assign POST (GET, etc.) variables to regular variables is that I run into fewer problems escaping, unescaping, and concatenating when I'm building queries and strings, especially more complicated ones. But it's just a preference.

So do you reassign them immediately, as soon as the value is retrieved from the form? And then in Nile's example you would use this instead?...

Code:

---

$country = $_POST['country'];
INSERT INTO persons (country)
VALUES ('".$country."')

---

I am trying to rewrite a whole website so that it will still work with Register_Globals = Off and am trying to assign $_POST to almost all the variables. It's very tedious (expletives deleted). :)

You could do this:

Code:

---

INSERT INTO persons (country)
VALUES ('".$_POST['country']."')

---

BUT ALWAYS REAL ESCAPE IT

This is not the question. I don't have any trouble inserting the values into the database. I already do it exactly as you have there. I was asking if I should do it the other way.

I don't know what "real escape it" means. Something about preventing SQL injection but I can't remember at the moment. I need to get everything working first before I worry about preventing someone from hacking it.

Referring to the original post: hidden is a type of form field. It is just like any other field that has a value-- text, password, etc. It is just not displayed in the browser or editable by the user (except by someone who knows how to 'hack' it with javascript). Just like any other value in the form it will be sent the same way as a text field (etc):
<input type="hidden" name="f1" value="v1">
<input type="text" name="f2" value="v2">
Once submitted, both will be available in exactly the same way:
$_GET/POST['f1'] == 'v1';
(depending on method="get/post")


About "real escaping":
I think the name is nonsense, but that's what it's called: mysql_real_escape_string($string) (returns 'escaped' string).
Basically this is a function in php that is designed to stop database hacking by injecting mysql code. It escapes certain characters (I have no idea which ones, actually, aside from the obvious things like quotes and semicolons), and returns a now safe string to use in a query.
You should ALWAYS use it (or an equivalent function) on any user-generated text that goes inside a mysql query or a user can add code to hack your database-- delete it, get info they should not have, get around security, whatever.
http://www.php.net/manual/en/functio...ape-string.php

He means mysql_real_escape_string() . Yes, you should always use it before submitting user input to your DB to prevent SQL injection attacks.

"Should" you do it my way? No, not necessarily. If you like it, go ahead, but don't feel compelled to change your method "just because." To answer your question, I assign the variables just before the block of code I'm going to use them in, like so:

PHP Code:

---

// some code
// some other code

$country = mysql_real_escape_string($_POST['country']);

$SQL = "INSERT INTO persons (country) VALUES ('$country')";
$query = mysql_query($SQL);

// more other code, etc... 


---

just to keep things organized. much easier than assigning all variables at the beginning and then having to remember where, exactly , I'm using them.

On the other hand, rewriting your site to turn register_globals off is definitely something you should do.

Edit:

Quote:

---

Originally Posted by php.net

mysql_real_escape_string() ... prepends backslashes to the following characters: \x00, \n, \r, \, ', " and \x1a.

---

Hi Daniel! I am coming in to the home stretch on that site you were helping me with a month ago. I successfully replaced the function with includes and am now trying to tie the whole thing together logically. I'm hoping that the $_POST variables will solve the Register Globals issue. I ended up renaming all the variables so they make sense to me, but what a can of worms that became! There is one variable I can't get to work even with $_REQUEST but I'll ask about that later. Right now I want to see if I can apply traq's trick without breaking anything.

Thanks, traq, for sharing your method. It may solve a confusion I have encountered when trying to use the same include in various places, one where the variables are coming from the database, one where they are coming from forms, and one where they are coming from the database into a form for editing and then being used in emails. I am wondering if in the 3rd case I should save the updates and then reload from the database rather than use the $_POST variables. Is there a best way? Thanks. :)

...if I understand you correctly, it would not make any difference. You could perform the DB query and the emailing together, so as to make sure you have consistent values (i.e., if the DB query fails, the email that says it was successful won't be sent):

PHP Code:

---

// code for preparing vars for database above...

$to = "user@email.com";
$subject = "database submission";
if($$DBquery = mysql_query($SQL)){ $message = "Success! You are from $country"; }
else{   $message = "FAIL! Nobody cares where you're from"; }

mail($to, $subject, $message); 


---

As for dealing with variables from different sources (I assume you're talking about naming conflicts, etc., at least in part), you could prepend each variable name with something unique - e.g., $DB_varname would not be confused with $INC_varname . You could also use classes (object-oriented programming), but that would mean re-writing your site again. :p

I'm not sure I quite grasp the concept of OOP. I do use a class.phpmailer.php for the emails, as they are separate html files. I'm not sure what OOP would look like. I believe I use what would be called modular programming methods. I am basically trying to make sense of this guy's code by undoing his penchant for copying and pasting code all over the place by gathering duplicate code and putting it into includes so I can get an overview of what is happening. It is a live ecommerce site so it is disastrous if I break something. Needless to say, I am eager to get it finished and be able to register_globals off because every time the host upgrades the php, all the site variables (dates etc) go blank. The owner loses money every minute it is down... no fun.

It is still not clear to me what happens if a variable exists and has a value out of the database. For example: $country = "US"; Now what happens if it encounters in an include $country = $_POST['country'] and there is no POST value for $country? Does it retain the value "US" or does it get blanked out?

BTW, what are these... \x00, \n, \r, \, ', " and \x1a. and why would they be dangerous if they got loaded in with the data? Mahalo, e :)

Those are characters that could potentially mess with the query, such as adding "; delete database;" to the end of a query-- that would be bad.

If $country is set to something else at any time, then, yes, it would have a different value. If $_POST['country'] is not set and you try to set it this will generate a warning (error) if the error reporting settings are high, but it will probably reset the value of $country-- I think this is the case. You could always do an if-- if (isset($x)) { $y = $x; }
But it sounds like this is a case where you need to: 1) plan ahead (to predict exactly what the pattern will be), and 2) name variables specifically and consistently.
Should $country get the value of $_POST['country']? If so, good. If not, change the name of one of them.
And turning off register_globals would help here too.


OOP is not needed, perhaps never needed. It just makes things easier if you are doing repeated sets of repeated operations.
A class is an "object" in the sense that it has internal properties and internal functions.
Functions make repeating sections of code easy. Classes make doing SETS of functions easy and acting on an "object" the same way as other objects.
For example, you could make a "tree" class and apply internal functions to it-- $tree->grow(); $tree->growfruit(); $tree->die();
It would be useless if you only have one tree, but if you want to have a lot of "trees", then making a class for "tree is efficient.
But again, you never actually need this, and it is probably more work than you need to do, unless you are planning to reuse the same code (in a very big sense) for a number of instances of a certain type of object (in the metaphorical sense, but also the "O" of "OOP").

OK, thanks, that's a relief that I can skip OOP. I'm just going to try what I have in mind and see if it works. I found this cool code snippet in the comments on your link re mysql_real_escape which I added to my connection code which I think makes it so all POST variables are escaped without my having to do it explicitly in the code...

Code:

---

//This stops SQL Injection in POST vars
foreach ($_POST as $key => $value) {
 $_POST[$key] = mysql_real_escape_string($value);
}

---

Yes it does, but I would do:

PHP Code:

---

//This stops SQL Injection in POST vars 
foreach ($_POST as $key => $value) { 
 $_POST[$key] = mysql_real_escape_string(htmlentities($value)); 
} 


---

Kuau,

Sorry, I wasn't suggesting you switch to OOP. Sorry for alarming you :). I was only referring to how each variable's scope would be limited inside a class, therefore eliminating possible conflicts from different files. But it's certainly not necessary or convenient in this case.

Another way to accomplish that same goal is to use arrays:
$item1['country'] = 'USA';
$item2['country'] = 'Canada';
etc.

That way you can use the same names (that are logical), but keep them separated by the "object" you are using. This would require nothing more than the code above.

I am making great progress but I have hit a snag at this one line. I can't figure out why it is not giving the correct value for $filter. I need sleep so my eyes just can't see it at the moment. This line:

Code:

---

$filter = "agency = '".$_POST['Agency']."' "; echo $filter; exit;

---

produces this: agency = ''

I've tried $Agency and $_POST['Agency'] and still the same even though when I run debug it shows $_POST['Agency'] = "Alamo";

What am I missing? Thanks, e :)

...Are you sure its "Agency" and not "agency"?

Maybe try what we discussed above and see what happens

PHP Code:

---

$agency = $_POST['Agency'];
$filter = "agency = '$agency'"; echo $filter; exit; 


---

?

Just a guess. Other than that, I'd have to see the code.

That syntax is correct. Something must be wrong with the variable names (or how it was sent originally). At some point in there, "agency" (in one of its forms) was blank.

Turn on error reporting to the highest level and you will get warnings when you are calling a variable with no value or an array with a key that does not exist. It will tell you the line number so you can track it that way and find out where it is being lost.

http://www.php.net/manual/en/functio...-reporting.php

At the beginning of your script, add:
// Report all PHP errors
error_reporting(-1);

You can also change the setting in php.ini, but this way it will just be there for debugging. Find the errors, fix them, and once the page is ready to go, remove that line again and the users won't see any extra errors (or back to the original setting, at least), so that you can debug but they don't get worrying, confusing notices.

Though it is always a good idea to fix all errors and notices, some of them do not actually "hurt" anything, but instead just make it confusing because php can guess and work around them. Basically if you use a variable that doesn't exist it will use an empty string instead (why you're getting ''). If you have this kind of problem and then don't show the notices (low level error reporting), then the users won't know the difference and the script will run fine (most likely), but it will be more difficult to debug.
So, if you turn that on and find many things wrong with the script, then just fix the ones that are actually causing you problems. Then you can remove that code again and it'll go back to how it was. If you have the extra time, fix the extra problems too, but it's not crucial. (More important later if you are expanding the script, or someone else is working on it.)

Hi traq: I did do the whole thing your way, ie. setting all the $_POST variables to plain variables first, but was desperately trying anything to get it to work.

$Agency is correct, but good eye that you caught that change. Through this process I discovered that I had been using one variable for two different values and had to introduce $Agency to represent the short name. But you did draw my attention to the possibility that the variable name was wrong and, sure enough, the script that creates the drop-down boxes was still using the old name, so I changed it to $Agency and now everything works like a charm. I'm about to make it live, which is the real test... I'll let you know what happens. :)

Hi Nile: I removed that code when things weren't working, but as soon as I have everything live and functioning, I'll reintroduce it and try your addition... thanks! :)

Hi Daniel: Great advice, which I will try in a bit. The owner's waiting for me to make it live right now so I have a feeling I'm going to need it very soon haha. :)

Miracle of all miracles, I made it all live without a hitch! Thank you guys for all your help... I could never have done this without you. Daniel, I even understand 99% of the code thanks to your great explanations and homework you give me! I still have some modules in the Admin Panel to do, but the main functions are done... yea!!

After all the modules are done, then I need to try turning Register_Globals off and see how I really did haha. I'm sure it will crash and burn, but it feels good to get this far. Thanks a million for being there. I wish I could give you a big hug. :)

I sure hope you guys are there because I am in a major emergency on the live site. Nothing is working because I am getting this error message but cannot find the error...

Code:

---

Parse error: syntax error, unexpected '=' in /home1/mauiretr/public_html/_car/php/add-agency-logos.php on line 5

---

There is no equal sign that seems to be incorrect. Here is the code...

Code:

---

if($selection == "best"){
  sql = "SELECT agency_id, agency, agencyname, logo FROM `agency` WHERE `agency` = $Best_Rental ";
  $result = mysql_query($sql,$connection) or die("Couldn't execute $sql query. <br> mysql error: ".mysql_error()); 
  $row = mysql_fetch_array($result);
} elseif($selection == "all"){
  sql = "SELECT * FROM `agency` WHERE `agency_id` = $_POST['agency_id'] ";
  $result = mysql_query($sql,$connection) or die("Couldn't execute $sql query. <br> mysql error: ".mysql_error());
  $row = mysql_fetch_array($result);
} elseif($source == "cp" || $source == "cancel"){
  sql = "SELECT agency_id, agency, agencyname, logo FROM `agency` WHERE `agency` = '$Agency' ";
  $result = mysql_query($sql,$connection) or die("Couldn't execute $sql query. <br> mysql error: ".mysql_error()); 
  $row = mysql_fetch_array($result);
}

$Best_Rental = $row['agency'];
$agencyname  = $row['agencyname'];
$Car_Logo    = $row['logo'];

---

Please help before the owner freaks out!!! Thanks. e :)

$sql =

mistyped twice in your code

Dear bluewalrus:

OMG! Duh! 3 times actually (from copy and paste). Thank you so much!!! I have been up all night and cannot even see straight.

Talk about misdirected attention. :) e

Parse errors are special: this means that upon the initial scan of your code, the php engine did not know what to do with it. There isn't something "going wrong" as the code is run, but it's actually unintelligible from the beginning. This usually makes it easy to find because it's almost always a typo or misplaced bracket, etc. The only problem is that frequently parse errors don't tell you exactly where to look because it only knows there's a problem when it gets to something it doesn't understand. For example, if you are missing a bracket and it reaches the end it will give an error (unexpected $end) for the last line, regardless of where the actual typo is. Still, though, this makes debugging clearer. Hope that helps next time.

Hi Daniel:

I am really starting to "get" this stuff thanks to your great explanations. Now that the panic's over I can put the code back to the way I like it with the least amount of redundant code. One thing I'm not sure about is when you have to separate the variables from the SQL. Which is the best practices way of saying agency = $Best_Rental;

Like this? "... WHERE agency = '$Best_Rental' ";
OR this? "... WHERE agency = ' ".$Best_Rental." ' ";
OR this? "... WHERE agency = $Best_Rental ";

Also is "||" exactly equivalemt to "OR" and does it matter if you use one or the other? Any advantages either way? Thanks, e :)

I never write "OR". I believe it is functional, but using || is much more clearly a "symbol" rather than text (content). There should be no difference in function, though.

All of those work for the mysql statement, though there's a mistake in the middle one.
You have spaces between ' and ", and that will cause it to never be equal to that. When comparing something in mysql spaces do matter (as they do in most strings, but not code).

Which one you want to use is your decision, but:
1. Double quotes ("...") take longer to parse because they can have not just text but a few other things, like variables in them.
2. Using variables outside the string is probably a better idea ("...".$var."..."), but only for really organized code: double quotes are designed to have variables inside them.
So, you really have two good options:
1. "agency=$Best_Rental"
or
2. 'agency='.$Best_Rental.'........'

I always use single quotes like in (2) because they parse faster (honestly, a very small difference, perhaps irrelevant), but also because they never do unexpected things. In single quotes '$var' stays as the STRING dollarsign-var, not parsed as the value of $var. This means that "what you see is what you get" when it's in single quotes. I like that.
So then of course I have to exit the quotes and append any values with the dots.

Double quotes are faster to type though, since you don't need to exit the string.

The other problem with double quotes, though, is that it ONLY parses variables (and a couple other things), so if you need anything else (for example, a function), then you need to exit anyway. That's yet another reason I stick to single quotes.


As for having the single quotes within the MySQL statement, that's a good idea, but unrelated to the php.
MySQL, properly formatted, looks like this:
`agency` = 'BestRental';
Many (most?) people are too lazy to write that, though, so they write:
agency = 'BestRental';
Some people write even:
agency = BestRental;

The last one is a very bad idea. The single quotes in the mysql act to tell mysql what the value is and what the mysql code is. If not, it has to guess (it might even give an error in some cases, especially if it the value has text like ; or = in it, or maybe just spaces).

And don't forget to have mysql_real_escape_string() somewhere in your code.
You can do it directly in the query if the line doesn't get too long.
So, the most proper way you can write that is:
$query = '....`agency`=\''.mysql_real_escape_string($Best_Rental).'\';';
If you have already done the mysql escaping, then just use:
$query = '....`agency`=\''.$Best_Rental.'\';';

Note that you can use double quotes if you want to-- it makes it a lot easier to read than with the escaped (\') single quotes, but this is technically "best" as it is the fastest.

In the end, though, my recommendation is to do what works. If your code is working, don't worry about it. If you start to get 1,000 hits per day (or even per hour), then maybe it's time to start making your code super-efficient. If not, it won't make any difference to anyone.

I've always preferred single quotes to double quotes, not necessarily for the speed improvement (as daniel says, it's almost unnoticeable), but for the simple fact that I'm making the code as straightforward as possible.

The sole exception to my habit is SQL queries.

I find that the format "...`agency` = '$BestRental'..." is the best balance (for me) between being "technically correct," providing predictable results, and being easy to type/read.

Wow, I'm going to need some time to digest all of the above. Thank you both for sharing your knowledge of what works best. Daniel, could you please do me a favor and clarify the places halfway down where you used 'BestRental' without the $ before $Best_Rental. Did you mean to do that? I'm not sure if your example is using it as a variable or as literal text and I'm really trying to understand exactly.

I was under the (possibly mistaken) impression that it was considered bad form (in the sense that eventually code written like this will be deprecated and no longer work) not to separate the variables from the string. I much prefer traq's

"... `agency` = '$Best_Rental'..." to
"... `agency` = '".$Best_Rental."'

which is the way I have been forcing myself to do it (and making myself crazy with all the quotes). It would be much easier. Really, is it OK to do it like that? I learned the '".var."' method from theTestingSite and was so proud of myself that I finally had it almost down. I put spaces above because it looked like 3 single quotes in a row.

Along the same line, I seem to recall something about having to use single quotes around values in the SQL query except if they are integers (?). For example, would you say "... WHERE agency_id = 1"; OR "... WHERE agency_id = '1'; ? Sorry if I seem kind of dense about this stuff. Did you guys learn php and mySQL in school?

Thanks so much for your patience and kindness in helping me. I've pretty much been doing the code and pray method from the start. :)

The single quotes in the query is if it is a string, not a value. If "1" were "one" you'd use the single quotes you could use the single quotes around the 1 but I think that'd make it treated like a string.

For more info (Not for the where statment but for the syntax)

http://www.sql-tutorial.com/sql-where-sql-tutorial/
http://www.w3schools.com/Sql/sql_where.asp

Quote:

---

Originally Posted by kuau

"... `agency` = '".$Best_Rental."'

---

Leaving a double-quote string and using dots to add a variable is counter-productive. Yes, it works, but there's no point in doing it that way. I hope I can explain:

Doing it this way makes sense: 'This is a '.$string.' with a variable.'; . You exit the literal (single-quote) string and add a variable, which will be parsed and have its value added to the string.

Doing it this way makes sense: "This is a $string with a variable."; . You just leave the variable inside the dynamic (double-quote) string, which is automatically scanned for variables and parsed, adding its value to the string.

Doing it this way makes no sense: "This is a ".$string." with a variable."; . The double-quote string is parsed for variables (but there aren't any), then exited and the variable is added, then the next half of the string is parsed for variables (but there aren't any).

Edit: To answer your other concern, I haven't heard anything about this format being in danger of becoming depreciated. But I haven't bothered to check, either. Where did you hear this?

Just to clarify about "BestRental", that was the string version of the text stored in your variable.

That was pure mysql, after php had generated the string. Once your variables, operators, etc are parsed, you get a final string (including commands and string values) to be used as a query.

The examples above are of that expected/desired output. On the surface the PHP will look more complex (with variables, etc.). The lines following that (with the $ again) show what it will look like in the actual php.

Always remember that php is always generating something-- so you need to know what the php is doing and ALSO what it is generating and what that then is doing.
As the simplest example, <?php echo '<html></html'; ?> is both php and then generated html. For the final page to work, both need to be correct.
So, again, the above is just the generated mysql in the proper format-- then you need to go back one step and actually generate that with php (including using variables to generate the string values).

The format I type my mysql statements in is always the most complicated format. It's tiring to always type it all out, but I do it for a simple reason: I don't trust mysql. It's always done strange things to me (and I'm sure it's been the fault of something wrong with my code, but that's beside the point), so typing everything as explicitly as possible, such as separating strings and variables with dots, is clearest to me. If not, things can get less clear and end up with mysql having a fit about something I wrote, and I'll end up cleaning it anyway.
If you find an easier way to type and it consistently works, that's just fine. If you start having trouble, take a step back and do it slower in the more explicit way. Few people type it as precisely as I do, but I like to-- it makes me feel like it's going to work, rather than throwing out an error for something I didn't predict.

Thanks for all the great responses!

bluewalrus: The tutorials were super clear...thanks! Now I have to go back and fix my code. I like to be totally consistent and it appears mySQL is fairly forgiving.

traq: Thanks for explaining. It really makes sense, especially after bluewalrus' tutorials. I'll work on developing a new habit. One question though is what happens in this case:

Code:

---

$sql = "SELECT * FROM customers WHERE lastname = '$lastname' ";

---

and lastname is O'Reilly. Wouldn't the SQL command be truncated? Or maybe if Magic_Quotes is on it might work (?).

The best thing is that your explanation made me able to understand Daniel's explanation above (the one starting with "I never write OR"). I probably misunderstood about Dustin using the '".$var."' method. He probably used it selectively and I applied it universally because I didn't truly understand. No one told me it was being deprecated.. it was just because adding $_POST variables seemed to correct some of the problems when the site broke when the host upgraded (Register_Globals was turned off) and that was the method he used in the examples he gave. It was no doubt a wrong assumption on my part. The only thing I think I might know :) is that the word is "deprecated" not 'depreciated.' I noticed both you and Daniel say 'depreciated' -- maybe you can use both, but this is the definition in Wikipedia: http://en.wikipedia.org/wiki/Deprecation

Daniel: I totally get why you do it the way you do it. Maybe once I get better with quotes I can do it that way, but at the moment those escaped single quotes throw me for a loop. But at least I know what to aspire to. I'm still at the point where I need to look at the code and be able to follow it. I'm not sure what \' is or does. It isn't in the same position as where I put the double quotes, so it is a bit confusing. I better stick with double quotes for SQL queries and single quotes elsewhere for now. When all the code is working, perhaps I can go back and do a search and replace

I have a question about variable scope. If you have a page with a POST form that goes to a result page when you press the Submit button, are the POST variables from the first page considered within the scope of the result page? And if so, are they availlable to files called from the result page?

Mahalo! aa :)

For the question about the O'Reily name example, that is why you use mysql_real_escape_string. I think that should fix any sort of input conflicts in mysql (definitely quote-related problems). If you don't use that, O'Reily is the last of your problems.

Escaping is extremely simple. In every language (that I can think of at the moment), a backslash goes before the character you want to "escape". This takes away it's "symbol" property and makes it just plain text.

"$var" is the VALUE of $var.
"\$var" is the string '$var'.

Escaping can be done on most characters that have functions.

The most common is with quotes. '\'' is a single quote string. "\"" is a double quote string.
Of course it looks prettier to write '"' and "'", but it's possible to do it either way.
Any content quotes need to be preceded by slashes when the symbol quotes around the string are the same type (single or double).

One of the easiest ways to work with this is to get a code-highlighting editor, like notepad++ or dreamweaver (and many, many more) and playing with this.
Type 'can't', and you will see that all of the text AFTER the string is not some odd color because the ' in can't is messing up the string endpoints. Just add the slash and 'can\'t' will be back to normal.



Scope does not extend beyond a single page load. Scope is within a single level of code on a single processing of a page. Of course you can have includes, etc., that then are embedded and use the same scope, but this is effectively the same processing.
The exception is with $_SESSION variables (and cookies) because those are, in a complex way, specifically kept and transmitted from one page load to another.

The question about post is backwards: those are NOT post variables in the form. Those are form inputs in html. Once that form is sent, it is sent by the browser through the "post" method. (Before that they are just text on the screen.) Then the PHP parser gets the page request along with the post variables and it then has them around as variables.
So they are only in $_POST on the second page, because that's when they become "post" variables-- before that they are just text entered in textboxes, etc.


--
Depreciation/deprication: that's really strange. Everywhere I've ever seen it, it's spelled depreciated. According to the wiki article, that's backwards.
Regardless, it means that something is old and being replaced, so it's not a good idea to use it either because there is a better way or it will be removed in future versions.
This is specially for changing circumstances, though-- it was good coding practice at one point and now it is not any more.
I always thought it meant "de-preciated" in the sense of "appreciated less" (or something meaning similar to that), rather than "deprecated" which means more or less "discouraged". That is-- I thought it was just not popular any more, rather than actually considered "bad". (By the meaning of the word.)
I suppose that deprecated actually makes sense though.

I see the term used a lot on php.net for examples. From a google search, "depreciated" is apparently found about 200 times, but "depricated" about 8000. I have no idea why I never noticed that. Thanks for pointing it out.
But remember-- if you ever see it spelled the wrong way (for programming), it means the same thing. It's just one of us who has no idea what we're trying to spell. Haha. (And I study languages/linguistics...)

Dear D: I experienced the (rather alarming) color change when I was going through the code in DreamWeaver replacing double quotes with single. When it's in the middle of a word like "could'nt" it's easy to follow, but for me your earlier example is a bit abstruse. I can't tell if the \' is around `agency` or around mysql_real_escape... my brain seizes up haha

Code:

---

$query = '....`agency`=\''.mysql_real_escape_string($Best_Rental).'\';';

---

Yeah, my understanding of POST was backwards (duh!). :) So if you want to use the variable values beyond the result page, you have to save them to the database and then load them back into variables? I actually considered saving the values right away and reloading them in order to to avoid working with the POST version of the values. Would that have been dumb?

I think of 'deprecation' as being phased out. You're right that it was once more appreciated, but it is usually something that has become a security risk due to the changing times. It is interesting to observe how the human mind can change what we see based on what we expect to see. It may surprise you that this is the link to which you sent me when you were helping me with functions. :)

http://php.net/manual/en/function.eregi-replace.php

As always, thank you so much for your excellent tutelage. Have to go running now. e :)

Yes, complicated strings with escaped characters can get messy. Don't try to write them quickly or in one try. First, write out what you want, then add back in the parts that need to be escaped. Beyond that, just get used to doing it and it won't be so difficult after a while. It never gets brainless, though.

I'm not sure what you mean about skipping post variables. This is not possible. The values are in a form and submitting that form means submitting that data as post data. Then the server parses it. You can't get around that, or it will have never been on the server in the first place. You have to remember how all of this works: the browser is relatively independent of the server and vice versa: the few useful things like post are all that we have to use to get things done.

And, yes, if you want values available for a later page, you must use another method. Typically databases are used, but there are a few options:
1. Temporary: cookies and sessions. Sessions are great (and cookies are generally fine), but they only work for a certain time. If you just need it available on the next 5 pages, or for just that "session", use these.
2. Permanent: databases, "flat files" (text files on the server), etc. These are ways of actually storing the data in a permanent location on the server so that it can be accessed at any point.


The only other way to get the same post data on another page would be to send it again. Though that may not work, it does sometimes: you could pass a value or two (hopefully not 50) as hidden fields on the next page, or if there is an error in what they entered you could just give them the same form back while filling in the values with the post values:
<input name="X" value="<?php echo $_POST['X']; ?>">
(but you'd want to check that isset($_POST['X']) before doing that, to avoid the E_NOTICE error if not.)

"POST" variables are not really a 'type' of variable as much as they are a format for variables. The same variable can be in a form field, post data, get data, or in a database, and you can move it from one to the other with PHP as you desire. (Of course technically you would be using different "variables", but referring to the same value.)