Jacques1

You do have to HTML-escape outgoing data, but this happens in the rendering part and has nothing to do with SQL queries. When you perform database operations, you need the original, unaltered data.

You can't have an "elseif" after an "else". The "else" marks the end of the statement (as in: If none of the above is true, execute the following code). It's if (...) { ... } elseif (...) { ... } elseif (...) { ... } ... else { ... } If your code "just gets stuck", that means you need to fix your error reporting as well. PHP always tells you exactly what's wrong.

The code has multiple problems. First off, you must not use SQL-escaping together with prepared statements. The whole point of a statement is that its input gets treated as raw data and not as SQL, so any backslashes you've added through your escape functions will end up as literal characters (e. g. “O\'Reilly”). You're also searching your database for the plaintext password, but of course that will never be found when you've stored hashes (which you should). You need to search for the username only, retrieve the hash and then verify the password against the hash using password_verify().

This is clearly a different format, namely the correct one. If you're still having trouble, tell us exactly what that is. Note that you cannot use implicit indices with checkboxes (which is why I recommended explicit indices). Since unchecked boxes aren't sent at all, you have no chance of figuring out which box belongs to which adjustment. You're sending a POST request, but all data is attached to the URL, and the request body is completely empty. That doesn't make a lot of sense. Put the parameters into the request body (with the already mentioned "data" property).

The JavaScript code also looks fishy. Why are you sending an empty POST request with all parameters attached to the URL? Use the data attribute to include the parameters in the request body. And why do you prepend “fd=” to your URL-encoded parameters? This is likely to break parameter parsing altogether.

URL parameters are stored in $_GET, not in $_POST. You also haven't understood the reply. In PHP, you can't have duplicate parameter names. You do have duplicate names, because defid is appearing twice in the URL. To fix this, you need to change your form and append “[]” to the parameter: <input type="text" name="defid[]"> <input type="text" name="defid[]"> ... Better yet use explicit indexes: <input type="text" name="defid[0]"> <input type="text" name="defid[1]"> ...

PHP runs on the server, and this is hardly a server-side issue. Moving to Miscellaneous.

Maintaing a perfect sequence of integers will be painful, both for you and the admin. Why don't you decouple the technical implementation from the user interface? The admin could, for example, arrange the products with simple drag-and-drop and doesn't have to care at all about how exactly the ranks are stored. Then you're free to choose any implementation which is technically suitable without having to worry about nice-looking numbers. To avoid re-arranging products all the time, you could use large gaps or even foating numbers instead of integers.

This is about the HTTP stream wrapper which automatically emits warnings when there's an HTTP-related problem. It's not possible to catch those errors (except for hacks like a temporary error handler).

There's the error suppression operator. Whether that's a good idea is debatable, though, because it will suppress all errors, including serious ones. Consider using a more professional HTTP client like cURL.

Now that you guys have completed your copy-and-paste transaction, I hope we can have a more serious discussion. C'mon, requinix. What do you think happens with a file with PHP tags and PHP code in it? So what you're actually saying is: You hope the file will never contain any other code. I hope so too, but hope isn't quite enough. So your scripts are all 777, or what? I like your optimism, man. Sounds a bit like the Wordpress mantra: “What could possibly go wrong?” What are you talking about? Under what redefinition of atomicity is this statement true? Yes, let's just assume that all people coming to this forum are seasoned experts who write sophisticated applications and know exactly what they're doing. Because PHP programmers don't just blindly copy-and-paste half-working code from forums.

First off: Dynamically generating PHP code and loading that into your application is the absolute last thing you want. If anybody manages to manipulate that file (which is fairly likely), you end up executing random code on your server. Or if there's just a tiny syntax error in the file, your entire application is dead. Do not generate PHP code. The best place for configuration values is the database. Using flat files is generally not a good idea, because this quickly results in data corruption: File operations like file_put_contents() can actually fail. If you write directly to your configuration, you'll end up with garbage and kill your application. There can be multiple file operations at the same time. Without concurrency control (e. g. locking), this may also put your configuration into an inconsistent state or make you lose changes. Long story short: Use the database.

The bigger picture is that you need to stop writing spaghetti code. Right now, you have JavaScript code within 90s HTML markup within PHP code, next to CSS within HTML within PHP. No wonder you spend most of your time struggling with syntax errors! You've reached the point where you no longer understand your own code. JavaScript code and CSS declarations belong into external files. This will massively reduce the complexity and size of your PHP scripts, making syntax errors much less likely. The PHPHTML pasta can be untangled with a template engine like Twig, which will also fix dozens of cross-site scripting vulnerabilities in your current code (it seems you haven't even thought about security before). While it's theoretically possible to generate dynamic web pages with pure PHP, this requires a lot of discipline and security awareness. I don't recommend it. Last but not least, you should replace your current code editor with a proper IDE (integrated development environment) like Netbeans or Eclipse. This will warn you immediately when you fudge up the syntax, giving you a chance to fix the error yourself.

