Larry

Hmmm...interesting one. My question is whether the child window needs a dynamically generated name. Couldn't it always use the same name, which would solve this problem? Or is it likely/necessary that the user may want multiple child windows open at one time?

Sorry I don't have a better answer for y'all, but this has really surprised me. I'd not seen it before. Although to be clear again, it should matter whether form data is being submitted or not (i.e., you shouldn't need the enctype if you're submitting the form). Also, over time you'll learn how to only refer to form values if they have values, which is what really matters. Thanks for sharing the feedback!

It's great that it's working that way for you but this is really surprising to me. That enctype is only required when a form also submits file data. What browser are you seeing this in?

Thanks! I've not tried it on High Sierra myself yet. I don't know anything about that support yet, although the requirements just say 10.10.3 or later. But if you did the normal DMG installer, it should have created an XAMPP folder in /Applications (if I recall correctly), with the web root directory being /Applications/XAMPP/xamppfiles/htdocs.

Hmm...thanks for sharing what worked for you, although it'd surprise me if that made a difference, but your mileage may vary. The most important question is whether the form is being submitted with data or not. If there's no data, then it should print those errors (as written at that point in the book).

Cool. Thanks for letting us know!

Awesome, kudos!

Hey Leonardo! Sorry for the confusion! I thought all the files you required are available in the book's downloadable code. Could you confirm what you need specifically?

Yes, sorry, yes, all my apologies. It's been a very tough year professionally and personally. We lost a family member and had another in the hospital for some time. I know not saying anything isn't the right answer (nor is not doing anything), but it's hard/weird to talk about. I'm back in a position where I can be making progress on this again and it's at the forefront of my mind. The second edition of the Yii book, along with keeping up with these forums and many other things, is just not getting done as it should be. Yes, I am most certainly going to finish the second edition. Yes, it's taken offensively too long. I can only offer my sincerest apologies and my aspirations to complete it ASAP. Thank you so much for your miraculous patience and for your willingness to bluntly say "where the hell is the second edition?".

Where is your CSS file located relative to your index.php script?

What's the code you're using?

So sorry AGAIN for the delayed reply! This got lost on my end. It's important to differentiate between "validate" and "sanctify". It's also important to think about how you want to handle invalid data. The most crucial step is to strip out any code, using strip_tags(), before the comments might be displayed on a web page. This will protect you from code injections but doesn't raise errors to the user. Which is fine, depending upon what you want to accomplish. If you do want to validate the data and possibly show the error to the user, then a whitelist approach of what is a valid comment is probably not going to work as there are too many characters that could be valid. I'd go with a blacklist approach instead, knowing that there's not really a good reason for a comment to include , and those are dangerous. Regardless of whether you validate or not, though, you'll still need to strip tags from it and make sure it's safe to use in queries (using an escaping function or prepared statements).

So sorry for the delayed reply! This got lost on my end. I hope you've figured this out by now, but if not... login.js calls login_ajax.php on line 92 of login.js: $.ajax(options); Let me know if anything is still not clear. Apologies again!

So sorry for the delayed reply! This got lost on my end. I hope you've figured this out by now, but if not, if the element is found, it's assigned to the output variable, so you'd look at that to confirm the element was found before attempting to update it. Apologies again!

So sorry for the delayed reply! This got lost on my end. I've not put together a newsletter in years now, and I'm not sure I ever will again. I'm both infinitely behind on many obligations and changing how I spend my time. Thanks for the interest, though! Apologies again!

So sorry for the delayed reply! This got lost on my end. Let me know if you still have questions about this. But the short answer is you only need to upgrade your API version if you need to take advantage of new features. Many users--including me--use very old versions of the API without a problem. Apologies again!

So sorry for the delayed reply. This got lost on my end. I hope you've figured it out by now but if not, let me know, sharing the current version of the code. With what you posted, it looks like your query has a syntax error (missing a space before "LIMIT"). Apologies again!

Unfortunately you'll need to provide more information than that, like the code itself that you're using. Also if there's a URL where we can see this in action, that'd be helpful.

Sorry about the confusion! My expectation is this is due to a change in more recent versions of PHP. In older versions, it would have treated $$total as a "variable variable", but it looks like it's being smarter now. A variable variable would work like this: $cat = 'dog'; $dog = 42; print $$cat; // Prints 42 b/c it takes the value of $cat--"dog"--and inserts that to create "print $dog". Sorry about that!

Unfortunately you omitted the most important details: what operating system are you using and where did you install XAMPP?

This is probably due to the version of MySQL that you're using, as support for multiple timestamps with automatic behavior has changed over time. It's hard to know what the solution is without know the actual error, but using a combination of TIMESTAMP and DATETIME seems perfectly reasonable.

Sorry for the delay, Chris! I'm the only one that regularly moderates the forum and I'm criminally behind in many, many things. Looking now...

Ha! Thanks for letting us know. Yes, that's a mistake that many end up making a couple of times before getting it figured out. In short: happens to the best of us!

Awesome! Glad you've got it now!

I don't think that's a good way to think of it because the $live variable could have a true or false value. More truthfully put, it means "if the opposite of the $live value is TRUE". That is exactly correct. You'd change the second line of config.inc.php (page 60) from false to true. It "knows" because you've manually changed that value. The second line of config.inc.php (page 60). In short, the config file defines the value of LIVE (also, to be clear, it's a constant, not a variable). You set that value, the rest of the site looks at it to know what to do.