Larry

Thanks to Stuart and Jonathon for helping, as always. Terry, I'm glad you like the book so far. Even though it requires basic knowledge of PHP and MySQL, it was my hope that even seasoned developers would learn a few things from it.

Hello Terry, thanks for the question. In terms of MySQL, NULL values can hurt performance in that MySQL may not be able to take advantage of indexes on fields with lots of NULL values. Setting an empty value (an empty string or 0) may be slightly better than NULL in terms of performance but most likely is not a better idea in general (especially an empty string, as you may end up doing comparison on that field and an empty string does not equal NULL, although they may look the same to the naked eye). To me, NULL values, especially a lot of them, indicate a poor, non-normalized database design. On the book I'm working on, I just designed two databases, with three tables each, and there's not a single column that allows for NULL values. I'm not saying it should never happen, but columns with NULL values shouldn't be common. Again, the rules of normalization tend to lead to more tables with few or no NULL-possible columns. Let me know if it's still not clear.

Hey Jonathon, First, I would say that any time you're messing with rewrite rules, unless you're doing straight-up redirects, I'd recommend using an absolute path to the CSS files and the media. Just more reliable. As for the issues with .htaccess, yes, it's a pain. The complexity of a Web server, a browser's behavior, and regular expressions, all in one! Could you confirm the complete .htaccess rules you've got now, in order, and I'll take a look.

Sure. In looking at the first article, some thoughts... - I disagree with the calling the MVC design pattern a "framework". A design pattern is a standardized way of solving a problem using code. A framework is a set of code for rapid development. - Although frameworks normally use a single entry file, like index.php, there's a strong argument that running all requests through a single point of entry is a poor design choice and should be avoided, if possible. - The inconsistency of the case of variables and classes bothers me. Other than that, I think the article and code is generally okay. There are certainly other ways of doing the same thing but I don't have absolute rules against the way things are done there. I'll look at the other tutorial on another day.

Well, the first thing to keep in mind is that I primarily (i.e., almost exclusively) use a Mac, so I have no sense whether Internet Explorer is any good or not. History would suggest that it's safe to assume it's not! The extensions and add-ons for Firefox are what set it apart, especially for developers. For years I used Firefox first and occasionally Safari. Just recently I made Safari my default browser and Google Chrome, which is growing on me, as my second. I do have Opera installed, but never really got into it too much. With Firefox, the developer tools are great, not to belabor the point. Even the ability to view just part of the source code is really great. I also like the way it manages tabs and saves state. But the memory... Safari seems to perform well. And I really like the ClickToFlash plug-in, which disables Flash content until I click on it to view it. But Flash generally crashes more as a plug-in to Safari. Chrome performs well but I've tried to use its developer plug-ins and have struggled with them. I tell you what I do really appreciate having, especially as I change browsers: 1Password. I'm taking the passwords out of my browsers (which may or may not store them securely) and putting them in 1Password. Plus the 1Password file is sharable across devices, which is useful. I had heard about 1Password for quite some time and never felt the drive to use it, but I'm glad I started to.

You're welcome. I'm not sure I understand what the actual relationship is between MediaArchive (is that a Model, by the way?) and BibleDetails. Also, I suspect your View file should have $model->Bible->someBibleModelProperty.

Thanks, Gregory and Jonathon. Ironically, I've pretty much stopped using Firefox as my day-to-day browser. At first I found it to be too slow, and then I noticed it was a huge memory hog. Right now, Firefox is demanding 165MB of RAM, more than any other application, and I haven't even opened a single page in it yet today. But when it comes to development and tools such as Firebug, no other browser comes close!

Hello Larry, I'm not exactly sure what you're asking about here: using Authorize.net for the first example or PayPal's Website Payment Pro for the second. But in either case, it shouldn't be that hard as the principles are largely the same (the latter change is more directly comparable).

Sorry about that. I've added it to the downloadable code and uploaded the new version to the site. Thanks for the interest in the book!

Thanks for the nice words. First, you do need to have the proper relations identified in the Model. But then, it's just a matter of referring to $model->relation_name->property, which is probably $model->department->name in this case (this reference is in the View).

That error message doesn't occur where you think it does, but rather later on in the script if the query doesn't return any records. You'll need to apply the basic debugging steps to figure out why. Also, before you post again, make sure you read the forum guidelines and include pertinent details, such as the versions in use.

Yes, exactly. Although...you can't have a variable named $2week and that would come from the database and it'd be a number, so you shouldn't use quotes around it. You can simplify this code in a couple of ways, too. I'd be inclined to have one conditional that confirms payment status, receiver email, mc currency, and txn ID. Then another conditional determines the expiration increase based upon the value of mc gross and the two week subscription. But that's all minor stuff. It looks like you've got the premise down.

