Are Hidden Variables $_POST variables?

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.)