You need to fix the problem, not hide the error message. Appearently you're still inserting $_GET parameters straight into your query strings. Do what Psycho said: Slow down, take a deep breath, and then carefully analyze your code.

What exactly is the current problem? Are you getting an error? What does it say?

Since you also seem to be new to the Internet: The blue underlined text is a link. You click on it with your left mouse button. >> Click me <<

$stm isn't the same as $stmt. You might want to start using more descriptive names instead of cryptic, generic abbreviations.

Getting rid of the old MySQL extension is the whole point of this thread. The OP knows that it's outdated.

You shouldn't try to translate your old code word-for-word, especially when you've adopted all kinds of bad techniques (which you have). The purpose of MySQLi is not to add a fancy new “i” to all functions. It has actually introduced new features to make you write better code: Manual escaping (which nobody seems to get right) has been replaced with prepared statements. Manual error handling (which nobody seems to get right) has been replaced with exceptions. Use those features! In the 21st century, websites really should stop printing MySQL errors on the screen or telling me that no database could be selected. What the hell am I supposed to do with this information? I'm a random visitor, not your PHP developer or database administrator. You should also consider using PDO instead of MySQLi, because it's a lot more flexible and comfortable. MySQLi may sound familar and easy to transition to, but it's very cumbersome and limits you to the MySQL database system once and forever.

This is a help forum, not a we'll-guess-what-your-problem-is-and-then-fix-the-code-for-you-forum. If you have a problem, you need to actually tell us what that is. You're also expected to actively work on the issue and not just hand over the code. What have you tried? What exactly do you not understand? What I can tell you is that you need to start thinking about security. You can't just take user input from random people and insert it straight into the e-mail headers and the message, because this effectively turns your server into an open mail relay where anybody can send e-mails to arbitrary addresses. Use a proper mailer library like PHPMailer instead of the terrible mail() function.

Note that the empty() function also suppresses index warnings, so if you do want warnings, you'll have to go back to $_POST['param'] != ''. To be honest, I don't care too much about the exact check as long as there is a check. What I object to is the statement that you could just rely on all parameters being present. Like I said, I understand why you would want to log missing fields, but I think relying on “Undefined index” notices is a very poor approach to that. By itself, a missing parameter is a client-side problem. People and bots send all kinds of data in all kinds of ways, and sometimes they simply don't provide all required parameters. Of course a client-side error can be rooted in a server-side bug, but if you want to log that systematically, you'll need a lot more than a few index checks: What if you get a value from a select field which doesn't match any of the options? What if you get a text input which exceeds the field limit? What if you get data which should have been caught by the HTML5 or JavaScript validation? Ignoring those potential rendering issues only because PHP doesn't automatically emit a warning seems arbitrary. Notices also do get overlooked. If your own code never produces any unnecessary error messages, and if your error reporting is always set to -1, that's great. But not everybody is in that position. For example, I had to deal with bigger applications which would literally flood the error log with notices just by running normally. Nobody is going to wade through the entire log to find the one notice which indicates a template. However, people do react to meaningful warnings and fatal errors: Warning: No POST parameter "lname" provided (missing form field?) in ... Long story short: If you think input problems should be investigated to detect possible bugs, do it for all input problems, and use proper error messages instead of cryptic PHP notices.

This: https://developer.mozilla.org/en-US/docs/Web/API/Node/innerText I don't think anybody can answer that question based on a single line of code. Show the complete code and the console.log() results.

You've now switched to a different approach. When you check for $_POST['foo'] != '', you effectively are doing an isset() check, except that it's poorly implemented, floods your error log with useless warnings and makes it harder to spot actual defects. Initially, you said that we could just assume that all parameters are present, which is clearly wrong and can lead to severe problems. There's no guarantee that all parts of the code (including libraries) are ready to handle the garbage input you've let through. In fact: According to your own logic, every functionality should just assume that the input is correct and go on, doing who-knows-what until the program finally blows up. Bug-free software is also something that just doesn't exist in reality. No matter how much you test your code, there will be bugs, and your application must be able to deal with that. The only argument which is somewhat valid is that you consider missing fields to be bugs. But even then it makes no sense to rely on the built-in index warning. You'll want a meaningful message in your log, and you'll probably want to abort the script altogether. So no matter how you look at it, leaving out the isset() checks or replacing them with a bad alternative is just wrong. You might use empty(), though, because that is actually an extended isset() check.

That's why I also mentioned textContent as a fallback.

And now let's hope nobody will hold you accountable for the gigantic security holes you've just opened up.