PFMaBiSmAd

I also recommend using double-quotes to start and end your query string (so that you can put single-quotes into it without needing to escape them), then use the simplest (fewest changes) syntax within the query - $query = "UPDATE websites SET designerid=$designer, clientid=$client, title='$title', url='{$_POST['url']}', description='$desc', designbrief='{$_POST['designbrief']}', needs='{$_POST['needs']}', files='{$_POST['files']}', `databases`='{$_POST['databases']}', version='{$_POST['version']}', commissiondate='$commissioned', deadline='$deadline', status='{$_POST['status']}', finishdate='$finished', price='{$_POST['price']}', previewurl='{$_POST['previewurl']}' WHERE id = {$_POST['id']}"; You table definition also has a few problems - 1) The length of an INT cannot be more than 11, so INT(20) has no meaning. An unsigned BIGINT can have a length of 20. Is that what your INT columns actually are? 2) Your deadline and finishdate columns appear to be for dates/time. Please use a DATE or DATETIME data type and put the correct formated values into them. 3) Your price column should be a DECIMAL data type of the correct length. Finally, I hope you are using mysql_real_escape_string() on all string values and either validating or casting the numeric values being put into the query in order to prevent sql injection?

Browsers don't make up HTML code. The form you are browsing to that has an action attribute of action="uploader2.php" also has a submit button with a name attribute of name="upload" You would need resolve your different forms, actions, submit button names, and the names of the variables you use in the form processing code. Your description field in the form code you posted did not show up in the output from the print_r() instruction, so clearly (again) the form you are browsing to is not the form code you posted in this thread. The form code you did post in this thread produces the following output from the print_r() instructions (for all empty form fields) - POST:Array ( [MAX_FILE_SIZE] => 200000 [username] => [rendername] => [description] => [upload2] => Upload Render ) FILES:Array ( [userfile] => Array ( [name] => [type] => [tmp_name] => [error] => 4 [size] => 0 ) )

Post your code. There are a lot of php coding examples posted around the Internet and in old books that don't following current recommend php.ini settings and don't work on current installations of php.

Just because you can echo/print_r a variable named $_SESSION, does not mean that variable is part of a session, if the session_start did not actually start a session or you are closing the session before the variables are assigned values or you are doing something directly with the session id cookie... There could literally be two dozen different things that could cause the symptom you are describing. Here is just one of them -

And confirm that sessions work using simple test code. If sessions work, then that would mean there is something in your code that is causing the problem. It actually sounds like your page is being requested twice (either by the browser or due to code being included more than one or a redirect) or you don't have an exit statement after a header() redirect and the code itself is clearing the session variables.

Add the following lines of code immediately after your first opening <?php tag and before the session_start() statement - ini_set("display_startup_errors", "1"); ini_set("display_errors", "1"); error_reporting(E_ALL);

If you covert your array into a comma separated list, you can use the IN() function - http://dev.mysql.com/doc/refman/5.0/en/comparison-operators.html#function_in

Based on the line number where the error is occurring (line 3), you have at least one carriage-return/line-feed before the <?php tag. You cannot have any characters in your file before the <?php tag when you have a session_start() or a header() in your code. This includes, but is not limited to - a space, a tab, a carriage-return/line-feed, a doctype declaration, any other HTML, any other printing or non-printing characters, or the BOM (Byte Order Mark) characters that some editors place at the start of a file saved as UTF-8 format.

This is from the printout you just posted - [upload] => Upload Render That clearly shows that the form is setting a submit button named upload Have you refreshed your form page in your browser after making any changes to it so that those changes would be reflected in the HTML?

The form code you posted above is not the form you are actually using. The form code you posted is using upload2 as the name of your submit button and that is the name that your form processing code is testing for. The form you are actually using has a submit button named upload, so your form processing code is skipping over the if(isset($_POST['upload2'])){....} conditional code.

Debug what you are getting by adding the following lines of code immediately after the first opening <?php tag in upload2.php - echo "<pre>"; echo "POST:"; print_r($_POST); echo "FILES:"; print_r($_FILES); echo "</pre>";

mysql_numrows() is an old depreciated alias of mysql_num_rows() and would have no direct bearing on the problem. Please debug your code with error_reporting set to E_ALL and display_errors set to ON so that php will help you by displaying ALL the errors it detects.

What data type is post_date? You can only do greater-than/less-than (i.e. BETWEEN) date comparisons when the format can be comparied by magnitude (i.e. yyyy-mm-dd or a Unix Timestamp) which is why the DATE and DATETIME data types store dates as yyyy-mm-dd. If $sdate and $edate are 'yyyy-mm-dd', they are already in the correct format for the comparison and you don't need to use STR_TO_DATE on them. You should store post_date as a DATE or DATETIME data type if you expect your database queries to function efficiently.

Your code relies on both register_globals and session_register() (and probably session_is_registered() and session_unregister()). All of these were turned off by default in php4.2 in April of the year 2002, over 7 years ago. All of these have also been completely removed in php6, so now is the time to update the code to current php standards.

That error has nothing to do with sessions and a header() on the same page. It has to do with your code sending output before doing something that requires the use of a header - output started at /mail_send.php:10 (line 10)

Function definitions need the function keyword at the start of them.

ShadowIce, are you even reading the questions in the threads? You have recently replied in three threads other than your own and in each one you have posted information that does not match the question that has been asked.

The question that was asked concerns a specific format, not the format you posted. The format you came up with is also unusable for direct database operations and takes more storage space in a database.

The 'topic solved' modification has yet to be installed in the upgraded forum software.

What the YEAR() and CURDATE() functions do can be found in the documentation - http://dev.mysql.com/doc/refman/5.0/en/date-and-time-functions.html

It's almost always best and faster to perform an operation using mysql funcitons directly in a query - $query = mysql_error("UPDATE Users SET Used = YEAR(CURDATE()) WHERE username = '$username'") or trigger_error('Query failed: '. mysql_error());

Doing this will allow your site to be taken over by a hacker because that is one of the first things they will try (anyone can provide a cookie with any name or value in it when they visit your site.) If someone is an administrator, should only be determined by a value you have assigned to specific usernames on the web server. The setcookie() function contains a DOMAIN parameter. You need to set it to .yourdomain.com (the leading dot should be used) so that all variations of your domain, both with a www. and without a www. will match the cookie. You also need to set the PATH parameter to a / so that cookies set in any path on your site will match all the paths. Ref: http://us.php.net/setcookie

Best guess is that you somehow got a non-printing character typed into the code.

Blank pages are either caused by code that contains a fatal parse error (a parse error will prevent the code on the page from being executed) or by code that does not output anything on the page. If both your if(){} and else{} statements output something, it is likely you are getting a fatal parse error. Are you developing and debugging your php code on a system with error_reporting set to E_ALL and display_errors set to ON in your master php.ini (and you have verified these settings using a phpinfo() statement in case the php.ini that you are changing is not the one that php is using) so that php would display all the errors it detects?

The posted code cannot produce that error (if the posted query executes so that $result is a result resource, there would be an 'id' index.) It would take seeing your whole actual code to be able to determine what is causing the error. I suspect you have different $query/$result variables and line 46 is doing something else.