benanamen

Try setting max_allowed_packet to 1048576. This is a known problem in that version of Cent OS. If you can, upgrade to CentOS version 7. Did you do a manual Mysql install or from package? If you did manual, you are probably going to have additional problems after the max packet fix but lets see where you are at after the packet increase.

You are using obsolete code that has been completely removed from PHP. Hiding errors with @ is a bad idea. You want to fix errors, not hide them, and why in the world are you echoing html? On top of that, page formatting goes in an external CSS file. This code looks like it was written in the 90's. All this x1, x2 x3 is ridiculous. You need to use PDO with prepared statements. https://phpdelusions.net/pdo

Why did you stop binding the parameters when you got to $getid?

For starters try running your code in IE8 and submit using the enter button. It will completely fail. Another example, If I was to submit your form using cURL, I have no idea that it depends on me also sending a button name to work so it will fail. The field names would be obvious.

As Jaques1 has said, depending on the name of a button to be submitted is a bad idea. It wont always be and it will completely fail under certain circumstances. Always use if ($_SERVER['REQUEST_METHOD'] == 'POST') along with the hidden input if needed.

YOU ARE VULNERABLE TO AN SQL INJECTION ATTACK! You NEVER EVER send user supplied data directly to the database. You are using obsolete Mysql code that has been completely removed from PHP. You need to use PDO. https://phpdelusions.net/pdo Page formatting needs to go in an external CSS file. The whole thing needs to be re-written and you need to update all your software versions. You are just begging to be hacked.

The correction you need is to stop using obsolete code that has been completely removed from the current php version. Use PDO. Your current code is also ripe for an SQL Injection attack. You never ever send user supplied data directly to the database. https://phpdelusions.net/pdo

You are using obsolete mysql code that has been completely removed from php. You need to use PDO with prepared statements. Here is a tutorial. https://phpdelusions.net/pdo

No, this is not the best solution since it will completely fail under certain conditions. You are hoping the name of a button is going to be submitted and it wont always be. The correct method is if ($_SERVER['REQUEST_METHOD'] == 'POST')

echo $foo = '"bar"';

<?php foreach ($result as $row) { echo htmlentities($row['message']) .'<br>'; } ?>

Give this a shot. Without a datadump I couldnt test it. SELECT u.username, u.email, u.`password`, m.message, g.group_id FROM users AS u INNER JOIN messages AS m ON m.username = u.username INNER JOIN message_group AS g ON g.username = m.username GROUP BY g.group_id ORDER BY m.`timestamp` ASC

Your missing url

You bound ID but then didn't use it.

Funny you should say that. I have been learning Python the last couple weeks and there is only one way to do it which I am really liking. I have always thought that there were too many ways to do the same thing in PHP and it should just be one way. On several forums I started a post to see how many ways you could output the standard "Hello World!". There are over a hundred different ways. So it really depends on how you look at it as to whether it is great or not. As far as retaining the correct form values when there is an error, you still can without creating the extra variables like so. value="<?= !empty($_POST['field']) ? htmlspecialchars($_POST['field']) : '' ?>" When I said halt the script, I meant the same thing as you.

You shouldn't have have a second query or third query. You need to do a single query with a join as I previously posted and you should be asking for specific columns, not using *.

Aaarg! Forget everything I said about the index errors. I shouldn't have even been seeing it. That whole part of the thread is mute and explains why I was thinking we were not quite on the same page. We were kinda having two different conversations. I was mistakenly doing if field empty set var=. Should have been if field !empty set var=. Doing it !empty as it should have been in this case has the same effect as the parameter not existing at all, coded error gets set either way and script halts. My normal code pattern is if field false, set error, stop script after all checks run. Quickoldcar was doing if field true set var to post param. I never set vars to a straight POST params unless it has changed for some reason. That's what threw me off. IMO that formula is no good. For one, you are setting pointless variables to POST parameters that haven't changed, and second, if there is just one parameter error, a whole bunch of already useless variables have been set for no reason. I believe the proper flow would be: Trim the POST array in one step Check for empty required fields (has the exact effect if field doesn't exist at all) if error add to error array, halt with user friendly errors from array, else continue

Rather basic. Add ORDER BY column ASC or DESC. You have too many queries. Just use a join. You are also opening and closing php unnecessarily. More importantly, you hang pictures on a wall. Next time post your code.

