PFMaBiSmAd

As de.monkeyz stated, it takes extra processing each time you use an un-quoted index name (at least 10 times longer) because php first searches the defined constant table for a match, declares a NOTICE: level error (even if the error_reporting/display_errors settings hide them), decides you might have meant to use a quoted string, then searches for the quoted index name. By disabling any of the error_reporting settings, you also prevent logging of real problems that occur, such as when a hacker feeds your script all kinds of unexpected data that your validation logic does not detect. Code should not normally generate any kind of php errors when it executes, only for unexpected conditions.

The autoreturn URL is specific to one buynow button and it is static. I would use something like http://your_domain.com/return.php?id=x for the URL (where x is different for each buynow button, so that you can use a single file.) You would need to put code in the return.php file to get the id value and check if the current visitor actually paid (i.e. using paypal Instant Payment Notification and storing the paid status in a database table) and can access the full size image (i.e. it should take more than just knowing the URL and trying various values - return.php?id=1, return.php?id=2, return.php?id=3, ... to access the full size image.) You could have return.php directly output the correct full size image (after making the necessary checks) or you can generate a unique URL for that visitor and that image and either perform a redirect to that URL or output a link to it on the return.php page.

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 all the errors that php detects will be reported and displayed. If you don't have access to the master php.ini, you can set the equivalent settings 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.) You should also be doing this on a local development system, as constantly uploaded code to a live server to check what a change does, wastes a lot of time.

Echo mysql_error(); on the next line after the mysql_query() statement to find out why the query is failing.

Yes, read the error message and set the timezone using one of the methods that it went to the trouble of telling you to use.

You need to try different methods to pin down what is happening. 1) Try a browser other than IE. 2) Temporarily comment out the msyql_query() statement to see if the problem is caused by the mysql portion of the code. 3) Putting a header() statement inside of an exit() is highly suspect. Exit() expects either a string or an integer value from the parameter. Header() returns void. Use a separate header() statement followed by an exit; statement (I do vaguely remember someone doing something similar and the resulting server response created a problem for IE.) Also, if that is all the code on the page, there is no need for the exit statement at all and/or why not just put the success logic on the same page where you process the form? 4) That cannot be all your code because there is nothing to make the connection to the database server. Something you might be doing in the code leading up to the code you did post could be causing the problem. When you are having a page-wide problem and you don't post all your actual code, it takes forever to solve problems.

Sounds to me like the From: address you are using is not hosted at the sending mail server so the mail server thinks you are trying to relay email through it and it is requiring that SMTP Authentication be used. Is the From: address hosted at the sending mail server? It should be, which will also likely eliminate the need to use SMTP Authentication.

READS is a reserved mysql keyword and produces an error when used as a column name. The back-ticks `` denotes special handling and allows a reserved keyword to be used as a column name.

That code is mixing a procedural mysqli_connect() function call with OOP mysqli methods. That does not work. However, the function _wakeup() is using the correct OOP method to create an instance of the mysqli class, but the code you have shown where the error is occurring at is back using procedural function calls (which again cannot be mixed with an OOP instance of the mysqli class.) Any chance the code has been modified from the original? In its' current state, it will never work. To fix the code, you will need to either pick procedural or OOP for msyqli and use that throughout all the code.

You do realize that the code that mrMarcus posted is extremely inefficient as it will call your function twice, thereby executing the query twice. Your web host will not be pleased with the unnecessary load that places on the mysql server.

User defined functions work exactly the same as php's built-in functions. The function call is essentially replaced by the returned value. For the same reason that you are assigning the value that mysql_num_fields() returns to your $fields_num variable, you must assign (or use directly in your code) the value that your sql_browse_and_select() function returns. $qResult = sql_browse_and_select($code); The $qResult variable that you define inside the function only exists inside of the function. Otherwise coding would be a nightmare because you would need to keep track of every variable inside every built-in and user defined function to avoid conflict.

And the header() redirect needs an exit; statement after it to prevent the remainder of the code on the page from executing while the browser performs the redirect. All a hacker needs to do is ignore the header redirect and he can access the 'protected' page the same as if the security check code was not even there.

