My “Effortless E-Commerce with PHP and MySQL” book is going to the printer on Tuesday (I believe). Barring any last minute changes, below you will find the complete table of contents. Those that have being paying attention to this book throughout the writing process may notice that Part Four: Extras has up and gone. This is entirely in part because I ran out of pages (I’m only allotted so many) and in part because many of the topics I was going to discuss separately in Part Four got moved into the other chapters. Five of the eleven chapters end with 3-7 pages of additional ideas, note, PHP code, MySQL tables, and so forth. I may develop some of these ideas further in this blog (both examples are very modular and extend-able). Edit: Unfortunately, due to page constraints, all of the bonus material had to be pulled from the chapters. I’ll make it all, plus some extra extras, available online. My apologies (but it’s completely out of my hands).

I’m very pleased to say that I’m in the process of wrapping up my next book, “Effortless E-Commerce with PHP and MySQL”. I’ve  completed the writing of all eleven chapters. Now I’m in the process of reviewing the PDF layouts of the chapters, which I’ll finish over the weekend (the book goes to the printer on Tuesday). Overall I think the book turned out quite well, although you’d expect me to say that! Unfortunately I did have to cut a couple of “bonus” chapters out, as I ran out of pages (the publisher institutes a hard limit on a book’s length), but I should be able to explain most of the bonus materials in blog postings here. I’ll post the final table of contents separately, and I still need to put the code for the second example online (actually, I need to create the official Web site for the book, too), but I wanted to quickly mention some of the book’s highlights, in no particular order:

If you’re like me and, well, most people, you probably aren’t using Linux on your personal computer. Yes, many technical people are using Linux and love it, but the fact of the matter is that the market for Linux as a desktop system still isn’t that big (and that’s not a reflection of how great Linux is, because it’s pretty great). But if you do a lot of Web development, like I do, you probably interact with Linux servers all the time. If you work with a Linux system from a command-line interface (or any Unix system, really), you may not have the vaguest idea what the /etc directory is, or /dev. For that matter, the difference between /bin and /sbin or /usr/bin may be lost on you. I recently StumbledUpon this article that explains the Linux file system. It’s a short and simple, yet excellent, discussion of the topic.

In my forthcoming “Effortless E-Commerce with PHP and MySQL” book (which is pretty much my only focus these days), I wanted to use two different payment systems. This was part of my overall approach of trying to present as big of a picture as possible as to what “e-commerce” is. For the book’s first example, I wanted to use PayPal. Many developers don’t like PayPal, but for customers, it’s the most recognizable name, and that’s critical when it comes to customers being comfortable spending money at a site. People traditionally think of PayPal’s as a system where the customer leaves the e-commerce site, goes to PayPal’s site, and hopefully returns to the original e-commerce site after making the purchase. This is formally called PayPal’s Website Payments Standard, and is demonstrated in my book. In that example, I make use of PayPal’s IPN (Instant Payment Notification) system, so that the site is notified as soon as the payment is made, whether or not the customer actually returns to the e-commerce site immediately thereafter. Tapping into IPN makes the use of PayPal more professional and reliable for the site itself.

For the second example in the site, I wanted to use a true payment gateway: a system that can be integrated into a site so that the customer never leaves. A secondary, but big, benefit of a payment gateway is that the funds get transferred to the site’s merchant bank account, instead of to a PayPal account. (To be clear, PayPal’s Website Payments Pro works as a payment gateway that can be integrated into a site, but I believe the funds still go into one’s PayPal account.) I’ve used several different gateways over the years, but rarely made the selection myself (normally it’s the client making the choice, based upon their merchant bank account). So I spent some time researching payment gateways to find the one that would be best for the book. Many readers also provided their recommendations (thanks!). Here’s how that search went for me…

I primarily use a Mac for everything I do (and by “primarily” I mean just about 99.9% of the time), and have for years. I’m not trying to start an argument over the best computer, I’m just saying I like the Mac. One of the main reasons I prefer Macs is that it’s Unix (based on Free BSD, since the creation of Mac OS X) without being too Unix-y. For many people I know and work with—great with computers but not a geek, it’s easy to appreciate the nice interface and reliability and features and so forth, without an awareness of the underlying Unix stuff. For me, who regularly works with Web servers, I can do anything on my personal computer just the same as I can on a Web server. When I develop projects on my computer, transferring them to a Web server is completely smooth process. But why is this post about MAMP Pro?

I haven’t been posting much the past couple of weeks because I’ve been working night and day on my “Effortless E-Commerce with PHP and MySQL” book. The deadline for me to turn it all in was August 31st, but I’ve got just a little bit of leeway. I should be wrapping the first draft within the next few days and I’m about halfway through the second draft. To explain…

Basically I write a chapter at a time in Word, passing each along to the editor. The chapters go through a line editor (who looks at word choice, clarity, and style) and a tech editor (who looks at the code and such), then come back to me. At that point I do what’s called an author rewrite (AR), addressing the issues raised by the editors and correcting any thing that I later realized would be a problem (especially on a book like this, where chapters build on each other, it’s common to find when writing Ch 7 that something needs to be said or done in Ch 6). After the AR, the chapter gets turned into a PDF, laid out as it will be in the printed book.