PFMaBiSmAd

A) All of those notice messages are slowing down the execution of your code because php must still handle each one and try to figure out what to do with it even if they are hidden by the error_reporting/display_errors settings and if log_errors is ON you are continually adding to your error log file, and B) one or more of them are probably pointing to the area in the code that is not working that is causing the 500 page error (which basically means that the web server did not output a complete response.) Code should not normally generate any php errors when it executes so that real errors that do occur can be found. I would find and fix the problem causing each error. If You find that some of the undefined errors are due to program variables that are no longer set from external data or session data, then you have a register_globals problem in the code that needs to be fixed (register_globals have been completely removed in php6, so that turning on the setting is just a short term fix.)

Everything you have shown says it should work. I suspect there is something on the page in the portion of the code that you have not shown that is either prevented the error_reporting/display_errors code from exposing an error or is causing the problem (such as the page redirecting or being requested twice...) Could you post the whole code. xxxxx out any sensitive information, such as the database hostname/username/password, but it is not necessary to hide table and column names (assuming your code is protecting against sql injection.)

The getcwd() appears to be correct. This sounds like a open_basedir/safe_mode problem (your php code cannot access the file, but the web server can when the browser requests the image.) What does adding the following two lines of code immediately after the first opening <?php tag show - ini_set("display_errors", "1"); error_reporting(E_ALL);

Have you echoed $item_benefit_1 to see what exactly is in it? Anything unusual on the server, such as url_rewriting or an add on doamin that could make the actual path where the files are at different from where they appear to be when accessed using a URL (assuming that when you remove the file_exists() test that the page works...) What does the following show - echo getcwd(); echo $_SERVER['DOCUMENT_ROOT'];

Is the code you posted being included by another page that is at a different path relative to where the images are at?

There is (another) fatal parse error on line 39 due to a missing } You should be learning php, developing php code, and debugging php code on a system with error_reporting set to E_ALL and display_errors set to ON in your master php.ini so that php will help you by displaying all the errors it detects. You will save a TON of time. Stop and start your web server to get any change to the php.ini to take effect and use a phpinfo() statement to confirm that the settings were actually changed (in case the php.ini that you are changing is not the one that php is using.)

File_exists() expects a file or a directory and does not work with most URL protocols - http://php.net/file_exists It does not work with http/https URL wrappers. You would need to use a local file system path in file_exists()

Set error_reporting to E_ALL and display_errors to ON in your master php.ini. Stop and start the IIS service to get any change made to the master php.ini to take effect and use a phpinfo() statement to confirm that the two settings were changed. This will cause all php errors to be reported and displayed, which will likely tell you why the code is failing. No guessing is necessary.

The following line of code is what appears to be responsible for setting $user to an instance of an object (immediately before the line where the error is occurring) - $user = get_entity($user); It would take seeing the code in the get_entity() function to be sure, but it may be intentionally returning a FALSE value instead of an object and the main code should be testing for that occurrence instead of blindly using the returned value. It also may be that there is a logic error in the get_entity() function that needs to be fixed.

A cookie behaves the way you mentioned, not a session. If you are in fact describing a cookie, you can always set the correct $_COOKIE variable to the same value you just put into the setcookie() statement.

http://www.phpfreaks.com/forums/index.php/topic,292878.msg1386240.html#msg1386240

Did you check using a phpinfo() statement that the output_buffering setting was actually changed (in case the php.ini that you were changing is not the one that php is using)?

Because there is no corresponding day (the 30th) in February. Instead of using 'now', use the first day of the month (or at least a day that exists in all months.)

It's likely that your server has this - http://www.hardened-php.net/

You should be learning php (or learning anything new in php), developing php code, and debugging php code on a local development system. Constantly uploading code to a live server just to see what it does or if it works wastes a huge amount of time. If necessary, you can set those two values in a local php.ini (when php is running as a CGI application) or in a .htaccess file (when php is running as an Apache Module.)

Blank pages are usually due to fatal parse errors. In your case - You must set the error_reporting/display_errors settings before your script is requested in order to show fatal parse errors.

Then the path must be incorrect relative to the page that the code is on or the image by that exact name and letter-case (assuming you are on an operating system that is case sensitive) does not exist and the problem is not really a php problem anymore.

Php code must echo things in order to cause them to be output to the browser. <?php $image_path . "profile.jpg"; ?> outputs nothing (do a 'view source' in your browser to see what you are getting.) <?php echo $image_path . "profile.jpg"; ?> will output whatever is in $image_path concatenated with "profile.jpg"

