DavidAM

Or you could read the values from your my.cnf file in the PHP script and pass them to PDO -- see parse_ini_file.

@c4n10 Read very carefully the responses Jessica provided. She was gently trying to tell you that you were calling the code something it is not. But you continually ignored her gentle prodding, so she became less and less subtle. At this point, it is clear that you don't know what you are talking about and (the bigger problem) you are not listening to people who are trying to help. And just in case you still don't get it: THERE IS A MAJOR DIFFERENCE BETWEEN JAVA AND Javascript. THE CODE YOU SHOWED IS Javascript, NOT JAVA I think her final assessment is on the money: I don't know enough JS to provide any insight. Although all of your onclick calls are passing two parameters to functions that only accept one parameter -- maybe that's some special JS thing, I don't know. The issue may also be with the CSS changes being made by some of those functions. Hopefully, someone with more JS knowledge than me might come along and help. But if you don't start listening to people who are trying to help, I doubt anyone will spend any significant time on it.

Actually, php has two operators for a logical "and". They are && and AND (not case sensitive). They do have different precedences, though. I always use "AND" because I like the way it looks. (I never did like the "&&" look in C and other languages). Since they have different precedences, and since I'm too lazy to remember the precedences, I always use parenthesis to group the exp<b></b>ressions: if ( (isset($_GET['id'])) AND ($_GET['id'] > 0) ) Parenthesis are pretty cheap (I get them in bulk) so I don't worry about using too many. I think the problem is that you are not passing the ID value from the edit form. You can either include it in the FORM ACTION <form action='file134.php?id={$_GET[id]}' method='post'> or add a hidden field to the form: <input type=hidden value={$_GET[id]}> (which will put it in $_POST instead of $_GET) or (best practice) store it in a SESSION.

Jessica! How can you say Psycho made a mistake?! Obviously, the bugs in the post editor are getting worse, now they are changing variable names in the posted code.

"=" is the assignment operator. To compare use "==" (two equal-signs). As it is, you are assigning: 'gbook' && file_exists() to $page, so you changed $page to "true" which evaluates to "1" when you print it.

Javascript validation is not reliable. The user may choose to turn off Javascript. The best approach (IMO) is to post to the same page and process the data. If an error occurs, you can show the form, with the user's supplied data so they don't have to re-type everything, just the invalid stuff. If there are no errors you can use PHP to redirect to the final page: header('Location: http://www.mydomain.com/thankyou.php'); exit();

I don't see the COUNT in your query; but you are correct, it will not work that way. COUNT is an aggregate function -- it operates over a GROUP of rows NOT on individual rows. If you want the total row count in the table, there are two things you can do. 1) Run another query: SELECT COUNT(*) FROM users or 2) add SQL_CALC_FOUND_ROWS to your existing query, then run another query SELECT FOUND_ROWS() to get the answer. SQL_CALC_FOUND_ROWS will calculate how many rows would have been returned without the LIMIT on the query; and FOUND_ROWS() will return that value. (mysqli_num_rows()) is only going to tell you how many rows were returned by the query). # NOTE there is no comma after SQL_CALC_FOUND_ROWS $sql = 'SELECT SQL_CALC_FOUND ROWS username, DATE_FORMAT(join_date, "%d/%m/%y") AS join_date_str FROM users ORDER BY join_date DESC LIMIT 5'; $qry = mysqli_query($con, $sql); while ($row = mysqli_fetch_row($qry)) { $member[] = $row; } mysqli_free_result($qry); $qry = mysqli_query($con, 'SELECT FOUND_ROWS()'); $row = mysqli_fetch_row($qry); $totalUsers = $row[0]; mysqli_free_result($qry); One thing I didn't mention, you should get in the habit of releasing the resultset once you are finished with it. I added calls to mysli_free_result in the example above. I don't see anything here that should cause significant performance problems. If you have a configuration issue, you may want to get that resolved. My development machine is a very low-end computer (one I literally got off the trash pile). I don't worry too much about performance on this machine. Or, I should say, I realize that performance on this machine will be slower than a production server. I just try to keep everything as efficient as possible. When you look at the performance of a "page" you have to consider a lot of things: network time (between the click on a link and the time it gets to the web server); web-server time (web-server gets the request and decides to process it and sends it off to PHP); PHP time (that's your script, plus any PHP loading overhead); more web-server time (web-server gets the results from PHP and sends it to the browser); more network time; browser time (formatting the page). If you are really concerned about your script's performance have it tell you how long it took. At (near) the very beginning of the script add this line of code: $startTime = microtime(true); Then at the end, add this: $duration = microtime(true) - $startTime; $dynamic_home .= sprintf('<P>Script Duration: %.2f secs</P>', $duration);

In this case, you are trying to retrieve two different sets of data; 1) a list of users and 2) a list of uploads. Each set requires a separate query. Don't try to artificially limit the number of queries on a page. Just get all of the data for a given dataset (users) in a single query. --- Have a look at the bottom of this page. Right now, it says "Queries: 15 queries". On a dynamic site, most pages will take more than one. No, there was nothing wrong with your query, if you wanted a list of "demos" and the users that own them. That's called "joining" the tables and will be needed in pretty much every query that has multiple tables. Most people today use the JOIN syntax instead of putting it in the WHERE clause, but it works either way. And Yes. Because of the JOIN any user with multiple demos was listed multiple times (once for each demo). Since your PHP was pulling only part of the data and treating it as a data set, you were getting duplicate users. If you really want a single query, you can do that, and then somehow filter the duplicates out. But it means more work for the script and a PITA if you ever need to make changes to that part of the code later. This is called a Cartesian Product. Without a JOIN in the query, every row from every table will match every row in every table in the query (well, at least those that satisfy any other WHERE conditions). You get huge result-sets with these when it happens --- a table with 1,000 rows and a table with 500 rows will return 500,000 rows if there is no JOIN. I look forward to hearing of your success. (or any further questions).

