Jump to content
Larry Ullman's Book Forums

Larry

Administrators
  • Posts

    5390
  • Joined

  • Last visited

  • Days Won

    154

Everything posted by Larry

  1. I'm sorry, but I'm not quite following what your exact question is here. On a cursory glance, your code looks correct. Is something not working properly? If so, how?
  2. You haven't quite provided enough information--I have no idea what it means to click "the upgrade option"--but it sounds like this is a simple case of not using the correct password.
  3. Sorry for the delayed reply! As for why you need to include (not call) the config.inc.php file on every page, that's how you ensure that every page in the site has access to the same information and is configured to behave in the same way (e.g., handle errors). This is both a common thing to do and rather important. As for the other specific questions, are you still unsure about those? If so I'll revisit the code and the book to ensure I can explain it properly. I don't remember that logic off the top of my head.
  4. Hey Jim, So sorry for the delayed reply! Thanks for the nice words and for the interest in another edition. I truly appreciate it. Right now I don't have any plans to update that book, nor has the publisher asked. So I'm not sure what to make of that other than it wouldn't happen in 2020 or the first half of 2021, I don't imagine. Thanks again and I do hope that you and yours are doing well, too! Larry
  5. Thanks for the clarification. I may have overstated, or suggested using isset() too bluntly. It really depends upon the situation and how overly careful you may want to be. And what level of error reporting you have in place! If I recall correctly, empty() doesn't throw a warning if a variable isn't set, but I'd test that first (i.e., your first example is probably fine but maybe isset() isn't necessary). You could/should do isset() on $_POST['confirm'] before referencing it, but you can't do isset() on a condition, as you have in the second example. Let me know if anything is still unclear!
  6. Yeah, that can be pretty common. Kudos for figuring it out and thanks for letting us know you did!
  7. That's a really good technique, Jay! Thanks for sharing that!
  8. Thanks for catching that and for letting me know! I'll pass it along to the publisher.
  9. You need to execute the query from within the FOREACH as that's the only place you have access to each individual selected size.
  10. it's in the sql.sql file: https://github.com/LarryUllman/phpmysqlvqp-5ed/blob/master/sql.sql
  11. Ah, no, you can't do that. You'll need to use PHP to break the multiple selections into their single counterparts and insert each one separately.
  12. Add the "multiple" property to the opening select tag: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/select
  13. I haven't used PHPStorm in a long while, so I'm not positive but maybe adding id="gender" to both of the inputs would solve it.
  14. I'm not sure what you mean by "combine the two queries together" as one is an INSERT and another is a SELECT. They cannot be combined into one. But from the looks of it what I think you should be doing is executing the INSERT query, then checking for affected rows, then executing the SELECT query. Also, separately, it's pretty weird to print out JavaScript like you're doing as opposed to just redirecting the browser directly within PHP.
  15. It wouldn't make any sense to prevent a user from using the same password as another user. I've never seen that done. As for forcing people to reset their password, that makes for good security but it's still not that common and definitely not common--in my experience--in places it matters most, such as financial institutions. I also personally find prevention of re-using a password to be annoying, although not a terrible inconvenience when using a password manager. My current approach is pretty strongly a matter of: tell users how to be smart about their passwords but don't put many restrictions on what passwords they actually use.
  16. I assume you're putting blank values into the database then. Right now you bind 7 variables to parameters but only assign values to 5 variables.
  17. Thanks for sharing what you found! Personally, though, I'd still use the GET method here. POST doesn't really make sense in this case.
  18. Most likely this is because you don't have an input named 'pass' in your form. On another note, though, it's not a great idea to store the user's password in an unencrypted manner.
  19. Thanks for the interest in the book! I do appreciate it. I don't actually have a list of changes, however. I'd recommend checking out what's changed in PHP since the book was written. The major changes there are probably most important for your case. Best wishes with your studies!
  20. Okay, two ways of going about this. The first is to make a SELECT menu whose option value is the category ID and then you add the JavaScript that redirects the browser when the selection changes. Alternatively you could create an unordered list of links that's collapsed into one menu using JavaScript and CSS. I think the later is likely more common.
  21. As far as I know, the only way to make a SELECT work as a list of links is to use JavaScript to redirect the browser upon changing or selecting an item in the list. I don't think that's something you want to do. As for your MATCH...AGAINST, you probably don't have a fulltext index set on sizes.size, which could cause that error.
  22. So I assume that limiting by number of views means a certain number of views within a specific time from (e.g., 10 per month). I'd start with the standard subscription model, where you store the date and then refresh the date with every successful payment (i.e., add a month). This separates active subscriptions from inactive ones. Then create a way of recording views, maybe in another table. When the user views a page, check how many views they have in the current period (i.e., since their last payment date). If they have none left, print that message. If they have any left, show the content but update the record of views.
  23. It definitely sounds like the virtual subscription model is the correct choice for you.
  24. From the error message it looks like you're trying to treat a variable as an array but it has a null value (i.e., it's not an array).
×
×
  • Create New...