PFMaBiSmAd

Is the data you have been posting in your threads coming from a database query? If so, you can generally do all this ordering/combining/processing in the query statement and just display the result from the query.

You should not nest mysql_ function calls, since that prevents you from testing for errors or even if the query matched anything. The following logic is what you should use for a SELECT query, every time you perform a query - <?php $query = "SELECT Part_Name FROM `$list` WHERE PartID = $partid"; // use back-ticks `` only when need and string concatenation only when needed if(!$result = mysql_query($query)){ // query failed due to an error, handle that condition here... // do any user error reporting here - i.e. "Sorry, the requested operation could not be performed."; // do any application error reporting here... trigger_error("Query failed: $query<br />Error: " . mysql_error()); // assumes you have php's error_reporting/display_errors/log_errors set appropriately } else { // query run without any errors, check if the query matched any row(s) if(mysql_num_rows($result) < 1){ // no row matched, handle that condition here... echo "The requested partid does not exist."; } else { // the query matched one or more rows, use the data here list($itemname) = mysql_fetch_row($result); // mysql_result is the slowest way of accessing data, use a fetch_ statement echo "<p>This will delete the item: $itemname. Are you sure you want to do this?</p>"; } } The above code has error checking logic (test if something failed or not), error reporting/logging logic (output a user message and report/log application error information, and error recovery logic (take an expected execution path when something doesn't work to prevent follow-on errors and trying to use non-existent data values.) When you use code like this, it will tell you exactly what your code is doing and point to where problems are at in it.

Your form is using method='post'. The form data will be in the $_POST array - $_POST['delete'] Your code has some security problems that you should fix - 1) Your login check code needs an exit; statement after the header() redirect to prevent the remainder of the code on your protected page from running while the browser is requesting the target url in that redirect. The only thing your current logic is protecting or preventing is the echo "You aree logged in, please feel free to delete a message "; statement. 2) You need to make sure that any messages you are deleting actually belong to the currently logged in user. Your current logic would allow any logged in user to delete any or all the messages, belonging to anyone. You also need to consider that any one message appears in the outbox of the person who sent it and in the inbox of the recipient, and actually deleting it would remove it from both the sender and recipient boxes. Are you sure that is what you want? Shouldn't you have two flags, one for the sender and one for the receiver, that indicates when one of them has deleted the message and you should simply not display it in their corresponding box?

Each image you put onto a web page requires its own <img src='url_of_an_image' alt=''> HTML tag. The url_of_an_image for an image that is dynamically output by php must be to a .php script that outputs the correct content type header followed by the image data. Since you would want to use the same .php file for all your dynamically output images, you would want to put an GET parameter on the end of the url that indicates the id of the image. If you search the Internet/forum, you should be able to find example code showing how to do this.

phpmyadmin IS A PHP SCRIPT. If it displays the data correctly, that means that YOUR PHP CODE is where the problem lies. The quicker you post the code that reproduces the problem, the quicker someone can answer -

Two date strings with the same 'Y-m-d' date() format, can be compared by magnitude. If your's weren't working, then it's likely your data from the query isn't what you think it is.

You didn't state at what point you didn't get the expected output, but I'll assume you meant to tell us it's when you browsed to the login.php file. You are not getting the 'true' message because your conditional test is not true. Your user_exsists() function (in core/database/users.php) is returning the mysql_query() return value for a SELECT query. From the documentation for mysql_query() - There's two problems with your logic in login.php. A query result resource is equal (two == signs) to true, but it is not exactly (three === signs) a true value. Also, a select query that runs without returning a FALSE value, due to an error, doesn't mean that the query matched any row(s). It just means that the query didn't fail to run. After you test if the query executed without any errors, you must test if the query matched the row(s) you expected it to or returned the value you expected it to. The code you have in the user_exists() function (in core/functions/users.php), does test if the query counted one matching row and returns exactly a true or false value. Why didn't you use the logic in that function? Also, for the user_exists() function in core/functions/users.php. Why do you have two sets of logic in that function. When the first return statement is executed, that code returns to the calling code and nothing in that function after that point will run. Lastly, If that tutorial is showing you that you need to test if the boolean value returned by a function is a true or a false value, I would find a different tutorial. A function that's been defined to return a boolean value, is intended to be used directly in a conditional test. Doing things like empty($username) === true ... user_exists($username) === false is just wasting typing time and processing time. For those two examples, you directly just test if(empty($password)) ... if(!user_exists($username)).

We cannot possibly help you with your code, unless you post the code that reproduces the problem.

