Larry

Basically that just means your query failed to run, which means the database spat out an error instead of any results.

Ah, cool! And thanks for sharing your learning experience. If it helps, I still make dumb mistakes, too.

I'd check the registration date. It's likely that multiple records have the same value there if they were created by a mass import.

Ah, sorry about that but kudos for figuring it out and thanks for letting me know!

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.

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;

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?

I'm not quite following the use case here (why you'd update a table to an auto-increment value) but, more importantly, this isn't a prepared statement? Could you provide a bit more code? Also, when you say you're having a problem, what is happening that shouldn't? Are you seeing any error messages?

The header.html file is going to be included from another script, so the reference to mysqli_connect.php needs to be correct relative to that parent script. That parent script should be in the htdocs folder, so ../mysqli_connect.php should be correct (if it's in the xampp folder).

Okay, that makes sense. If you're running an HTML script directly, then PHP code in that script won't be executed. You should instead be running the PHP script that includes the header file.

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.

What do you mean by "when you run the script"? What script are you running? Or, better yet, what URL are you using when you see that result?

Hmmm... your visible tab title there makes me wonder if there's not actually an HTML problem that's at the root here. I'd look for that first. If that's not it, if I recall correctly this chapter probably does an HTML index version first. I'd confirm whether or not that's rendering properly.

I expect the problem is you CANNOT test from localhost without SSL. If you use Let's Encrypt, you can get a free, legit certificate to use for testing purposes.

Ah, okay. Kudos for figuring it out and thanks for letting us know!

I'll look into this and get back to you after the weekend!

I forget if I have examples of this in the book--I suspect I do--but here's an explanation of options for you that should work: https://stackoverflow.com/questions/11693234/php-mysql-gets-value-of-out-parameter-from-a-stored-procedure

If you look at the SQL chapters you'll see examples of how to do fulltext searches in MySQL.

Thanks for reporting that! I'll have the publisher fix it.

Yes, more or less. You'll want to change your naming scheme so that each row of input--which becomes a database row--ends up as part of the same array in PHP. You'll need to play around with what works, but if you do var_dump($_POST) in the PHP code that may help you understand what's coming in from the form.

This is very good detective work and thanks for being so thorough. I'd start by ruling out cases 3 & 4, though. The links are going to come through with HTML entity versions, so %26. You'll never have & in the URL, so there's no need to test and handle that. I'm also not inclined to go to zero-width positive lookahead assertions; that'd probably just complicate things. I just did an online regex tester for case 2 and it matched the percent okay: https://regex101.com/r/AWJdX3/1/ Are you restarting Apache after making changes to the configuration?

Okay, so this kind of thing is a bit tricky. Since you have multiple inputs that are all arrays of related records, I'd start by changing your naming scheme to make them all more overtly related. For example, you'd want exams[X][subject] and exams[X][grade]. If i'm following you on this. I'm not sure I am 100%. But the key is to make the association of the data overt like that. Let me know if it's still unclear.

The browser just isn't finding the CSS file, which means the HTML reference to it doesn't match where the file actually is. Do you have a CSS folder with the correct CSS files in there? Like this: https://github.com/LarryUllman/phpvqs-5ed/tree/master/08

Awesome. Glad to hear it!

If you remove the error suppression operator, you'll see the error messages. You should probably also use some conditionals in there, such as checking that mysqli_num_rows() returns 1 or more records before you attempt to fetch them.