Larry

Yes, you would definitely learn more by coding from scratch. Also, the thing with frameworks, is that they make 80% of the work much, much, much easier and the last 20% much, much harder, so it's not a clear net gain sometimes.

No, I didn't demonstrate pagination in the book, in part because there's only so much space available and in part because pagination is a fairly rudimentary concept to implement. To apply pagination... - You'd need to create a stored procedure that returns the number of products in that category. - From that stored procedure, you'd be able to calculate how many pages are required. - The stored procedure for fetching products would need to be changed to take two more arguments: the number of records to fetch and where to start in the result set. - The PHP script would need to determine and pass those two arguments to the stored procedure. - You'd need to create pagination links to subsequent and previous pages that pass the total number of pages involved and where to begin that page's result set. That's the basic idea. Most of this is covered in detail in my PHP & MySQL book, aside from the stored procedure stuff (that book's example uses straight queries for all this). If you have any questions or problems implementing this, let me know. I could write up a blog posting about it, if you'd like (it just may take a while).

Well, I pay $50/month, and am extremely pleased with what I'm getting. The key here is that what works for one person may not be appropriate for another. When I see $62/year and "Once in a while the server goes down for a couple hours", I think "cheap hosting" and not "cheap" as in inexpensive, but as in poor. For your personal project, your hosting is fine (and again, if you're pleased with what you've got, that's great; I'm not trying to talk you out of it). But for me, that wouldn't cut it. What I want in a Web host is uptime, support, performance, and security. As for uptime, by comparison, my hosting company just let me know they'd be doing some maintenance and the server may be unavailable for up to 15 minutes. This was the first time in 6 months that downtime might have been expected and I'm not sure it ended up being 15 minutes after all. As for support, I can get any question answered within 15-30 minutes, normally, and any problem solved within 1-2 hours. Some people may not have or see the need for such support, but my Web site is the face of my business. And since I'm generally in the business of Web development, having a site be unavailable is a bad thing. And, naturally, the busier a site is, the more important good hosting is and the more damaging outages are. Secondarily, I've saved money on hosting before, and the result was that I spent a lot of time fixing problems or watching over the server and so forth. What I'm buying for $50/month is peace of mind. And, actually, when I think about how much money I make per hour, spending time on the hosting so that I'm saving a few bucks a month is a poor economic choice. When it comes to choosing a host, I think everyone can completely ignore all specs about disk space, bandwidth, etc. All hosting plans will give you more than you ever need, and are often trying to amaze you with these numbers. It's like buying a car because the speedometer goes to 170, when you'll never drive it about 80 anyway. But as with everything, you get what you pay for. Let's say the cost of physically buying a server, putting it online, and maintaining it (i.e., what the hosting company covers, plus a profit) costs X. And let's say X is $500/month, for the sake of argument. If I'm paying $50/month, then there are probably X/50 clients on the server, or 10. If you're paying $5/month, then there are X/5 or 100 clients on that server. That means 10 times the people/sites using the same resources, the same bandwidth, and so forth. That's got to have an effect on performance. More importantly, that means 100 clients whose code could be introducing security holes that undermine the security of your site. To me, that's a big deal. Again, I'm not saying you should change your hosting or that cheap hosting is always inappropriate, but I wouldn't be dismissive of paying more. You suggest that the average person doesn't know any better and is getting ripped off. I would argue that such people actually do know better than to just take the cheapest hosting they can find. Because I like analogies, let's return to the car idea. You could buy a really cheap, used car that would get you from point A to point B and that is appropriate for person X's needs and fits his or her budget. Or you could buy a brand new Mercedes, that also gets you from point A to point B, and that may be appropriate for person Y's needs and fits her or his budget. But it'd be pretty asinine for person X to think person Y is getting ripped off for spending so much money just as it'd be ridiculous for person Y to think person X and everyone else ought to buy a new Mercedes.

Well, it's doing what you've told it to do. I'd recommend you go back a few steps and learn a little more about jQuery and JavaScript before moving on. You're missing some basic things. For starters, you incorporate the jQuery library but aren't using it. Then, you've got an anonymous function being called when the link is clicked, which is good, but all your anonymous function does is return false, thereby preventing anything from happening within the browser. And that's fine, but you've not added any functionality behind the scenes (i.e., the Ajax). So you're many steps from being close to this one.

