Jump to content
Larry Ullman's Book Forums

Larry

Administrators
  • Content Count

    5223
  • Joined

  • Last visited

  • Days Won

    143

Posts posted by Larry


  1. I played around with this a bit. Again, I might entirely rethinking the logic, but assuming we want to keep two date columns, this create works:

    CREATE TABLE `carts` (
      `id` INT(10) UNSIGNED NOT NULL AUTO_INCREMENT,
      `user_session_id` CHAR(32) NOT NULL,
      `product_type` enum('coffee','goodies') NOT NULL,
      `product_id` MEDIUMINT(8) UNSIGNED NOT NULL,
      `quantity` TINYINT(3) UNSIGNED NOT NULL,
      `date_modified` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
      `date_created` DATETIME DEFAULT CURRENT_TIMESTAMP,
      PRIMARY KEY (`id`),
      KEY `product_type` (`product_type`,`product_id`),
      KEY `user_session_id` (`user_session_id`)
    ) ENGINE=InnoDB  DEFAULT CHARSET=utf8;

    I put `date_created` second and changed it to a DATETIME and then it can use the CURRENT_TIMESTAMP as the default so the INSERT query doesn't need to be changed.


  2. Okay, I just installed the DB and script and upgraded PHP to 7.3.8. Sadly, I am NOT seeing the error at all. This is using PHP's built-in server, although it'd surprise me if this was an Apache issue. I'm also testing this on a Mac.

    Unfortunately it's really hard for me to come up with a solution without being able to replicate the problem. From everything I'm reading online, having the _destroy() return a boolean solves the problem for some, but of course the code in the book already does that. 


  3. Sorry for the delayed reply; had to take the time to set this all up on a server again. I ran the script with the 6 changed to 8 and it did also allow me to register. Then I realized it was probably because of the forward lookahead and the parens and where the minimum does and does not apply. Changing the minimum to apply to the whole grouping works better:

    if (preg_match('/^((\w*(?=\w*\d)(?=\w*[a-z])(?=\w*[A-Z])\w*)){8,}$/', $_POST['pass1']) ) {

    All that being said, since I wrote this edition, both the industry and my personal feelings how validating passwords has changed. If I were to do this again today, I'd just require a minimum length (say 12 characters) and not care at all what characters are in that password. With modern computers, "thisismypassword" or "this-is-my-password" is more secure than "1Ad92q" for a number of reasons. 


  4. I've reviewed the MariaDB documentation for timestamp: https://mariadb.com/kb/en/timestamp/

    It looks like the first timestamp column in a table has different behavior than the second. We want date_created to be automatically set on creation, but not update. We want date_modified to be automatically updated on each change. To get that behavior you'll need to change the DB and the SQL queries. Assuming we want both the date_modified and the date_created, I'd be inclined to put the date_modified column first and then populate date_created to the current timestamp upon INSERT. 

    Or just drop the date_created column entirely and update the SQL commands accordingly.


  5. Ah, okay. First, thanks for all the details. Second, I would advise against trying random things as you debug. It's a natural thing to do but tends to lead to more confusion. Here, for example, the upload script purposefully doesn't append the file extension, but that's totally okay because the show_image.php script doesn't use the file extension either. So that's actually correct and you definitely don't want to add the .jpg extension to the uploaded file (for starters, what if the upload was a PNG?). 

    Normally if you're getting this result it's because your path to the file is incorrect. That your upload script uses ../../ch19_uploads/$id but show_image.php uses ../ch19_uploads makes me think that's the problem (assuming show_image.php and the upload script are in the same folder). Again, I definitely wouldn't move the folder, I'd just make sure you get the file path correct in the code. You can also try using an absolute path to the folder in your code. 


  6. It's not a matter of secrets. Forums like these or Stack Overflow are here expressly to share information and to help others. Honestly, the absolutely best thing to do would be to use mysqli_error() b/c then MySQL will tell you what the problem is, whereas we're just guessing. But without that knowledge my best guess would be that the PHP user for the script doesn't have execute permissions to run the stored procedure. Or you have the database wrong. In either case, mysqli_error() should tell you the actual cause.


  7. This kind of problem is a PITA to debug b/c it could come from several places: the value stored in the database, the value retrieved from the database, the value put into the HTML, or the value displayed in the browser. I don't think you want to go to some converter method; it's best to solve the actual problem. I'd start by confirming how the values are stored in the database. Make sure the database is using UTF8 everywhere, especially on the specific table and column. Make sure you're using UTF8 when connecting to the database, both directly and from PHP. And then make sure your HTML page uses UTF8, both in the HTML encoding and in the encoding used by your IDE/text editor when saving the file. 


  8. Sorry about the delay and thanks for reminding me! The solution here isn't immediately obvious so I had to hunt around a bit. It looks like the write session function is what comes into play here (per the PHP manual), but that method returns true, assuming we're looking at the same script. This is a wild guess, but does it get fixed if the close session function is changed to   

    mysqli_close($sdbc);
    return true;

     


  9. I don't know the answer to this one off the top of my head. You might be able to use imagmagick or gimp? I really don't know whether this would qualify as OCR or not? I imagine you'll need to find some software that runs on the server that can do the work, then upload the image via PHP and call the software via PHP through an exec() command. None of this would be easy or obvious.

    If you already have a JS library that works for the reading of the image, can't you just have JS do the math, too?


  10. To clarify, the chard ID is not the same as the token. The token is the representation of the payment method, which is used to create a charge. 

    As for not seeing the charges in the Dashboard, you are looking at test data, which should show the results. I'd look at the logs in the Dashboard to see if requests are being made and also confirm you're using the right API keys.

×
×
  • Create New...