Jump to content
Larry Ullman's Book Forums


  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by Larry

  1. Hey Hector! Thanks for the interest in the book and it's great that you have a target project in mind. The book does cover how to have multiple users with login/logout, so it'll give you the bones of what you want.
  2. Excellent. Kudos for figuring it out and thanks for sharing the solution!
  3. Thanks so much for the nice words. I really appreciate it. Kudos for figuring out the MySQL question! As for the redirect it sounds like you just have a bug in your code somewhere. Find the redirect line and see that you aren't adding an extra "http//" somewhere.
  4. That seems like you're on the right path. I'm not quite following what the problem is. You say it gives you an error when you do 0, but that seems like the correct behavior, no?
  5. Here is a somewhat similar example: https://github.com/LarryUllman/phpmysqlvqp-5ed/blob/master/ch11/show_image.php
  6. My inclination is since you're using stored procedures already, put as much logic into the stored procedures as you can. But if you do need the cart contents on this page, that's fine. I'm a little confused by this line, though: if ($row['users_id'] == '0') I'm not sure why you're quoting a number. Also, if there's no users_id for a cart, would that have a 0 value or a NULL value? I would think the latter, but it depends upon how you defined it.
  7. There's nothing obvious in the code that's wrong. You'll need to do some debugging here. Start by verifying that the stored procedure is being called. Then verify the values of the variables. Run the stored procedure using phpMyAdmin (or the mysql client) using those same variable values, etc. In short, you'll need to use lots of print statements, trial and error, here!
  8. The content-type would differ based upon the type of image. This is why I suggested using the mime_content_type() function to dynamically get the MIME type and then provide that dynamically in the code.
  9. Yes, you do need to change the content-type header. It ought to match the content type of the file (i.e., of the image). You can use the https://www.php.net/manual/en/function.mime-content-type.php function to get that from the actual file on the server.
  10. Unfortunately I don't know the answer to this one. Sorry!
  11. My guess is the MySQL user you're using from the PHP script doesn't have execute permissions to run the stored procedure.
  12. If you Google "htaccess force ssl" you'll come across articles that explain this, like this one: https://www.siteground.com/kb/how-to-force-ssl-with-htaccess/
  13. This happens when there's an error with your query (i.e., it causes a MySQL error; it doesn't return 0 or more results). You should apply the standard MySQL debugging techniques: print out the query and run it using another interface or just invoke mysqli_error() directly.
  14. It's ~450 pages. I'm gearing up for another release.
  15. Did you figure out how to access the XAMPP Control Panel or do you need help with that?
  16. That looks totally fine to me, and you'd create a unique index on the combination of post_id and user_id, which restricts each user to only liking a post once. Nice work!
  17. I assume your path is incorrect. Where is the uploads folder located at (the absolute path)?
  18. That's fantastic! Kudos! For the benefit of others, would you kindly share what the problem and solution were? Thanks!
  19. Thanks for the nice words! It sounds like maybe you jumped to a later chapter. One of the earlier chapters (8, maybe?) talks about having a PHP script both display and handle a form. It explains what's going on here in more detail. The short answer is the same PHP script is being accessed in two different ways (i.e., via GET to display the form and via POST to handle the form's submission).
  20. I get what you're saying, however, the email address is only available when they are logged in, whereas the session ID is available when they are logged in and when they are logged out. So it always works on every computer. To maintain the session across computers (when logged in), you just need to associate the email address with the session ID. But you can still rely upon the session ID whether they are logged in or not on that other computer. For example... 1. User is on computer A (or even just browser A) but not logged in. Session ID is stored in a cookie and provides access to the cart. 2. User logs in on computer A. Email address is associated with the session ID. Session ID is still stored in a cookie and provides access to the cart. 3. User logs out on computer A. Session ID is still stored in a cookie and provides access to the cart. 4. User is on computer B but not logged in. Session ID is stored in a cookie and provides access to the cart. Currently this is an empty cart, which is reasonable. 5. User logs in on computer B. Email address is used to find the existing session ID. Session ID is still stored in a cookie and provides access to the previous cart. * 6. User logs out on computer B. Session ID is still stored in a cookie and provides access to the cart. So using the session ID approach, the user *always* has access to the cart (or, more precisely, the site can always find the user's cart). The only catch (the asterisk above) is when the user logs in the site needs to handle the possibility of two populated cart sessions: one while logged in on computer A previously and another while not logged in on computer B. Of course it's entirely up to you, but this is how I'd do it.
  21. That all sounds fine. The email address is effectively the same as the user ID, except for being a string instead of a number. However, I'd be inclined to still rely upon the session ID for primary cart access. It's stored in a cookie and exists whether or not the user is logged in. So if the user is logged in, does stuff, and logs out, the cart isn't suddenly empty. The only additional logic then is reflecting the user's email address in the Cart table when they log in (and, again, avoiding duplicate sessions).
  22. That means your SELECT query isn't working. You'll need to run it separately on the server to see what the results are (i.e., what the error is). or Invoke the mysqli_error() function to have PHP spit out the MySQL error that occurred.
  23. Good question! So you'll need a way to tie sessions to users. The sessions are separate from any user as-is. There are three paths: - Add a cart ID column to the user's table - Add a user ID column to the cart table - Create a new users_sessions table In the second case, you'll want to allow for null values, as there is no user ID until the user has logged in. In all of the cases, though, you'll need to add logic that makes the connection between the user and the session when they log in. At base, this is just simply an UPDATE query or two. The tricky bit is if the user has two carts. You'll want to think about how to handle that. It may be a matter of always using the most current, or always using the non-empty one, or merging the contents of two carts together.
  24. Per it sounds like you've got the login system bit worked out. Answering your other question there...
  • Create New...