Larry

Marie, what is the definition of the password column in the database (its size in particular) and what are you using to encrypt the passwords?

Thanks for your post and questions! I have been keeping the PHP & MySQL book up to date, and the 5th edition does reflect changes in PHP 7 (the book was written with PHP 7.1.7). I couldn't say for sure whether I'll ever do too much OOP in this particular book, though. It's a complicated subject--my PHP Advanced book spends hundreds of pages on it--and I wouldn't necessarily agree that MVC or OOP is ubiquitous in the PHP community. But these are the kinds of things I re-evaluate with each new addition and appreciate you raising the question!

You're quite welcome and thanks for the nice words!

Yes, your understanding of the pros and cons of this scenario is correct. As for your questions... 1) The only way I know of or can imagine that being possible is by adding login functionality. When the user goes from browser A to browser B, they need to somehow tell the site "I am the same person". 2) Not hard at all! Part of the design of the two applications in the book was so you could take pieces you liked from either when creating your own solution. Here you'd take the login/logout functionality, plus the additional user database table and implement that within the new site. Then you need to tie the logged-in user to the tracking session. You'd still use cookies but in the database you'd associate the cookie value with a specific user. Let me know if you have additional questions!

PHP scripts must be run through the web server application (e.g., Apache). To do that, the PHP script must be run through a URL. So if an HTML form posts to a PHP script, it must be run through a URL, too. Or, looking at it the other way, if you load an HTML page through the file system and then submit the form, the PHP script will be loaded through the file system and do nothing (but likely show the PHP code in the browser).

Hello Badr! Thanks for the interest in the book and I'm sorry about the delay in receiving yours. You should reach out to Amazon about that. Unfortunately, though, I don't know anything at all about the sales or distribution of books, including getting the Kindle version for free with a print copy (although I can say I've never heard of that and it would surprise me if that were true). Sorry I couldn't help!

I feel like using cookies is fairly standard--and reasonable--these days and is the right approach here. Sessions do also require cookies, or a somewhat complex workaround, and are more demanding of the server. All in all, sessions are a lot of work just to store a single number.

Thanks for sharing that!

Apologies if this is due to a book error, but your query uses "id" while the database table uses "quote_id".

Awesome. Kudos for figuring it out and thanks for letting us know!

That's a fine solution! In the other thread I posted what I originally had in mind, though. With programming, there are many ways!

Not a problem to leave it as is. Thanks, though!

No problem. Thanks for sharing what you learned!

It's more straightforward than you might be thinking. Here's how it starts: if ( (isset ($_POST['gender'])) AND ($gender == 'M') ) {

Thanks for letting me know!

Sorry for the confusion here. It's a subtle difference. Here's what the MySQL manual says: and I guess I'd phrase it as ~ being more impactful than <.

The second line is not actually manually setting the cookie, it's manually assigning a value to an element in the $_COOKIE array so that you can refer to it later in the script. I wouldn't say this approach is less secure necessarily, but it's a bit of an artificial workaround (by that I mean it allows you to refer to a $_COOKIE variable before it should have a value).

Good eye and thanks for reporting!

Yeah, sorry about that. Those should be using different cases. Thanks for reporting! Also, could you clarify what you mean by "digital online copy" so I can make sure it gets fixed?

You'd need to start off with what kind of information would be needed. Look at what questions may be asked of the system and what information would be expected in the response.

Ah, shoot! Thanks for reporting!

Just to clarify, this would be an Apache and XAMPP issue, not a PHP one: https://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslrandomseed I assume XAMPP has them commented out by default b/c people may not be using these in particular, so they just have representative values. Personally I never spend any time worrying about the local SSL stuff as it's just a dev environment. As for the bytes argument, the more bytes the more secure but also the more processing required. You'd want this to be an appropriate value for all the parameters of your system.

Unfortunately I'm not familiar with the changes in any detail and don't see anything discussing what to do instead. Sorry I couldn't help on this one!

Thanks for your post and for your interest in the book. PHP7 and HTML5 are the main changes in the 5th edition. Considering everything, you should stick to the 4th edition that you have!

At least a part of the problem is you're referring to variables in the wrong order. For example, one of the first lines in your function is: var regularPay = parseFloat(regularHours*hourlyRate).toFixed(2); But neither regularHours nor hourlyRate has a value at this point. I would recommend two approaches here instead: 1. Start with the smallest concept first. 2. Create comments describing the logic and then implement the logic in code. For example... # See if hours worked is greater than 40 which becomes # Get a reference to the number of hours worked # See if hours worked is greater than 40 which becomes var hoursWorked = document.getElementById('hoursWorked').value; hoursWorked = hoursWorked.toFixed(2); if (hoursWorked > 40) { alert ('Greater than 40!'); } and so on. (You can also use console.log() to output values and results to the console.) By doing this more incrementally you can build up a working model while better understanding what's going on and the use of comments should help you avoid getting too far ahead of yourself.