Where in your main code are you calling sql_browse_and_select() and assigning the returned value to the $qResult variable that you are using in the two lines of code you did post?

Your upload() method does not check if the form was submitted and so executes all the upload processing code when the form is requested, thereby generating a number of errors. The upload() method also does not test for any of the possible upload errors before blindly attempting to access any of the $_FILES data.

If you browse to that page with a ?game_id=123 on the end of the URL so that the SELECT query retrieves the correct data and click the Yes radio button and submit that form, the expected UPDATE query is formed and executed - UPDATE MountainFCgamereports2010 SET approved='Yes' WHERE game_id=123

Actually, the <form... is part of a php print statement, so it would be necessary to concatenate the $game_id variable, instead of putting it in php tags with an echo of its' own. However, I just tried your full code posted in this thread and there is an $end error, so something is missing. Did you alter the code for the post? Edit: that error was due to the short open tag in your code.

The leading slash on a file system path refers to the root of the current hard disk. It does not refer to the document root folder. The information you have shown in the thread does not match the symptoms. Best guess at this point is that you have multiple copies of the file in different directory paths, some with and some without the function definition and/or you are using short open tags in the included file (i.e. the "file included" is showing up because it is in the source, not because php is outputting it.) What does a 'view source' of the page look like in your browser?

The form at the bottom of that code is not setting $_GET['game_id'] so there is no value in it when the form is submitted. Web servers are stateless. They don't know or care what happened on any request before the current one or what will happen on any future request. All resources used on any page request are destroyed when the code on that page ends. This includes any php variables. You would need to add ?game_id=<?php echo $game_id; ?> onto the end of the URL in the action="...." attribute in order to cause the $game_id value to be passed when the form is submitted. Also, there is no code setting $radioset from $_POST['radioset']. This implies that register_globals are on. To update your code so that it will work regardless of the register_globals setting (which was turned off by default 8 years ago and have been completely removed in php6), add the following to your code - $radioset = $_POST['radioset'];

You have an existing thread for this exact same issue. Why start another thread?

To get the quickest solution to what your code is doing, please just post your code. You likely have an if($game_id = '') (which sets the variable to an empty string) rather than an if($game_id == '') (which tests if the variable is an empty string.)

That's only the code that is checking the session variables. What about the code that is setting them or the code somewhere on your page that could be clearing them. Because you did not get errors about the whole $_SESSION not existing or an Undefined index error for $_SESSION['logged_in'], that implies that your code is setting 'logged_in' but is not setting 'accesslevel'. Best guess is that the part of your log in code that gets data from the database is not working and is not telling you what it is doing when it does not work. You could also have some code that either relies on register_globals to set same name session/cookie/program variables and your web host finally turned register_globals off (8 years too late) or you have some same name session/cookie/program variables and your web host managed to turn register_globals on and your variables are getting overwritten. Frankly, you are asking us what your code is doing without seeing your code. The quickest solutions come in help forums when you present all the relevant information and code so that someone can directly see the big picture and/or duplicate the problem.

For debugging, add the following immediately after the first opening <?php tag on the main pages involved in the problem (both where you log in and where you are being told access denied) - ini_set("display_startup_errors", "1"); ini_set("display_errors", "1"); error_reporting(E_ALL); And while your code might not have changed, seeing what method you are using in your code generally narrows down and suggests what could have been changed on the server that could cause the symptoms.

Your exp_date column can directly be used in the ORDER BY since it is a DATE data type. However, when you used exp_date as the alias name for the date_format() term, the date_format() result is what is used in the ORDER BY. By putting in an additional date_format() in the ORDER BY, you are just forcing your column value to be used instead of the alias of the first date_format(). This adds extra processing. The best solution would be to use a different alias name and then just use your column name in the ORDER BY.

Have you echoed $_FILES['afbeelding']['type'] to see what it contains so that you can find why it is not matching the "image/pjpeg" string?

Both of the examples you posted are correct, provided that the variables exist and contain a numeric value. What exactly is happening that leads you to believe that "nothing will work...."