I prefer not to do this, generally, but it's hard debugging this script because the problem (apparently the form isn't being submitted) is unusual, but how about you email me the current version of user.php (right?) and I'll take a look.

Hello Tony, Thanks for the nice words on the book and for your interest in my other books. This is a good question. Besides what Antonio and Jonathon have added (thanks!), in my PHP & MySQL book, I have a "spam scrubber" function that can catch potential spamming hooks found in the entire form data submission. I also, if using a version of PHP that supports it, recommend using the Filter extension of PHP to validate email addresses.

I'm not even clear about what the two programs are! So...no.

I'm not sure this is causing the problem, but I just noticed your form is missing the closing HTML form tag. Doing a W3C validation on the HTML (of the page with the form) might be a good debugging step, too.

Antonio, big thanks for your help. Just to clear something up, though, PHP does not have block level scope, which is to say that the while loop and such does not create an area of variable scope. The reason that $row has no value after the while loop is that the loop will attempt to fetch records into $row until it can't. At that point the loop is exited, but $row now has no value because it was just assigned no value (thereby breaking the condition of the loop). But thanks again for helping out!

The contents of the html directory would go in XAMPP's htdocs directory. The stuff outside of the html directory would go outside of the htdocs directory.

I would create a "product" page that lists a single product. That page should be passed the SKU. Then you change the link so it goes to the product page.

I think that's a better approach and the PHP side is simple. Start by creating a category variable, outside of the while loop: $category = NULL; Then you've got the while loop: while ($row = mysqli_fetch_array(MYSQLI_ASSOC)) { } Within the while loop, you compare the just-fetched record's category with the $category variable. If they are the same, you just need to print the record. If the fetched category is different, then do whatever (like display the category name) and assign the fetched category value to $category. And that's it!

There's no difference between exit and exit(), but exit is a language construct, not a function (I believe), which means the parentheses are not required. So, since they aren't required, I tend not to use them. The exception would be when providing a terminating message with exit, in which case you must use the parentheses.

Yeah, my inclination is that a recursive function isn't necessary either, just a good SQL command or two. Another question I would have is what is the desired output? Like viewing everything at once or just one node or...?

As for the error messages, the complete error messages would be best to see. When you say you "nothing came out" of adding the echo statements, what does that mean? You didn't see any of the echo statements being executed?

For an INSERT query, that should be mysqli_affected_rows(). Do I have that wrong on my post?

And what debugging steps have you taken and what were the results?

That means you have the same function defined twice in the functions.php script.

Right. The SQL commands are in the MySQL_VQS_2.sql file, found in the downloaded files.

Why do you think there's supposed to be more? Can you provide an example of something you think is missing?

I'm not sure I'm following you on this one. The code at the bottom of page 432 is what I put in a file named args.php, so that I could execute it to show the results in Figure 11.21. It's just a dummy script that merely reports back the arguments provided when it's called. The second argument is the name of the file to be numbered, as in the explanation under Step 3. No, the purpose of the script is to add line numbers automatically to another script. So the first argument received will be the name of the script being executed, which is always number2.php. The second argument should be the name of the other file: the one the user wants numbered. This argument would change with multiple uses of number2.php. That's just a file I chose to number. As I say on page 432, and clarify above, that's a bit of sample code. You can number any text file you want. Again, if you see Step 10, it says to run the script using php number2.php filename , replacing "filename" with the actual file you want numbered. For me that was "args.php", but for you it can be any plain text file you have. The first argument will be number2.php. The second argument will be args.php or whatever filename you provide. Right, yes. There's only one argument actually being provided by the user, but the PHP script always receives the name of the script being executed through the command line as its first argument. So every call to a command line PHP script will always have at least one argument. You're welcome. Sorry for the confusion and let me know if anything is still not clear.

Interesting question, Ahab. Let me ponder your white whale a bit and see what I come up with. Just out of curiosity, is this something you need to do or are just wanting to see if you can figure out?

That makes sense. Kudos for figuring it out and thanks for letting us know.

Please do, Greg. Thanks!

Great. Thanks for letting me know!