Leaderboard

@2020, Error: process stops, and tells you what you did wrong. Warning: process continues, and tells you what's wrong Exception: if error occurs, the code executes what you have in place (called an "exception handler") should such an exception occur. In development (as opposed to "live for public viewing), I have: 1.) On top of all my PHP pages: error_reporting(E_ALL); ini_set('display_errors', 1); 2.) In the non-public file above the public_html directory mysqli_report(MYSQLI_REPORT_ALL|MYSQLI_REPORT_STRICT); $db = mysqli_connect("localhost" , "username" , "pass" , "database"); (Never ever ever have your mysql credentials in your public www directory.... the day will come when PHP for whatever reason decides to stop working and everybody will get to see your credentials) I didn't even notice mac_gyver did not capitalize his sentences, I'm here for info, not to be grammar police 😀 But from what I understand mac_gyver is saying (I'm the worst PHP person on this entire forum) is: 1.) turn all the errors on during testing, but MAKE SURE all error reporting is turned off when your site is live for the public. 2.) You can create exception handlers in your php/mysql code so you can debug specific parts of your code, if you want. Otherwise, Barand's #4 suggestion, combined with PHP error reporting on top of all your PHP pages should be sufficient (in most cases) to display most if not all the errors in your code.

It's neither a PHP thing nor a HTML5 thing - it's a plain, old HTML <select> thing. By default, if none of the options have their selected attribute set, the first option is shown as selected.

Either of the last two codes are OK, but I would use the first one and set the value of the first option to nil: <option value="">Select here</option> and not a space. Question: If this is a yes/no thing why not use simple Radio buttons

code that unconditionally (always) outputs the raw database statement errors for the connection, query, prepare, and execute statements, only helps hackers when they intentionally trigger errors, since these errors contain things like the database hostname/ip address, database username, if a password is being used or not, part of the sql syntax, and web server path information. the only time you should output the raw database statement errors is when learning, developing, or debugging code/query(ies) and you are viewing the site as the developer/programmer. at all other times, you should log these errors. the simple way of doing this is to use exceptions for errors and in most cases let php catch and handle the exception, where php will use its error related settings to control what happens with the actual error information (database statement errors will 'automatically' get displayed/logged the same as php errors.) you would then remove any discrete error handling logic, since it doesn't add any value for a legitimate visitor to your site, and it will no longer get executed when there is an error (execution transfers to the nearest exception handler for the type of exception or to php if there is none.) the line that Barand posted enables exceptions for errors for the mysqli extension.