For your massive line after line of code, that only changes in what value/legend, I would make an array of arrays, with your categories as the index of the main array, and you have an index/value pair for each form field under that category. The sub-array index would be the form field name and the value would be the legend you want in the email message. Then you can loop over the array of arrays to build the email message. The main array index would given you the category heading for the message and then loop over each sub-array to output the legend from the array value and access the correct $_POST field using the array index.

Assuming the 500 http response isn't due to a php syntax/parse error in your main file (edit: or something in a .htaccess file), you can set php's error_reporting/display_errors in your script and get any php detected errors to be displayed. Add the following two lines of code, immediately after the first opening <?php tag on the main page being requested - ini_set("display_errors", "1"); error_reporting(-1);

Unless you NEED to use the features of PDO (and alter your code for the mysql features that PDO doesn't have any equivalent function for), you should switch from mysql to mysqli. Switching from mysql to mysqli can be accomplish by changing function names and swapping or adding function parameters (mysqli switched parameter usage and made them non-optional.)

You need an exit; statement after your header() redirect to prevent the remainder of the code on your page from running while the browser is requesting the target of the redirect. You likely have some code that is clearing the session variables. Another possibility is that the variation of your domain name (www. vs no www. on it) is changing from the starting page to the final page and the session id cookie is not set up to match all variations of your domain. For the devices where it does work, you are using all the same variation. For the ones where it does not work, you are likely starting out using one variation (without the www. on it), but the header() redirect takes you to the variation with the www. on it, then you stay on that variation and the session matches.

I tried that script to see what it would do. There are numerous php detected errors when it runs and it won't run at all, as is, under php5.4 (call-time pass by reference has been eliminated and results in a fatal error.) There's an error_reporting(0); statement in the lib/site.php file that is hiding all runtime errors you are likely getting on your server. You should comment out that line and see if you get any useful error information. Please don't post a bunch of error messages here and expect to get someone to tell you what to do to fix each one. If finding and fixing what is causing each error is beyond your php skills, hire someone or use a different script. However, based on what I saw in the code, you should not waste your time. The code is amateurish, has no validation, and would be a hackers dream come true if used on a live site.

Anything you have found concerning old mysql passwords has nothing todo with the application's login. If the sample data is being displayed, that means that your database connection is working.

Are you trying to login with a username of admin with a password of test?

The "die?" message looks like it is left over from some debugging. Sadly, the minimal sites like the one where you found that script at are solely for the purpose of earning money based on visitors. Knowing that the login form is redisplayed after you have entered your credentials, does at least point toward some likely causes. If I have time, I will look at the login form and the login processing code (in the pb_events.php file) to see what might prevent a successful login.

Note: a new thread has been started for this problem. Topic locked...

The issue isn't directly with the Trojan script itself, it's how the Trojan script was placed onto the server. Some php code was either uploaded, remotely included, or injected into eval'ed content and then executed on the server or an admin password for an application/control panel/ftp was guessed and directly allowed php code to be put onto the server. The original loader script then read and put the Trojan script onto the server. You would need to find the exact method that was used to get the original loader code onto the server and close the hole that allowed it. The web server access log file and any application/control panel/ftp/sql query log files would be the best places to start looking. Given the name of the Trojan, it's likely that the method of getting it onto the server involved a remotely included file in conjunction with php's register_globals being ON and an older php application that wasn't secure.

It would help if you posted the exact error/output you are getting along with what the URL in your browser's address bar is (if you don't way to post your actual domain name, xxxxxxx that part out, but don't change any of the other information in the URL.)

P5system, If you post replies on a php help forum with code that has an opening and closing php tag on every line, you are going to start receiving replies that point out every short-coming with that code, such as how bad code like that looks, and how hard it is to troubleshoot even basic syntax errors in code written like that.

If you echo mysqli_connect_error(), it will tell you why the connection failed.

Since your php code is apparently running, you can set the error_reporting/display_errors settings using statements in your code. The reason for asking/suggesting putting the settings into your master php.ini on your development systems is so that fatal parse errors in your main file will be reported and displayed and you don't need to remember to put the settings into your code for development and remove them on a live server (you don't want to display php errors on a live server.)

Because you are not getting the - "<p>Number of books found:" displayed on the page, your code is probably not executing to that point. Best guess is that the mysqli extension is not enabled. However, you are using the @ error suppressor on the line that would have produced an error message alerting you to that effect. You should never use the @ error suppressor in any code, ever. On a development system, you want to see all php detected errors. On a live server, you want to log all php detected errors. Remove the @ and I previously asked about your error_reporting/display_errors settings.

You need to troubleshoot why your php code is not outputting the expected results. For any one here to possibly help with the dozen different things our code could be doing, you would need to post the code that reproduces the problem (less any database connection information.)