Jump to content
Larry Ullman's Book Forums

Larry

Administrators
  • Posts

    5388
  • Joined

  • Last visited

  • Days Won

    154

Everything posted by Larry

  1. If you just google "xampp mail server windows" you'll find plenty of tutorials on the subject. (I don't have XAMPP on Windows, so I don't know off the top of my head.)
  2. From there error messages, you have two issues to resolve. The first is you haven't configured a local mail server. The second is your error handling script still references the $e_vars variable, which it no longer has defined as an argument.
  3. There are two issues here. One is that there's an error going on in the script. The second is the error handling isn't working properly. For the latter, you don't mention what version of PHP you're using, but I expect the warning in the box applies: https://www.php.net/manual/en/function.set-error-handler.php Remove the last parameter from the my_error_handler() definition, as well as the use of that $e_vars variable within it. Once you fix that, you should properly see the actual error that's happening on the page.
  4. Glad that's working for you and thanks for letting me know about the emails. I'll look into it. Cheers!
  5. My inclination is it's either not being stored or retrieved in a format that PHP can use. I'd check/confirm your column type. Also, it's best not to use "Date" as a column name since it's also a keyword in MySQL. That being said, I'd have MySQL return the data in the format you want, rather than ask PHP to convert it.
  6. Hey Max. Kudos for figuring it out and thanks for sharing the solution. The first thought that came to my mind would be to store the coordinates in separate columns. In other words, split the coordinates upon receipt and then store them in two columns. That'll make future work easier to do.
  7. Hey Nick, are you setting a "from" address when you send the email? Also, it may help if you use placeholder values when describing the problem here. I'm not 100% sure I understand the distinctions you're trying to make (e.g., sending the email to me vs receiving an email or all the uses of "me").
  8. So you have the script D:\xampp\htdocs\phpmysql4_scripts\ch09\view_users.php which is including ../mysqli_connect.php. The ../ bit means "go up one directory from the current directory". Up one directory from D:\xampp\htdocs\phpmysql4_scripts\ch09 is D:\xampp\htdocs\phpmysql4_scripts, so the code is looking to include D:\xampp\htdocs\phpmysql4_scripts\mysqli_connect.php.
  9. Hey Marie. From what you describe, if the problem isn't with the database then it's with your code. In other words, it could be giving you that error message for the wrong reason. Looking through the downloaded code, I don't think this book uses a "form functions" file but it does use a login functions file.
  10. Thanks so much for the kind words and for the interest in a Python book. I truly appreciate it. Unfortunately I'm not well versed in Python, so that's not in the cards. Thanks again, though!
  11. Yes, that would be my assumption: that it's doing a conversion. If it wasn't, then the SHA2() function would return an error for an improper argument.
  12. Thanks for your questions and for the nice words. For the first question, when executing queries like this, there really is no "automatic". In a real application these queries would be executed by code that verifies the results as part of the process. For example, using PHP you could start a transaction, fetch the balances, adjust the balances, fetch the new balances, verify, and then commit. For the second question, what you describe is called a "race condition" and can be prevented by implementing locks. So you'd lock the row, run one update, and then unlock the row. A subsequent query that would theoretically make a quantity negative (assuming that wasn't allowed) would then fail.
  13. Thanks for your question, and for your patience! Mostly it's just hard--nearly impossible--to have a full-time job and a family and a house, etc. and work on the book. This is part of the reason why I don't spend any time on social media, too. However, finishing the Yii book is always on my mind. In fact, I took two weeks of vacation last month and spent that on the Yii book. I got a rough draft of half of what was remaining done. I still have the last five chapters to rough out, and then polish these last eight. So the short answer is: yes, it's still being worked on and I just made some decent progress by using my vacation time, but it may still be a while before I complete it.
  14. Yeah, that'll do it. Kudos for figuring it out and thanks so much for sharing the solution!
  15. It might be best if you start coding by documenting what you want to do and then convert those comments into code. For example: Add a record to the products table. Get the product ID for the record just added. If there are sizes, add one record to product2size for each size. This uses the product ID already fetched and the size ID, which comes from the HTML. If there are product categories, add one record to product2pcat for each category. This uses the product ID already fetched and the category ID, which comes from the HTML. So with that written out like so you can see for starters that you don't need to fetch the product ID multiple times, just once will do. You'll also see that steps 3 & 4 are parallel, not dependent upon each other (from what I can tell). But your code for step 4 includes "isset($sizeError)". I don't see why that's there. That may be why the third query isn't running? From the code and your comments it looks like the second and third queries could be executed in either order as neither depends upon the other. There's nothing particularly special about running these three queries. I think you have some logic issues. As I recommended before, if you use a slew of print statements you could see what is or is not true or happening. It's a blunt debugging tool, but it works. Another likely cause of confusion is you're using both prepared statements and non-prepared statements. That's not really a good idea, from the point of comprehension. Moreover, you're not using prepared statements for the two queries that would benefit the most from the prepared statements. By using prepared statements the second and third queries can be executed within the foreach loops, nicely.
  16. One issue I can see is that you call `$product_id = $stmt->insert_id;` a second time, but you already have the $product_id value, so that shouldn't be necessary. And there's a good chance `$stmt->insert_id` won't return anything a second time it's called, but I could be wrong about htat.
  17. Could you be more specific than "the query did not run"? Did PHP attempt to execute the query but it didn't succeed? And, if so, what was the MySQL error? Or is it not getting to that point in your code where PHP is even trying to execute the query? You may want to litter your code with print statements to see what is or isn't happening, and what values exist where.
  18. Yes, there's a typo there that's my fault--sorry!--in that you should be selecting the password from the database, too. You have that in place in your code now. From your debugging work it seems that if (password_verify($p, $row['pass'])) { is returning false. That means the problem is either with $p or with $row['pass']. I would start by registering a new user with a new password--just "password"--and testing that, just to rule out that you haven't mistakenly used the wrong password (i.e., the code is actually working properly!). I'd also print out the value of password_hash('your password') and make sure that entire value is being stored in the database (using phpMyAdmin or the like).
  19. Ah, your code uses `if define()` when it should be `if defined()`. That's what your error means: define() requires two arguments, the constant name and the value, but you're only providing one (because you meant to use defined()).
  20. Ah! Kudos for figuring it out and thanks for sharing what the cause was!
  21. Thanks for the nice words. Yeesh on this error message, though! That command creates four keys (or indexes): on user_id, on username, on email, and on the combination of username and pass. None of those seems to be 100 bytes! My hunch is it's the login key that's causing the problem. Try removing that from the command (and delete the comma after `UNIQUE (email)` and try it again.
  22. You're most welcome. I'm glad to hear it and thanks for posting this!
×
×
  • Create New...