Ok, I did some testing on 300,000 employee records. Based on my test results, the fastest option is set an index and no limit 1 No Index Average .97 .0554 1.142 1.155 1.094 .700 1.153 1.143 No Index Limit 1 Average.38 .423 .354 .388 .348 .412 .405 .333 Indexed Average.026 .046 .026 .022 .020 .019 Indexed Limit 1 . Average 031 .020 .029 .042 .038 .042 .021 .029

So Jaques1, are you saying that by indexing username there is no reason to use the Limit 1? I suppose its time I whip out some code and see what actually happens.

15 minutes is plenty. My time is either not 15 or I get into an accelerated time warp where 15 minutes seems like 5.

I used quickoldcar's code example instead of what I actually proposed in #9. Nevertheless, the resulting error is exactly the same. If you look at my code in #9 it does use empty as you say. What I proposed in #9: // Check for empty instead if (empty($_POST['field'])) { echo 'Field Empty'; } Using the isset makes it impossible to spot the issue that the expected field is not even in the form at all since it silently hides it. The only way you would ever know is by reading the code and seeing the form field doesn't exist. There will be no error in the logs, no error on the screen with error reporting on. No nothing except all the missing data you thought you were getting. I would call anything that generates a system error a bug even if it is just a notice. It means something is wrong and needs to be fixed. I would say the following is pretty meaningful as to what and where the problem is: Notice: Undefined index: lname in E:\xampp\htdocs\help.php on line 32. Whether you see it in the logs or on the screen it is quite clear. You are also not going to want to abort the script on an undefined index. The worst that is happening using your example of removing the field is your not getting that piece of data. Using isset, you will never know until you look for the data and it is not there. With what I proposed, you are at the least getting the error logged which should be being checked regularly anyways. As you said, there is going to be bugs that will make it to production. Usually found because users do crazy stuff you would never think they would do. I am pretty sure that is not what I am saying. My comments are specifically relating to whether a site supplied form field will always be isset when POST is submitted or not and if not, under what code provable conditions will it not be. I also tested in Curl and it makes no difference. Besides a form or curl, what other way is someone going to POST your expected form data? I am not saying there is not a case where what I proposed will be a problem, but I am saying I dont know of it and would like to know what it is. Same type of thing when we had our conversation about if ($_SERVER['REQUEST_METHOD'] == 'POST') VS if ($_POST). You were able to show me specific cases to support $_SERVER['REQUEST_METHOD'] == 'POST being the correct way and how it could fail otherwise. I want to know what I know, not just because someone says it and if I repeat it to someone else, to be able to back it up in code. Using your example of removing the form field and, as actual code testing shows, how are you going to know that the error check for missing lname is looking for a form field that doesn't even exist if the problem is completely hidden with the isset?

Curl test case same EXACT result. (Of course need to change the if submit line to if ($_SERVER['REQUEST_METHOD'] == 'POST')) <?php $curl = curl_init(); curl_setopt_array($curl, array( CURLOPT_RETURNTRANSFER => 1, CURLOPT_URL => 'http://localhost/help.php', CURLOPT_USERAGENT => 'cURL Request', CURLOPT_POST => 1, CURLOPT_POSTFIELDS => array( 'fname' => 'Joe', 'email' => 'user@example.com' ) )); echo $resp = curl_exec($curl); curl_close($curl); ?>

In this particular case, I deleted the lname field and changed the error check to if ($_POST['lname'] != '') { $lastname = $_POST['lname']; } else { $errors[] = "<p>Sorry, you must give your Last Name!</p>"; } What I get (with error checking on) is undefined index (ONLY) which is exactly to be expected. Firebug not even needed although I did look there. While in development mode the problem isn't going to get past you without you knowing it. In this case, if you leave the isset, you are never going to know that you are either missing the field you expect, or you are doing an error check you dont want. It will just silently be ignored. So in this instance I see it as bad to have the isset. In development, you are going to know about this and be able to fix it before going to production. If your dev environment matches the production environment, which ultimately, it should, its not going to unknowingly make it to production. I suppose in a group development with different people doing things it would serve as a safety net. It definitely isn't going to hurt anything to do it that way. Everything I have ever done I was the only programmer so I have never experienced problems from multiple coders. Only once I was coder and another guy did the design .

My bad, I meant WHERE username and the use case being a login and only one possible username match. user_id would have been the indexed auto increment which is not the column the WHERE would be checking.