Jump to content
Larry Ullman's Book Forums


  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by Larry

  1. 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.
  2. It's ~450 pages. I'm gearing up for another release.
  3. Did you figure out how to access the XAMPP Control Panel or do you need help with that?
  4. 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!
  5. I assume your path is incorrect. Where is the uploads folder located at (the absolute path)?
  6. That's fantastic! Kudos! For the benefit of others, would you kindly share what the problem and solution were? Thanks!
  7. 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).
  8. 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.
  9. 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).
  10. 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.
  11. 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.
  12. Per it sounds like you've got the login system bit worked out. Answering your other question there...
  13. Oh, hey, that's awesome! Kudos and thanks for letting me know!
  14. Ah, okay. Thanks for explaining! I guess my inclination in this case would be to make a command-line utility that does the work you want to do and you provide this utility with the path to a file when you invoke it. The main issue in my mind is that "uploading" a file from a computer to itself is a marker of making a process more complicated than it needs to be. You could also write the command-line utility to accept a directory as an argument and then iterate through that directory. Let me know if this is still unclear.
  15. Thanks for the update. I'm still a bit confused by the scenario. If PHP is running on the same Windows machine as the files, then it should be able to access the full path. If not in the web version of PHP (presumably due to permissions), then the command-line PHP can. Apologies if I'm missing something.
  16. Ah, okay. If PHP is running on your PC (on a webserver there) you can definitely access the file system using PHP.
  17. I imagine it _may_ be possible but it's the kind of situation where I feel like the answer is "this is probably not what you should be doing". In that it feels like you're only using PHP here because you're most comfortable with it. If you're starting with C++, my inclination would be to try to do all the work in C++. But let me know if I'm missing something.
  18. If you put the file in a folder named "ch01" then the URL would be http://localhost/ch01/first.php.
  19. There could be several reasons why. To debug it, you'll want to take the src value for the img (from the browser HTML source) and run that directly in a browser to see what, if any, PHP error is reported.
  20. Thanks for the information! Could you clarify what edition and version (e.g., print) you're using? Thanks!
  21. Hmmm... you could put the error suppression operator before mail() calls, although you could also just comment out the mail() calls, for that matter.
  22. What's the actual problem you're having? What errors are you seeing, if any? All that being said, there's kind of a lot of problems with that code from a design standpoint. Way too much undocumented magic going on. The dynamic fetching of specific fields is dubious.
  • Create New...