Those are generally (~90% of the time) sql syntax errors that have nothing to do with your mysql version. Mysql simply cannot figure out what you mean because you used a sql keyword or sql syntax in a location where it does not belong. The sql parser does not know what you, the programmer, intended (computers cannot read minds yet) and cannot distinguish between your wrong syntax and perhaps a feature that exists in a different version. These are usually caused by using a reserved keyword as a column or table name or by using the wrong syntax for what you are attempting (such as using the syntax for an insert query in an UPDATE query...) If you have a specific error that you need help with, you would need to post the error and the code or query responsible for the error.

It's got something to do with the evaluation of the expression being concatenated within the string. The following corrects the problem - echo '<img src='. $row[map] . '>'; echo '<img class="' . $row[username] . '" src="' . $row[figure] . '" >'; echo '<style type="text/css">'; echo '.' . $row[username]; echo '{'; echo "top: " . ($row[ypos] * 35 + $row[ypos] * 2 + 2) . ';'; echo "left: " . ($row[xpos] * 30 + $row[xpos] * 2 + 2) . ';'; echo '}'; echo '</style>';

$_FILES['uploaded']['name'] does not exist due to one of the half-dozen or so possible upload errors and your code has very little error checking logic in it (and some of it is not doing anything such as the size check because the variable $uploaded_size is not being set by your code.) See this other recent thread for some upload error checking logic to get you started - http://www.phpfreaks.com/forums/index.php/topic,292945.0.html

From the forum's rules - Why don't you reread your first post in the thread and ask yourself if anyone can tell what you want. Perhaps if you posted an example showing variables, values, and what the expected result should be.

[sarcasm]Oh no, not more time wasted by a php feature that was supposed to be a lazy what short cut to "help a few beginners blissfully and unknowingly write better (more secure) code."[/sarcasm] What is your current form processing code and the code that is retrieving the data from the database? What does a phpinfo() statement show for the magic_quotes_gpc and magic_quotes_runtime settings?

<?php if($_SERVER['REQUEST_METHOD'] == "POST") { // a POST form submitted to this code // check if the $_FILES array has something in it - if(empty($_FILES)) { echo "The file upload failed for one or more of the following reasons -"; echo "<ol>"; echo "<li>Uploads are not enabled on your server in php.ini</li>"; echo "<li>The form tag does not contain - enctype=\"multipart/form-data\" or something else about the form makes it invalid</li>"; echo "<li>There is no type=\"file\" field in the form</li>"; echo "<li>The total size of the data from the form exceeds the post_max_size setting</li>"; echo "</ol>"; } else { // the $_FILES array contains something // display any upload error - switch ($_FILES['file']['error']) { case 0: // echo "The file uploaded to the server OK<br />"; break; case 1: echo "The uploaded file exceeds the upload maximum size directive in php.ini<br />"; break; case 2: echo "The uploaded file exceeds {$_POST['MAX_FILE_SIZE']}, the MAX_FILE_SIZE directive in the HTML form<br />"; break; case 3: echo "The uploaded file was only partially uploaded<br />"; break; case 4: echo "No file was selected<br />"; break; case 6: echo "Missing temporary upload folder<br />"; break; case 7: echo "Failed to write file to disk<br />"; break; case 8: echo "File upload stopped by extension<br />"; break; default: echo "An unused error value was returned<br />"; } // end of switch/case if($_FILES['file']['error'] == 0){ // a file was uploaded without any error // use the uploaded file information here // put any type, size, file name/extension, or content validation here // The following will be set for the file - // $_FILES['file']['name'], $_FILES['file']['tmp_name'], $_FILES['file']['size'], and $_FILES['file']['type'] echo "Process the uploaded file here<br />"; } } } else { echo "A POST method form did not submit to this code<br />"; } ?> Checking the type and size separately means don't lump the checks together into one logical test with one common generic error message. You will be forever guessing why the upload failed.

Yes, you have got to check $_FILES["file"]["error"] to see if the upload was successful before you can check any of the other values associated with the upload. There is also an upload error condition where the $_FILES array will be empty if the size of the uploaded data exceeds the post_max_size setting. This error condition should be checked first. Then, the validation checks for the "type" and "size" should be done separately with different error messages that tell you exactly which test failed and why the check failed, including displaying the actual "type" and "size" values that failed so that you get feedback as to what was wrong with the value.