As I say in a tip, I've not found a third-party plug-ins to be nearly as good as the commercial ones. I've never personally tried to develop one either. If I'm going to work on a site that needs that feature, I just roll the $70 or whatever into the price of the project. But that's just me. Perhaps by looking at some of the third-party plug-ins you could get a sense of how they work.

Thanks for the nice words and I hope you like the other book. Let us know if you have any questions or problems.

Hello Sam, Thanks for the nice words. Me teaching you PHP is probably a lot easier than you teaching me to be a vet! Okay, and I'm just free thinking here, you could add a two_week column to the table. A user registers and the expiration is set to yesterday and the two_week is 0. The user goes through PayPal. The first time the IPN sends back a 0 amount, if two_week is still 0, meaning they haven't done a two-week subscription yet, you set the expiration to 2 weeks from now and update the two_week to 1. When future IPNs come in, with appropriate amounts, you add a month to the expiration. If another 0 amount comes through for that same user, they don't get credited another two weeks because they already had that. Does that sound like what you want to do?

Before I answer the question, just out of curiosity, what's the benefit of having one button that just toggles another button (as opposed to having the first button toggle itself)?

Sorry, Jorge, that I didn't get you an answer. There was a ton of code to review, so I put it on my watch list to get back to it and...apparently I never did. Sorry about that. Kudos for figuring it out and thanks for posting the solution.

Thanks for your question, Terry. I don't really do anything with Windows at all, let alone development for Windows. In fact, even things that I think are decent, like ASP.net, which extend to a broader audience, are pretty much useless to me because it requires Windows for development and hosting. So, all in all, not my cup of tea. But thanks for thinking of me!

Live and learn, eh? Not so sure about 5.3.6 and a built-in Web server. The idea itself kind of surprised me when you mentioned it, and in doing research, there's nothing about that in the release notes for PHP 5.3.6, and the only place I find any mention of the idea is in association with a guy that I consider to be a crackpot. So...

Hey Terry, I posted this on my blog and in the newsletter and on Amazon as it's complicated and a bit embarrassing. PHP 6 never existed, officially. When I wrote the book, PHP 6 was about halfway done, so I used the beta version of PHP 6 in writing the book. The main feature of PHP 6 that I wanted to highlight was support for Unicode, which is pretty important in a global sense. But since the book was written, changes took place and it turned out that it got to be very complicated to continue PHP 6 as they were planning. So PHP 6 was shelved. Some of its features made their way into PHP 5.3, including most of the PHP 6 stuff that I discussed in the book (which is only about 5% of the book's material). I don't even know if there's a plan for PHP 6 now. Ironically, I tried to incorporate PHP 6 discussion into the book so that the book wouldn't be outdated too quickly after being published. Instead, three years later (I think), the book is still too far ahead! And, doubly ironically, the PHP 6 stuff was really hard to write as there was barely any decent documentation on it. Often I had to look into PHP's core code to figure out what functions existed and how they were used. As I said, I'm a little embarrassed about that, but I've learned a valuable lesson: not to go too far out on a limb! So the short answer of "Why learn PHP 6?" isn't you shouldn't because it doesn't exist!

Thanks, Terry, for the interest in the books!

It's really not prudent to use the IPN without SSL: too much data is being transmitted in the open if you do that. If you're doing e-commerce, I think you just need to accept the additional cost of having SSL. Besides, you might want SSL for your admin pages or elsewhere. It's only a couple of hundred dollars and the lack of SSL will cost you more in the long run (due to lost sales and the inevitable security violation).

You'll have to import the data using a command line tool, such as the mysql client with batch mode or mysqlimport.

First, thanks for the interest in the book! The book uses the basic version of PayPal for one example and then Authorize.net for the other. The Authorize.net system is equivalent to PayPal Pro. So, in short you get to see both approaches. As far as I know, this isn't an issue with what's in the book, but I always add additional issues and thoughts on my Web site in support of the book. No, the PayPal example in the book is a fixed-price item. But, yes, you don't want to pass the price to PayPal. I think it's well more than 2 pages. From some of the debugging help I've provided in the forums, it seems that I could have gone through that section in greater detail, but everything is explained well, I believe. You can also go without the htaccess stuff, too. No, you should be just fine. You're quite welcome. Thanks again for the interest! I have not and I have not heard this from my host, but a lot of factors go into performance issues.

Thanks for your input, Josee. Yes, I've heard complaints about the Adobe Digital Editions before. It wasn't something I was familiar with. I've requested that Peachpit remove all DRM from all of my books, too. What you say about PDFs makes sense. One great thing about doing this myself is I should be able to output the content in any format I want. I'll need to create a PDF for the print version of the book, but there's no reason I can't output a different kind of PDF for the screen. I'll just need to figure out what that means...