Larry

Ah, interesting one! The trick here is to find a reliable way to consistently order the results. If, say, "ORDER BY state" doesn't do it, then you should either sort by a different column or sort by state and a second column. That's probably not "ORDER BY state, pet_id", but something along those lines.

Ah, that would do it. Kudos for figuring it out and thanks for sharing the solution!

Thanks, Jim! As for that statement, it's a bit complicated b/c it has to do with the database's caching mechanism and how resources are shared, etc., etc. What's always true is that prepared statements are reliably more performant when the query is run multiple times in the same script. If the query is only run once, it's hard to say for certain without doing some deep investigations. But prepared statements have a secondary benefit in that they are (perhaps only slightly) more secure than using straight SQL with escaping functions.

My guess is the problem is because that last closing LI should be within the if ($current_page != $pages) { block.

Hey! Thanks for the question. Yes, I would say it'd be a best practice to set ownership of the directory to the user that the web server runs at. This could be www-data or apache or something else. This would be more secure than just open permissions. I would still want to keep the folder outside of the web root directory and only store things there and fetch from there after proper vetting.

I'm having a hard time following what your actual questions are. Going forward, I'd really appreciate it if you asked explicit questions--with question marks--so I can know whether I'm answering the right thing. You should also, please, create separate threads for separate questions. That makes for better forum hygiene, thereby improving the usability of the Q&A for others. Thanks! I think you're asking: > Why use an absolute path for the redirection? It's more reliable across all browsers. And possibly: > Does PHP operate in a separate realm than JavaScript and jQuery? Yes, PHP runs on the server, not in the browser. JavaScript and jQuery run in the browser, not on the server.

Thanks so much for the nice words, Jim! As for your question, I generally think stored procedures would be faster than prepared statements, but I don't have hard data on that. I don't believe the difference between the two is tremendously significant in terms of speed. Certainly prepared statements are a bit easier to create, use, and debug.

Could you clarify what the actual question is? But just to point something out, the reasons using cookies is better than passing the value in the URL are: 1. Cookies are definitely more secure and less obvious than doing that. 2. Cookies are more reliable than passing in the URL. If your site depends upon this value, every link and every form submission must be certain to continue to pass along the value.

Yes, the bootstrap-navbar CSS is fairly standard. The Twitter Bootstrap framework is used on nearly 200k sites. Yes, echo and print are synonymous for all intents and purposes.

The password is encrypted by password_hash() using an automatically generated salt--a random value that makes the encryption more secure. If you execute password_hash() twice on the same password, you'll get two different results. This is why your query isn't returning any matches and why you have to use the password_verify() function instead.

Hey! Sorry, but there's really not enough information here for me to go on. Could you walk through this in more details? Which scripts are you using? What exact steps are you taking? How does it fail? What debugging steps have you tried and what were the results?

Hmmm...the code was working as I tested it when I wrote the book. I imagine the problem is somewhere else. The value there comes from $_SESSION['cart'][$row['print_id']]['quantity'], so I'd check if that value isn't being changed earlier in the script as it should be.

Ah, the problem is in your form where you refer to $row[1] and $row[2]. Numeric arrays in PHP are indexed starting at 0, so the two values fetched from the database are at $row[0] and $row[1].

You're quite welcome. Good luck with your project!

What you want to do is think about how malicious code is executed. SQL injection attacks are dangerous because user-submitted values are added to a query run on a database. Storing and displaying (in an HTML page) user-submitted values are dangerous because JavaScript is executed simply by being part of a web page. With PHP code, that code is dangerous when it's executed. That means hard-written in a PHP script and then executed or run through a PHP function like exec(). You never want to run user-submitted values through exec(). So you're pretty safe in that area if you never do that. You should also be careful when fetching a file from the server and sending that to the user (through the browser). You have to put in checks to make sure you're not carelessly making any file available for download.

Yes, XAMMP includes MySQL. From the FAQ, it looks like XAMPP does not set a root user password: https://www.apachefriends.org/faq_windows.html You may or may not want to do that. But then you'll need to create a MySQL user with the username "username" and a password of "password" (or a different user and then use those appropriate values later).

Yes, one of the strengths of PHP is you can use it in many different ways. If you want to go the MVC route, you can do that. You can use frameworks or not. You can use OOP or not. I would do any of the above given the particulars of the project.

Regenerating the session ID requires sending a cookie, which can only be done before anything--blank space, HTML, whatever--is sent to the browser. Something before that line, in this or another script, is creating output, which is the problem. You'll need to figure out what that is and resolve it.

Thanks for the nice words, Andrea! Really appreciated. It sounds like you're on the right path. I would start by performing a minimum of validation in your PHP code upon submission. For example, if the content provided includes Next, use prepared statements or an escaping function when inserting or updating the record in the database. So you're storing the HTML as provided, but preventing SQL Injection attacks. Finally, there's the issue of outputting the HTML in the browser. You don't want to use htmlentities() there, presumably, because you want to use the actual HTML. However, you don't want to just output it without any safety measures. After fetching the HTML from the database, I'd recommend running it through strip_tags(), providing as the second argument the list of tags that should be allowed.

Depending upon how you installed MySQL and on what operating system, there may or may not be a password set already. Earlier you specifically referenced page 440, and the steps there are just logging into MySQL. They aren't trying to set the password.

Well, they're different examples in different chapters, and the context for both is different. I wouldn't do too much apples-to-oranges comparison at this point. Rather, wait until the later example chapters in which everything is put together. And, to be clear, Script 9.7 cannot use the login_functions.inc.php logic because that's not created for another three chapters. Generally speaking, there is an argument--regardless of company size--in modularizing as much functionality as possible. By doing so you improve re-usability and make maintenance and debugging easier.

Thanks so much for sharing that!

Sorry for the confusion here! I wouldn't worry at all about the "YES" being wrapped like that. It's just a matter of the size of the terminal window and has no impact on the functionality. I'm not sure what's going on the second time. Do you know what the proper MySQL password is? It's almost certainly not "yes".

Ugh! Good catch. Thanks for flagging that! The corresponding code on the previous page (Step 3) is correct.

> Is it good practice to combine the "view users" and "search users" scripts in the same PHP file? Um, I think it's a fine thing to do. But it could be complex, as you're finding. > How do I amend the "SELECT COUNT(user_id) FROM users" query for pagination purposes to accommodate the search functionality? In its current form it continues to displays ALL the pagination links after a search query. You need to change the count query so that it matches the search query, so "SELECT COUNT(user_id) FROM USERS WHERE this AND that AND whatever". > Is there a more efficient way to formulate the following search query: Undoubtedly, yes. I would start by removing the things that no one is likely to search on, like the status or date_created. Probably also type and country. I would envision this as a simple user search, on just the username and email address. Then you could offer a more advanced search that factors in those other things, if need be.