PFMaBiSmAd

Since that code doesn't maintain WHO the win/loss values belong to and it is using SORT_ASC for the losses (the OP asked for DESC for both), Buzzzzzzzzz, non-working solution. Edit: in fact what gwolgamott has been posting is incomplete as well. The goal is to sort both wins and losses at the same time, so that within the same number of wins, the losses are sorted as well. If anyone reading this thread looks at the tested array_multisort() code that I posted above, it does sort by both wins DESC and losses DESC and it maintains who the win/loss values belong to.

The problem is because you are comparing $type with a numeric value using a loose comparison (==.) Php converts the value in $type to a number in this case, which results in a zero being used for the comparison. You actually only need to use if(!in_array($type,array('sounds','textures','ui')) because the zero value is not in that array as well.

To start with, the error is when rand.php is trying to include ../cms/global.inc.php The relative path of any relative include in rand.php is relative to main.php, not rand.php, so you would either need to use a relative path of ./cms/global.inc.php or you would need to form an absolute path using $_SERVER['DOCUMENT_ROOT'] . '/Charif/cms/global.inc.php'

The fact that the file did not upload means there is no file for all the GD functions to operate on, hence the GD errors. You would need to troubleshoot why the upload is failing. Is your upload code testing the ['error'] element of $_FILES['your_upload_name_here']['error'] so that you would know why the upload is failing?

When testing in FF, what URL are you entering in the browser's address bar?

The user doesn't download any php code. Php is a server side scripting language. Php would however read the whole include/require file on the server.

If you echo <pre></pre> tags around the print_r() it will be clearer what you actually have (you have an array of arrays) - echo "<pre>",print_r($clientinfo,true),"</pre>";

The following is the SELECT syntax definition - You must put the parts of it that you use in your query in the order that they are present in syntax definition. A WHERE clause must come before an ORDER BY clause.

If register_globals are on (what does a phpinfo() statement show for register_globals?), when you use extract on each row from your query, it is setting $user and that would be setting $_SESSION['user'] with the last value retrieved from the database. If you are going to use extract(), you should use it with a prefix (see the EXTR_PREFIX_ALL setting) so that there is no chance that it will overwrite any of your existing variables.

You need to investigate, if, where, and how $_SESSION['user'] is getting set to a different value.

http://www.google.com/#hl=en&q=php+mailer&aq=f&aqi=&aql=&oq=&gs_rfai=&fp=4b52c26b7e65a19f See the phpmailer or swiftmailer links returned by that search ^^^

You probably introduced a fatal parse error when you added the code incorrectly. Are you developing and debugging your 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 php detects will be reported and displayed? You will save a ton of time.

You would need to use SMTP Authentication, which the php mail() function does not support. You would need to use one of the 3rd party phpmailer scripts which do support SMTP Authentication.

Mchl, suggested in his post in this thread to use mysql_error() to find out why the query is failing. Did you do that?

Just putting two variable names in your php code does nothing - You need to assign values to variables - $_SESSION['username'] = $myusername; $_SESSION['pass'] = $mypassword; The exit; goes after the header() redirect, not after you close the if(){} statement - <?php session_start(); if(!isset($_SESSION['username'])){ header("location:login.php"); exit(); } ?>

Actually, because putting or anything() on the end of a statement doesn't address the execution path the remainder of your code takes when there is an error, it is only useful for troubleshooting problems and not ideal for application error handling. On an error, your code should - A) Output a user error message, something like "Due to a server error, this page cannot be accessed at this time." B) Log all the available information about the error - who (ip address, logged in visitor id) caused the error (in case a hacker managed to cause the error or a legitimate visitor happened to do something that your logic could not handle), what the actual data values or query was that caused the error and what error resulted, when the error occurred (so that you could both see if someone is triggering a series of errors to bring your database server down or to match outages with actual problems with your database server), where in your code (file and line number) the error occurred. C) Finish processing and output the remainder of your page that is not dependent on the error that did occur. You should also have display_errors set to OFF and log_errors set to ON for a live server (error_reporting should always be E_ALL or higher) so that all php detected errors are not displayed but they are logged.

So, did you even make an effort to find and change the size of your password field?

Actually, since Carlton adding a rouge single quote after the last value in the query, the corrected 'his way' code would still generate an error.

A) It would be if(!isset($_SESSION['username'])){ B) You need an exit; statement after your header() redirect to prevent the remainder of the 'protected' code on the page from being executed. Without the exit statement all a hacker needs to do is ignore the header() redirect that you are sending to the browser and he can access the remainder of the content on the page.

The php code you put into the eval() must be valid php code, your's is missing the ; on the end of the php statement. The fatal error you got should have alerted you to what was wrong -

Your INSERT query has a ( before the INSERT keyword and a matching ) at the end. Those two ( and ) don't belong there.

Have you checked yourself if the value in $_SESSION['logname'] actually matches an email address in your table?

The code you posted and the error message you posted don't match. You are using ./images/ in the posted code but the error indicates that the actual code that generated the error is using ./upload/

A) Is your password field in your table large enough to hold an md5() value (32 hex characters), and B) You are the only one here who can troubleshoot what your code is doing. How about checking if the value your query produces (form a SELECT query using the same logic you are putting into the WHERE clause) and what is actually stored in your database are the same.

http://dev.mysql.com/doc/refman/5.1/en/example-maximum-column-group-row.html