Larry

HartleySan, that string is part of how one does prepared statements. Awkuzu, what is your pass column defined as? Also, do you have a user_level column in your table? You don't mention it in the INSERT query.

There's not really enough here for me to help debug.

Yes, exactly. No, it's an either/or. If the folder isn't in the Web directory, then there's no need to use an .htaccess file on that directory (because it's not Web accessible). "Plenty secure" depends upon the site in question. 755 means that only the owner can write to the directory. That's the fundamental thing about security: if you need that level. There's no right answer, there's only more secure and less secure. A proxy script can do more than what you think, though. You could use a proxy script to limit access to only registered users or to count how many times a resource has been requested. It's not a matter of "necessary", it's a matter of "warranted" or "appropriate". Yes. You should never make the primary key value (from a database table) publicly available. Definitely not secure. To improve upon your metaphor (and I like a good metaphor), the real suggestion is that everyone knows everyone else's social security number, which would be bad. Excellent. Nice to "meet" you.

Excellent. Glad to hear you figured it out and thanks for sharing that. What made you say that my script was using a .HTML format?

To exit what program? Because I don't think quit() exists as a function in PHP. Yeah...no. To move up a folder, I use ../ ./ moves into a folder, starting from the current directory. These are not equivalent. If you can provide specific pages where you're seeing these things and are confused, I can help explain what's going on.

If you search Google for "install mcrypt mac", the very first hit explains how to do this. It is a bit technical, though.

Kudos for figuring it out and thanks for sharing your solution!

Sure, of course you can.

Yeah, apparently I didn't make it clear enough in that edition that you can load the page (which is what I mean by "testing it") but you can't click the links. I've made it more clear in the 4th edition.

Yes, exactly. The MySQL client can be used, as in the book.

Okay, even if XAMPP comes with JSON installed, and I'm not sure what that means in this case, you still need a parseJSON library installed. And your script needs to include the parseJSON JavaScript library and then call the proper method of the proper class. Don't get distracted by the header(). Right now, if you want to use parseJSON(), you need to focus on choosing, installing, and using a proper parseJSON library.

Sorry for the confusion. You cannot perform transactions using phpMyAdmin because each submission of a query is in itself a complete transaction (as with any Web page, there's no persistent connection and transaction from one loading of a page to another). I've added text to the fourth edition of the book, which I'm writing now, to make this more clear.

Your first INSERT query names 13 columns but only has 12 question marks (placeholders). You then bind 12 variables. I expect you need to drop the booking_id from the list of columns being populated.

Thanks for the compliments. I gather not many writers provide the level of support I do, but I find I learn a lot by doing so.

Is there a line number associated with the error?

To be clear, it's not a full MVC approach, it's a partial one. The PHP scripts are the controllers, the HTML scripts are the Views, and the stored procedures are, in theory, the Models. The stored procedures as Models is actually the point where it doesn't really adhere to tight MVC patterns. If you were to do an OOP implementation of MVC, you'd write the Models and Controllers as classes, separate classes. An instance of the Controller class would create an instance of the Model class as needed.

The code from W3Schools, missing on ActiveXObject is obviously less accommodating, but that one use may be outdated by this point. And thanks for all your help in answering other people's questions. I really appreciate it.

Um, be extra careful about validating the uploaded files to make sure they're of acceptable types. A proxy script, and blocking direct access to the subdirectories (using .htaccess or the like) would be even more secure. I normally try to put all writable folders outside of the Web directory. The problem is if you ever need to change that index.php page. If so, you'd need to do so for all X users. It'd be better to use top level scripts. I would think by the folder name, which the index file passes to the root level scripts that do the actual action. You want to avoid as much work up front as possible, and as many later edits as possible. I'm not sure how to answer this one. I suspect it does't matter so long as you have checks that would delete the directory should the database insertion fail and vice versa. No problem. That's what the forum is for!

You could just start by installing Yii on your own computer and developing there. That way you can see if you like it without affecting your hosted site.

Have you included a parseJSON() library? If so, which one? Have you checked the error console for error messages?

Thanks for letting us know, but this isn't actually a fix. What if there's a single quote in a value? Then you'd have the same problem. And technically, I believe HTML attributes are supposed to use double quotation marks. A better, reliable solution would be to apply htmlentities() to the data before you print it.

Hey Jonathon, Well, you could have installed Yii yourself, but perhaps they maintain the framework version if they do it. As for the caching tools, support for those is preferred in order to offset the performance hit required by the framework, but that is only an issue if your site is really active.

What version of MySQL are you using and on what operating system?

Thanks for the nice words, Ron. Much appreciated. As for your question, just replicate the page title code, using a different constant name. So maybe create a PAGE_DESCRIPTION constant and, in the header, have PHP print out the PAGE_DESCRIPTION constant within the appropriate meta tag, assuming the constant is defined.

It's not a big deal to convert to the older MySQL functions, you'll just need to do it. If you're in a situation where you don't need dedicated (or, really, that good) hosting, then I wouldn't worry about the performance issues. Yes, the MySQL Improved functions should perform better and support other features, but it doesn't sound like you're in a situation where you need to spend money to make that happen.