Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Improve examples for MySQLi to show use of prepared queries #60
The current documentation shows queries being made using variable interpolation. While in this particular case there is no SQL injection vulnerability, new developers should not be expected to be able to spot this or know what prepared queries are / how to use them.
I swapped up the order of the examples so it progresses from "simply query" to "prepared query" and added an explicit comment as to why a prepared query should be used.
Thanks for the PR! I'm not sure, though, what to do with this example; it certainly isn't the kind of code that should be used in production, but several of these issues are adressed in the comments (among others, that the
If these examples are considered so bad they shouldn't be used in "real code", then I would argue they should be deleted altogether. I don't think this set of examples is that bad. While I don't regularly use mysqli myself (I prefer PDO but spotted this issue while helping others), the only other obvious changes I can see are escaping values for HTML properly and adding
(In this case I was focusing on the SQL injection issue and also grepped the other mysqli and PDO documentation for similar issues, but found nothing obvious where it wasn't explicitly demonstrating SQL injection. Proper HTML escaping probably warrants a pass over the entire manual in its own right and thus a separate PR - it also doesn't lead to (potential) server side code execution (SQL is code) or data leaks)
Examples in the official documentation should be examples that new developers can copy and paste and adapt to their needs without falling into any big traps. They are going to do this without reading the entire page in many cases. Yes, experienced developers are almost certainly going to think the result is still terrible, but it should work and it should not lead new developers into obvious / major bad practices - in this case concatenating strings to create SQL queries. My view on this is, as a general rule, and especially for less experienced developers who aren't going to know when they can not use them, always use prepared queries (and I think the documentation should lead developers to doing this).
Regardless of how more experienced developers view this code, developers new to PHP, many new to programming, are going to copy and paste it - including just looking at and taking the part of it that looks like what they want to do this minute.
They aren't going to (and I don't think they should be expected to):
FYI: I am not a PHP maintainer, I am just another frustrated PHP developer.
"Examples in the official documentation should be examples that new developers can copy and paste and adapt to their needs without falling into any big traps." The whole mysqli documentation is one big mess. No one should ever look at it and think this is something, which I can use in real code.
I would love to provide simpler more contemporary examples if only I could. I am afraid the general public's opinion is you should not use this extension and nobody wants the manual updated.
While I admire your willingness to fix one problem, you actually introduced more. Don't take this the wrong way, but I want to list out the problems:
If this example were to be fixed it should look something like this:
What I have fixed:
After testing this locally I confirm this is a working piece of code. It's a code I would use for teaching purposes, but not in production code. After all, the purpose of the manual is to teach good practices, not provide production ready code. In production code I would go for DB abstraction library with PDO underneath.
P.S. I just saw you supplied a correction in which you added
I was specifically looking to fix one issue - and an important one (in my opinion). I don't have the time right now to do major rewrites. If you look carefully most of the content is from the previous version - as I mentioned, I moved some of the examples around to make more sense.
This is open to debate. Yes, I personally prefer extensions to throw exceptions and emit warnings (this is why I'm proposing to change the default error mode on PDO on the internals mailing list). All the documentation is written assuming that users don't change the defaults.
My argument for keeping the code as-is in this regard would be that this code works "either way". Part of the example can be copy and pasted into an existing script and it will work.
Not my code. And again, not a hard and fast rule - while not recommended, in many cases it has no meaningful performance impact and is perfectly fine to use.
Again, I just repeated what the examples here are already doing.
Again, not my code. While foreach can be considered "cleaner", there's no real impact.
Again, not my code - I only updated the existing example so it still works. This is an example to show what can be done with the mysqli result object.
The example never calls
Not my code.
An actual issue with my commit! Fixed.
... perhaps you should consider submitting your own PR rather than trying to rewrite basically unrelated PRs. As I mentioned several times, including in my initial opening comment on this PR, this PR is to fix one specific issue with the examples.