Look a little closer. You are writing the line (the one that contains the key) before you check to see if the line is the key. The IF test, and writing the new line should occur before you write the current line (the one with the key).

Since you are joining the two tables, if any user has more than one demo, that user will appear in your list twice. You would have to account for this possibility in your PHP code to prevent displaying duplicate user data. When you put a LIMIT on that query, if a user has more than one demo, that user will be in there twice, so you will not have 5 unique users. When you put the ORDER BY on that query. You will only get demos for the 5 most recent users that actually have an upload. And a user who registered long ago, but uploaded a new file just now, will NOT be in the list. I really think you have to do two separate queries in order to get the unique and accurate data you are looking for. SELECT users.id, users.username, users.join_date FROM users ORDER BY join_date DESC LIMIT 5 SELECT demos.gid,demos.game_id,demos.file_name, demos.demo_name,demos.demo_desc, demos.uploaded_by,demos.upload_date FROM demos ORDER BY upload_date DESC LIMIT 5 You could add a join in the second query to get the username to display with the demo if you want. You could add an (outer) join in the first query (and a group by) to get the last upload date or count of uploads if you want. You are right in thinking it is over-complicated. Using two queries (and doing the date formatting in the query), you can eliminate the nested loops, so something like: $sql = 'SELECT id, username, DATE_FORMAT(join_date, "%d/%m/%Y") AS join_date_str FROM users ORDER BY join_date DESC LIMIT 5'; $qry = mysqli_query($con,$sql); $member = array(); while ($row = mysqli_fetch_row($qry)) { $member[] = $row; } $sql = 'SELECT gid, game_id, file_name, demo_name, demo_desc, uploaded_by, DATE_FORMAT(upload_date, "%d/%m/%Y") AS upload_date_str FROM demos ORDER BY upload_date DESC LIMIT 5' $qry = mysqli_query($con,$sql); $demo = array(); while ($row = mysqli_fetch_row($qry)) { $demo[] = $row; }

