Larry

None of the above. As for B, you definitely don't want to create a new database connection with every function call. With C, you don't want to create a second connection script, as the defeats part of the purpose of having globally-useful scripts. With D (the fourth option), $this is only meaningful if you're using OOP. I'm just skimming all this text, but I don't think you're using OOP. There are really two best, easy approaches. One is to make the $dbc variable global within each function as needed, as I do in the book. The other, which I guess is actually better, is to pass the database connection to the function that needs it. Perhaps I've missed something because I'm seeing the answer as very simple and I haven't take the time to read this entire thread in detail. Let me know if that's the case.

It won't work with the IPN script because PayPal has no way to get to http://localhost. Localhost is a domain that, by definition, is only available to the same computer. The only work around I would know of is very complicated, requiring DNS management, router configuration, and more, and may not even be possible depending upon your ISP.

How you design your database depends upon the issue I suggested earlier, which perhaps you didn't follow. I understand what you're saying about the user interface, but you'll need to make a decision about how you store prices: using both currencies or using one base currency and converting on the fly.

Keys, or indexes, improve the performance of queries. I talk about specific recommendations in my PHP & MySQL book and in my newsletter. You can also find out more by searching online or using the MySQL manual. The presence or absence of keys do not prevent you from doing anything.

Sorry for the delay, but HartleySan was helping out and I figured I'd see how things went before I chimed in. Some notes on what you've done... class Players extends Connect { I don't know what the Connect class is, but I suspect it's not appropriate for Players to extend Connect unless Player is a specific type of Connect. Maybe what you're looking for here is an interface, but that may not be right either. public function getAllPlayers() { $mysqli = Connect::MYSQLI(); Two things here: first, you need to think about the design. My inclination would be that you should create one class type Player and then create one instance of that type for each Player. Second, you've got the connection to the database buried in a class, but it'll no doubt depend upon external values (such as the connection parameters), which isn't good. Your getters and setters look fine to me.

Hello John. For me, using XAMPP on Windows 7, C:\xampp\php\php -v works.

Thanks for the very nice words on the book. It is appreciated. I think this is the same issue posted here in the old forum (http://www.larryullman.com/forum/read.php?25,51958), which is to say it looks like a mistake I made in the book. Let me know if that other thread doesn't tell you what you need to make this work.

Thanks for the nice words on the book and thanks to Antonio for helping out.

The difference between your post and mine is that I was not trying to be condescending, I was just thinking aloud (or in type). So whereas I meant no offense, you meant to offend. At best that's just unprofessional and immature. Moreover, that's a curious way to behave when you're asking for free help from strangers.

The alternative, which you'll need to start doing eventually, is loading the first page (the form) through a URL. I don't know how this is done using your particular IDE, but you'll need to start doing that soon anyway. I believe technically HTML element attributes should use double quotation marks.

Well, um, experience, I guess. It also depends upon the versions in use. Are there specific type of gotchas you're thinking of?

My first answer would have been to study more ActionScript, but since you're already comfortable with that, I would look into cookbook/recipe type resources to get a bigger picture of how things are done as well as how specific tasks are best accomplished. You may want to also look into Flex frameworks.

The whole construct %{SOMETHING} is a way of referring to a server variable.

I'll have to double-check my notes, but I believe that's a fine approach. Kudos for figuring it out and thanks for sharing. Another alternative is to enable output buffering on the server, I believe.

You've just posted five separate questions as one thread, which makes answering them impractical. How about creating individual posts for each question, so that people might be able to address them singularly? Also, I see you've taken the time to be the first person to use an image for your signature, but until you start including fundamental details, such as the version of PHP and MySQL in use (per the forum guidelines), I'm going to be disinclined to assist.

Hello Alex, Yes, hopefully someone will have some input on a good payment system in the UK. I can't help on that one. Thanks for the nice words on the books and for your interest in more. The MySQL: Visual QuickStart Guide may be slightly out of date by now, but not that out of date, I don't think. I'm away from my desk, so let me take a look at it again and give you a more precise answer.

Okay, so first, what you've done here in the second example is what I would have recommend. I'm not sure why you were using "example" in your previous attempt. As for this second attempt, when you say it's not working for checkout.php and those, what does happen? What doesn't happen? Do you have checkout.php and the others in the proper location (i.e., you probably need to move them to somewhere else on your server for them to be available via HTTPS)?

Thanks, Alex, for the nice words on the book and for the suggestion. It is appreciated. I am still planning on writing a tutorial for using PayPal WebSite Payments Pro, but I have to finish the book I'm currently working on first, so it'll be at least a couple/few weeks. Jonathon: you're right on the money. Certainly there's a comparable alternative to Authorize.net to use in the UK, no?

Good question. The idea of caching the output of the dynamic menu generation is a very good one. But what you're talking about isn't user specific, so it shouldn't go in a session. The easiest solution would be to have PHP write a text file of the menu's HTML. Then the CMS just includes that text file in the right place. A script on the admin side could update the text file whenever something on the admin side happens that would change the menu's options.

My inclination is to say that if you need the functionality that array_walk() provides, you should use it. If you don't need that functionality, you should not use it.

KEY is jut a synonym for INDEX. So there are general indexes being created there. UNIQUE KEY is just a more specific type of index. PRIMARY KEY is jut a more specific type of UNIQUE index. The syntax for creating any index in MySQL is: INDEX_TYPE name (columns) With the name being optional. The backticks are just the optimal way to reference column names and other database elements (to avoid potential conflicts with MySQL reserved words), although I don't always use them myself.

What does "it doesn't work" mean? What does happen that shouldn't? What doesn't happen that should? What browser(s) have you tried this in? What debugging steps have you taken and what were the results? It's possible/probably the problem is here: var drop = document.form1.drop; as your form is not named "form1".

I expect that you're not running the form.html page through a URL (i.e., http:// something).

That's because you are using MYSQL_NUM in lowercase, which doesn't exist.

Well, the rules are the "Guidelines" linked above, but you did everything fine (thanks for checking). Anymore I just recommend people install XAMPP on Windows. It's the most foolproof solution.