PFMaBiSmAd

^^^ Why do you think you need to do that? You and your code should not care. It should simply iterate over the entries in the array.

The information posted by Anti-Moronic in this thread has nothing to do with your problem of putting " into a form field value.

$row[Y] expects there to be a defined constant named Y. Php first looks in the table of defined constants to find what the constant Y equates to. When it does not find the constant Y, it invokes the error handler to address the non-existent constant. If you happen to have the error_reporting/display_errors/log_errors settings turned on, you will see an error message about the undefined constant. Php than (in its brilliant wisdom) assumes that you meant to put quotes around the array index name and tries $row['Y']. It then does the normal lookup of the array index named 'Y', the same as if you have wrote the code correctly and put quotes around the array index name. So, yes each time you leave off the quotes around an array index name, it probably takes at least 10x longer to reference that variable than if you had written the code correctly.

Yes, don't send an email from your mail server. More seriously, why is this a problem? An alternative would be to send the email directly to the client's email account by him giving you his password to his email account so that you can use SMTP Authentication and send the email directly from the php script to the receiving/client's mail server.

No single-quotes around php variables as that would make $itemlisted the string made up of the characters: $ i t e m l i s t e d - unset($_SESSION['items'][$itemlisted]);

Aside from the fact that you are allowing all the mail() parameters (to, subject, message, From: header) to come from the posted form data (spam bot scripts will love your script and get your mail server banned by all the major ISP's fairly quickly) you are setting the From: address to be the arbitraryly entered email address from the form (which is probably why you are likely triggering your mail server's SMTP Authentication requirement.) You must set the From: address to be an email address hosted at the sending mail server. You would set the Reply-to: address to be the address the visitor entered.

I'm going to vote for this choice as being the likely problem - You haven't shown any code, so it is not possible to tell if what you are attempting is even valid. Based on your other thread about SMTP Authentication, does your sending mail server require it? If it does, there's no way you will be able to send an email through your mail server until you use a php script that supports SMTP Authentication. Edit: And frankly, you have at least two-three current threads about sending email. If you stick to a single thread for any particular problem, you will find that you will get a solution faster.

You never do anything with the error messages, so how would you expect your code to display anything? Computers only do exactly what their programs tell them to do. If you set a variable but don't do anything with it in your logic, you see no results.

The same way you do it for any variable - $_SESSION['some_name'][] = some value;

No it's not. You have edited it since then to correct the syntax errors that were present due to the echo = statements. Who knows what else you have altered in it or even what you changed the echo = statements too.

If the problem are the BOM characters that your editor is placing at the start of the file, the solution is to save the file without the BOM characters. If your programming editor does not have an option to change the file encoding to UTF-8 without BOM or to ANSI encoding, you will need to use a better editor.

Without seeing your current code that produces the current symptom, no one can directly help with what it is doing.

All content (anything that is not intentionally HTML tags/HTML syntax) that you output on a web page needs to be passed through htmlentities with the second parameter set to ENT_QUOTES so that any HTML entities in it, like &, ", ', <, and > don't break the HTML on your page. Also, the value='...' attribute of a form field (all attributes in fact) need quotes around it to make it valid HTML.

Just posting 4 lines of code out of context almost never results in a solution because that is not all of the relevant code that is producing the error.

Did you read the godaddy information or contact them about this -

If you need it to be in a session variable, then yes.

You would use explode to break the string into an array at the commas. Then you can easily alter just the second element. Then use implode to put the string back together.

The OUTPUT is on line 1 of that file. Either you have an actual character in the file before the <?php tag or the output is the BOM characters that your editor saved at the start of the file. See the last post in this sticky thread - http://www.phpfreaks.com/forums/index.php/topic,37442.0.html

If it always cuts off at some white-space, it is likely that your HTML is invalid. What is your code that is displaying the results?

This line is incomplete and is breaking your HTML - <option value='0'>Choose an option It should be - <option value='0'>Choose an option</option>

The error message tells you where the OUTPUT is occurring AT (or where the end of the output is at) that is causing the problem. Fixing this would involve eliminating that output or changing the logic to move the statement using a header() so that it is before any output is sent.

LOL, its because the key that was pressed is entered into the textarea after the onKeypress() event. See this link - http://www.sencha.com/forum/showthread.php?49376-Linefeed-left-in-Textarea-after-reset-or-setvalue Use onKeyup() instead of onKeypress()

^^^ Obviously, not. What does var_dump($_SESSION); show, immediately after the session_start(); statement?

You would pass the values for $region, $city, $interests, $experience, and $sortby as separate $_GET values in the URL. Passing the whole or part of the query in the URL would be a security hole because anyone could alter it to inject sql. You would need to completely validate the passed query before using it and that would take many time more code than if just the values are passed. I also notice that your code contains some duplicated code to build the two queries in it now. You need to consolidate and simply to avoid multiple copies of the same code in one script. The only difference between the two queries is the first one uses count(*) and has no LIMIT clause and the second one has the actual SELECT list and does have a LIMIT clause. You should build the middle part of the query only once in the code and reuse that in both queries.

Are you doing this on a system with error_reporting set to E_ALL and display_errors set to ON so that all the php errors would be reported and displayed? At a minimum, your code should be producing a warning at the second session_start() statement and might in fact be producing errors that would point to the reason why it is not working as expected.