Is this exactly the same thing you do to the password provided by the user on the login page? I mean exactly. You should create a common function named something like hashPassword() and use that function in your registration page, login page, and reset page; so you know you are doing the same in all three places. Then if you ever decide to use a different algorithm, you only have to change it in one place --- by the way, using MD5 with no salt is NOT a good idea, MD5 (alone) is too easy to hack (google "rainbow tables"). This is not the way to retrieve user input from POST fields. Each of those functions, addslashes and htmlentities have specific purposes not related to retrieving user data. The only thing you should do to POST (or GET) fields is stripslashes and that only if magic_quotes is on (which it should not be). By the way, could be done without the foreach. $rand_key = array_rand($alpha, 6); $password = implode('', $rand_key); echo $password; (That's an empty string in the implode call.)

Is the PHP you showed above the file named in that error message? I did not get a Parse error when I tried that code. Note: The in_array code will NOT produce the same results as the strpos code. The original code is searching the entire UA for the existence of any of the bot strings anywhere in the UA. The in_array() code is only checking to see if the UA is exactly equal to one of the bot strings. It's a mute point, because 1) that function is not called in the code provided; and 2) that function will always execute the exit("Bots not allowed.</p>"); line whether it finds a bot string or not! Show us the form.php file, or check line 22 of that file yourself. That is where the problem lies. Oh, and use tags, it makes the code easier to read.

PHP automatically decodes the values in the $_GET (and $_POST) array. Unless you are encoding (via Javascript or something) in addition to what the browser does, there is no need to urldecode() the $_GET (or $_POST) array. @eldan88 What says that? The code you provided could not possibly be saying anything like that. It is more helpful to copy & paste your actual code, than it is to provide a typed-out example that is something-like your code. Show us the real code; Use mysql_error to see the error message (copy and paste the entire message here); echo the actual query and show us what it looks like; Maybe we can help.

The code from exeTrix is using jQuery, so you will have to load the jQuery library -- see their website at jQuery API Documentation. You will have to change the url parameter in that code to the url of your widgetextract.php (or whatever script you write to handle the AJAX call) in order for it to post to your PHP. PHP is run on the server, so it is done and gone before the page displays. So there is no way to "set a php variable with ajax". You can, however, pass data to (a new instance of) your PHP script and have it pass data (as output) back to AJAX.

@jacko_162 The INSERT statement will not touch any columns that are not specified in the statement. The columns should receive the value assigned as the DEFAULT when the table was created. The UPDATE (triggered by the duplicate key) will only update the columns that you specify in that phrase of the query. Since you dropped and re-created the table, and these columns are not supplied by this code, could it be the form you are using for these fields that is causing the "lost data"? Do you have a trigger on the table that could be manipulating this data? @exeTrix I never said mySQL would arbitrarily define unique indexes. I simply said that the ON DUPLICATE KEY UPDATE phrase will be triggered by ANY UNIQUE INDEX on the table, NOT JUST the PRIMARY KEY. If you define a unique index on farkle_counts, it WILL trigger the ON DUPLICATE KEY phrase. There is NOTHING inherently "more secure" about PDO. It is simply "a lightweight, consistent interface for accessing databases" (PDO). It is the Prepared Statement that "eliminates" the need for escaping strings. And only because it is doing it itself, inside the "black box". If you use PDO.query or PDO.execute then "Data inside the query should be properly escaped.".

ON DUPLICATE KEY ... will trigger if ANY UNIQUE INDEX value already exists. If you have a UNIQUE INDEX on StartDateTime, then it will trigger the UPDATE. Check your indexes. PRIMARY KEYs are always UNIQUE, however the other indexes should not be UNIQUE (unless they are, uh ... unique).

You need to group the two conditions of the OR clause using parenthesis. Your problem is that the query above will return all events where the date matches AND the client matches; OR all events with adminpost = 'All'. Try this SELECT event_title FROM calendar_events WHERE month(event_start) = '".$month."' AND dayofmonth(event_start) = '".$dayArray["mday"]."' AND year(event_start) = '".$year."' AND ( client='$loggedin' or adminpost='All' ) ORDER BY event_start"; Note: If event_start is a DATE (or DATETIME) column (and it SHOULD be), and you have an index on it (and you SHOULD), that query will never use the index. You would be better served to use: event_start = '" . $year . '-' . $month . '-' . $dayArray["mday"] . "'" if it is a DATE column. If it is DATETIME, you need to use a little different condition. Note (2): You should avoid running queries in a loop. If you are doing a full month (or even week) calendar, then select all of the data for the time period, load it in an array and THEN build the output. Running queries in a loop uses a lot of unnecessary resources communicating with the database and will take longer than it should.

This tells you exactly where you started sending output -- The :3 here means LINE 3 of that file. If this is your actual code, then this is your problem Everything outside of PHP tags -- including those two blank lines -- is sent to the browser as content. There is no reason to break out of and back into PHP here. If should NOT make any difference to that particular error. And FYI, the specs say that the URL in the Location header must be absolute (so you had it right the first time).

AND you need to break up the WHERE clause into separate conditions should be WHERE qa.tags LIKE '%$trimmed%'" AND mlb.tags2 LIKE '%$trimmed%'"; (or maybe OR instead of AND, depending on what you want)

Actually, you are never retrieving the data from the posted form ($_POST), you are only retrieving it from the database. This is one of the good reasons that you should separate process from presentation. At the beginning of the script, process the data if there is a POST. Then retrieve the data from the database, then present the data (build the HTML). So it looks something like this: # Process the form if POSTed if (isset $_POST['submit']) { $name = $_POST['name'] ... UPDATE table SET ... } # Load the data to be shown SELECT ... $name = $row['name'] ... # build the form <HTML> ... <?php echo $name; >? ... Also: 1) Forget about the error suppression operator "@". Take it out of your code EVERYWHERE! When errors (or warnings or notices) are displayed, there is a reason. FIX THESE ISSUES, don't hide them. 2) You don't really need a while loop if you are only getting one row from the database. 3) Make sure you sanitize any data you send to the Database. Use mysql_real_escape_string for strings sent to mySql. Use intval for integers. etc. 4) Avoid PHP_SELF as the action of a form. Use an empty string: action="" or hardcode the page name. PHP_SELF is based on data from the client, and could contain hacks to infiltrate your system

The -f specifies who the mail is from not who it is to. It should be an email address that has authority to send from the mail server (i.e. one provided by your host). As to why it might work on some: Using an email address as the FROM address that does not "belong to" the sending server, is considered forgery by some receiving servers. They may therefore put the email in a junk folder, refuse delivery (and bounce it), or just discard it. Different (receiving) servers may behave differently.

Since M? W?????? is the only operating system that uses the backslash, I guess that says it all!

See mysqli_fetch_array in the manual The default is to return both. You can pass a parameter to specify one or the other. Or you can use mysqli_fetch_assoc or mysqli_fetch_row

Anytime you get that message, it means the query failed. You have to echo mysql_error() just after the mysql_query() call to see what the SQL error is. Also, you are not assigning the result of the second query (the SELECT) to a variable, so your call to fetch_array is going to fail as well. You need to use $rs = mysql_query($mysqlQuery2); up there when you execute that SELECT.

Again, you are not executing the query (the SELECT query this time). You need a mysql_query($mysqlQuery) in there. And by the way, you are not executing the DELETE query either.