Larry

For what it's worth, I almost never bother with trying to send email from a local environment. It's just a huge PITA and there can be a ton of reasons why it's not working. It doesn't look like MAMP comes with a mail server, so you'll need to use SMTP to either your ISP's email server or a third-party (e.g., Gmail). Your ISP may or may not allow this, though. But if you google "<your ISP> smtp settings" you might be able to find the settings you need.

Hmmm...sorry about that! I can't seem to find it either now. And I'm not exactly sure what I was thinking at the time I wrote it (now, years later). I don't have scripts created for either--anything I would have created would have been put in the downloadable files--but these are both pretty simple form -> populate database examples. Let me know if you have any questions as to how they'd be implemented. Sorry about the confusion!

Thanks for the nice words! It is appreciated! Unfortunately I'm not sure what's going on with that error message. It looks like it's suggesting that there's a problem with order_contents.print_id as a PRIMARY KEY but it's not a PRIMARY KEY and there's nothing in the SQL you posted that makes it a PRIMARY KEY. I've not seen this before. I'd double-check that the created database in phpMyAdmin matches the description put forth in the book. Thanks again!

Happy Holidays to you as well! Sorry for the confusion on these two related issues. Neither of those scripts exist yet--they weren't created for the book and they're not part of the downloadable scripts. But both should be quite easy to write yourself. Just copy view_orders.php and view_order.php and then update the code to change from orders to customers. Let me know if you have any additional questions about this.

I'm pleasantly surprised to hear that HTML_QuickForm2 is still maintained! I don't have a better solution than what you put forth but that's also a solution I've resorted to using in my dev life, so you should be okay!

Okay, so the code is the same as in the book and the library is roughly the same and the code examples in GitHub are roughly the same. This is going to be hard to debug! My inclination is that either the library doesn't work on HTTP or it has something to do with the sandbox. I would first log into Authorize.net and see if I can view the requests being made. First check that the requests are getting there. Then, if so, check that the requests are receiving the CC dummy values.

Hmmm...it's been a long while since I've looked at this code. What version of the Authorize.NET PHP library are you using? This could be a change in their library since the book was written.

Hmmm...this can be tricky. I'd start by re-evaluating whether it's really necessary to enable SSL on your Mac. Eventually I stopped bothering (I was never using real data that needed to be protected and since it's localhost, the data isn't leaving my computer regardless). But if you do want to continue the first trick is to figure out exactly why Apache doesn't like those settings. I normally start with Apache's "configtest" command, but you'll need to run that using MAMP's Apache. For the Mac's primary Apache you'd run `apachectl configtest`. Unfortunately I don't know what the properly path is to use MAMP's Apache instead, so you'll need to figure that out. Once you do that, `configtest` should give a specific error that can help debug this properly.

Unfortunately I'm not familiar with VSC 2019 and its PHP support. Or what it means to Live View a PHP file in it. Hopefully someone else might know and post an answer, or an internet search turns up the solution.

Hey Vikky! To implement a coupon system, you'd want to start by creating a coupon table. A coupon would have a code, probably an expiration date, and then either be a percent off or a fixed-amount off. In more sophisticated systems, coupons may only apply to certain items or total order amount, etc. You may also want to track coupon usage. Then, as part of the checkout process, you'd need to add a field to accept a coupon. Your programming logic would need to verify that the coupon is valid, and adjust the order total accordingly. You'd want to update your orders table in the database to reflect use of a coupon. That's the basic framework for it; there are myriads permutations on how coupons could specifically be implemented.

Hey! You're having this problem because PHP runs on the server, which means all of your PHP code has already been executed before you see the HTML page in the browser. Secondarily, your button as written doesn't actually do anything. There's no programming logic attached to it. That would require JavaScript, which runs in the client.

Good question! First, I guess I'd say that if having too many database records might be a problem, you probably want to rethink your hosting situation. The space used by fake records should be one of the furthest things from your mind, ideally. I imagine my forums has 1,000-2,000 fake registrations. That being said, you can just run delete queries to remove fake registrations on a manual schedule of your choosing. But it's probably worth trying to implement a couple of things to prevent fake registrations in the first place (reCAPTCHA and then some).

Thanks for your questions and for your interest in the book. I appreciate it! Yes, I think the 5th edition would still be a fine way to learn PHP. It was written using PHP 7.0.6. The current stable version is 7.4.11. I'm not aware of any deprecated code, but I also haven't written a guide for that. Most of the feature changes that have come along are in the more advanced and esoteric areas of the language. Yes, this book is designed to be an entry into the PHP and MySQL book. Yes, forum posts can be pinned to the top of the list. Let me know if you have any additional questions!

Okay, I think you should be able to do something like $(this).parent().prev().text(); Or it may be parent(). parent(). You can experiment with manipulating the DOM in the browser's console window to get the right solution. All that being said, if you have a form whose values are going into a database, I'm not quite following what the benefit is of updating an HTML table, too. The form selections already indicate what the user wants. You probably have a good reason--or I may be missing something--but I just wanted to raise the question.

It's probably help if you could share that part of the DOM here so we could understand how you might navigate it.

You probably want to be using $('#hway').text(returnval); as the DIV doesn't have a "value".

I would always promote the benefits of walking away and returning when it starts to get muddled. Absolutely move on in the book and then come back to this in a bit!

I wouldn't create multiple $color_ variables. Just create and use one $color variable.

Ah, okay. So $phpvqs et al. represent their own indexed arrays, which means that indexing $phpvqs at 'PHP VQS' in the main array is the same as if you defined that sub-array there. Or put another way, imagine $phpvqs was equal to 2. Then $books['PHP VQS'] would also be 2. As for the actual variables $title and $chapters, those are named and created within the foreach loop to represent the index and the value at that index. These could be named anything--$k (or $key) and $v (or $value) are also commonly used. So the foreach loop doesn't "know" anything about the structure of the innermost arrays but as the programmer, we do and can use more descriptive variable names accordingly. Let me know if anything is still unclear.

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?

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.

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.

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

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!

Yeah, that can be pretty common. Kudos for figuring it out and thanks for letting us know you did!