I’m currently going through some items in my “to read” folder, and am reading, or perhaps re-reading, the Better Business Bureau’s PDF titled “Security & Privacy – Made Simpler“. If you do any e-commerce, or even just Web development, it’s worth reading. It’s a 22-page document that discusses almost every facet of e-commerce, such as:

• Developing a security and privacy plan
• Creating and communicating your security and privacy policies
• Good employee screening and policies
• Common hack/theft strategies
• General Internet security
• Proper handling of customer data
• Payment processing
• What to do in the event of a data breach
• A preview of international e-commerce considerations

The document also has many resources listed in these and other categories. You can download the PDF from that page, but there are also related FAQs and more on the BBB’s site.

The first procedure in Chapter 10 is add_customer(), called in the checkout.php script, after the customer has successfully completed the shipping form. The code in the PHP script calls the procedure, which will add a record to the customers table. The procedure also returns the customer ID via an outbound argument named @cid. This value needs to be stored in the session for later use. Here is the original code:

$r = mysqli_query($dbc, "CALL add_customer('$e', '$fn', '$ln', '$a1', '$a2', '$c', '$s', $z, $p, @cid)");

// Confirm that it worked:
if ($r) {

// Retrieve the customer ID:
$r = mysqli_query($dbc, 'SELECT @cid');
if (mysqli_num_rows($r) == 1) {

    list($_SESSION['customer_id']) = mysqli_fetch_array($r);

Without a stored procedure, you would replace that code with:

$r = mysqli_query($dbc, "INSERT INTO customers VALUES (NULL, '$e', '$fn', '$ln', '$a1', '$a2', '$c', '$s', $z, $p, NOW())");

// Confirm that it worked:
if (mysqli_num_rows($r) == 1) {

    // Retrieve the customer ID:
    $_SESSION['customer_id'] = mysqli_insert_id($r);

There is one caveat, however: the variables aren’t safe to use in the query as they haven’t been sanctified (they’ve been validated, though). So I would run all the strings through an escaping function, such as mysqli_real_escape_string() first. You could do so when assigning values to the variables earlier in the script. You’ll also need to remove one closing curly bracket from the original PHP script, as this structure has one fewer conditionals.

Next, the customer is taken to billing.php, where they’re presented with a form for entering their billing information. The form data is then validated and the add_order() procedure is called. This procedure has the most logic, as it needs to:

• Add a record to the orders table.
• Get the new order ID value
• Add one record to the order_contents table for each item in the order
• Calculate the subtotal of the order
• Calculate the total of the order (which includes the shipping)
• Add the total of the order to the orders table
• Return both the order total and the order ID

The original stored procedure does all this using two INSERT queries, three SELECT queries, and one UPDATE. (This is an excellent example of the benefit of stored procedures, as the PHP script only needs to execute two queries to do all of the above.)

The billing.php script has the following code:

$r = mysqli_query($dbc, "CALL add_order({$_SESSION['customer_id']}, '$uid', {$_SESSION['shipping']}, $cc_last_four, @total, @oid)");

// Confirm that it worked:
if ($r) {

    // Retrieve the order ID and total:
    $r = mysqli_query($dbc, 'SELECT @total, @oid');
    if (mysqli_num_rows($r) == 1) {
        list($order_total, $order_id) = mysqli_fetch_array($r);

        // Store the information in the session:
        $_SESSION['order_total'] = $order_total;
        $_SESSION['order_id'] = $order_id;

You’d need to replace that code with all of the following:

$r = mysqli_query($dbc, "INSERT INTO orders (customer_id, shipping, credit_card_number, order_date) VALUES
({$_SESSION['customer_id']}, {$_SESSION['shipping']}, $cc_last_four, NOW())");

if (mysqli_num_rows($r) == 1) {

    // Get the order ID:
    $_SESSION['order_id'] = mysqli_insert_id($r);

    // Add the items to the order_contents table:
    $r = mysqli_query($dbc, "INSERT INTO order_contents (order_id, product_type, product_id, quantity, price_per)
SELECT {$_SESSION['order_id']}, c.product_type, c.product_id, c.quantity, IFNULL(sales.price, ncp.price) FROM carts AS c
INNER JOIN non_coffee_products AS ncp ON c.product_id=ncp.id
LEFT OUTER JOIN sales ON (sales.product_id=ncp.id AND sales.product_type='other' AND ((NOW() BETWEEN sales.start_date AND sales.end_date) OR (NOW() > sales.start_date AND sales.end_date IS NULL)) )
WHERE c.product_type="other" AND c.user_session_id='$uid'
UNION
SELECT {$_SESSION['order_id']}, c.product_type, c.product_id, c.quantity, IFNULL(sales.price, sc.price) FROM carts AS c
INNER JOIN specific_coffees AS sc ON c.product_id=sc.id
LEFT OUTER JOIN sales ON (sales.product_id=sc.id AND sales.product_type='coffee' AND ((NOW() BETWEEN sales.start_date AND sales.end_date) OR (NOW() > sales.start_date AND sales.end_date IS NULL)) )
WHERE c.product_type="coffee" AND c.user_session_id='$uid'");

    if (mysqli_affected_rows($r) > 0) {

        // Calculate and fetch the subtotal:
        $r = mysqli_query($dbc, "SELECT SUM(quantity*price_per) FROM order_contents WHERE order_id={$_SESSION['order_id]}");
        list($subtotal) = mysqli_fetch_array($r, MYSQLI_NUM);

       // Calculate, update, and store the order total:
       $r = mysqli_query($dbc, "UPDATE orders SET total = ($subtotal + {$_SESSION['shipping']}) WHERE id={$_SESSION['order_id]}");
       $_SESSION['order_total'] = $subtotal + $_SESSION['shipping'];

So there’s all the stored procedure logic in PHP. For an explanation of the queries, see the book. To use this in a script, you’ll need to complete all the conditionals as appropriate.

Later, the billing.php script calls the add_transaction() procedure, after processing the payment:

$r = mysqli_query($dbc, "CALL add_transaction($order_id, '{$data['x_type']}', $response_array[9], $response_array[0], '$reason', $response_array[6], '$response')");

That one line simply gets replaced with:

$r = mysqli_query($dbc, "INSERT INTO transactions VALUES (NULL, {$_SESSION['order_id'], {$data['x_type']}, $response_array[9], $response_array[0], '$reason', $response_array[6], '$response', NOW())");

This takes us to final.php, where the clear_cart() procedure is called:

$r = mysqli_query($dbc, "CALL clear_cart('$uid')");

Replace that line with:

$r = mysqli_query($dbc, "DELETE FROM carts WHERE user_session_id='$uid'");

And that’s it for final.php.

Now three scripts in Chapter 10—checkout.php, billing.php, and email_receipt.php—also invoke the get_order_contents() procedure. I explain how to replace it with standard PHP-MySQL in the second post in this series.

That’s it for converting all of the stored procedures in the book with standard PHP and MySQL. As you can see, it’s generally not that hard, depending upon how complex the stored procedure itself is.

Let me know if you have any questions and thanks for your interest in the book!

There are four stored procedures for each of these two tables. Each procedure corresponds to basic CRUD functionality: Create (i.e., INSERT), Retrieve (SELECT), Update, and Delete. In Chapter 9, all eight procedures are invoked from either cart.php or wishlist.php (Chapter 10, “Checking Out,” also has some scripts that will use them). Both scripts use a long-ish if-elseif conditional that checks for values in the URL to know when to perform INSERT and DELETE procedures. Such conditionals will be true when the user, for example, clicks an “Add to Cart” link on a product listing page or clicks a “Remove from Cart” link on the shopping cart page. UPDATE procedures are run when the shopping cart (or wish list) form is POSTed back to the page, presumably with new quantities provided for the items in the cart (or wish list).

A Product Listing in the Catalog

The Shopping Cart Form

Both PHP scripts, after whatever other stored procedures may or may not be called, execute the SELECT procedure. Let’s look at that first. (To make this post shorter, I’m only going to talk about changes required to the cart.php script from here on out; changes required for wishlist.php would be almost exactly the same.)

Near the very end of cart.php, the SELECT stored procedure is executed using this code:

$r = mysqli_query($dbc, "CALL get_shopping_cart_contents('$uid')");

Earlier in the script, the $uid variable is created, which is a unique reference to the current user. You can think of it like a session ID, although it’s not actually used by PHP sessions. To replace the stored procedure, you would just change the above line to be:

$r = mysqli_query($dbc, "SELECT CONCAT("O", ncp.id) AS sku, c.quantity, ncc.category, ncp.name, ncp.price, ncp.stock, sales.price AS sale_price
FROM carts AS c INNER JOIN non_coffee_products AS ncp ON c.product_id=ncp.id
INNER JOIN non_coffee_categories AS ncc ON ncc.id=ncp.non_coffee_category_id
LEFT OUTER JOIN sales ON (sales.product_id=ncp.id AND sales.product_type='other'
AND ((NOW() BETWEEN sales.start_date AND sales.end_date) OR (NOW() > sales.start_date AND sales.end_date IS NULL)) )
WHERE c.product_type="other" AND c.user_session_id='$uid'
UNION SELECT CONCAT("C", sc.id), c.quantity, gc.category, CONCAT_WS(" - ", s.size, sc.caf_decaf, sc.ground_whole), sc.price, sc.stock, sales.price
FROM carts AS c INNER JOIN specific_coffees AS sc ON c.product_id=sc.id INNER JOIN sizes AS s ON s.id=sc.size_id
INNER JOIN general_coffees AS gc ON gc.id=sc.general_coffee_id LEFT OUTER JOIN sales ON (sales.product_id=sc.id
AND sales.product_type='coffee' AND ((NOW() BETWEEN sales.start_date AND sales.end_date) OR (NOW() > sales.start_date AND sales.end_date IS NULL)) )
WHERE c.product_type="coffee" AND c.user_session_id='$uid'");

In short, all you need to do is take the big query from the stored procedure and execute it directly. Two uses of “uid” in the stored procedure, representing the internal stored procedure variable, need to be replaced with the PHP variable $uid, and wrapped in quotes (the variable within the stored procedure does not use a dollar sign, as it’s not a PHP variable, and doesn’t need to be wrapped in quotes as queries executed within stored procedures work like prepared statements).

Moving on, the cart.php script invokes the remove_from_cart() stored procedure once:

$r = mysqli_query($dbc, "CALL remove_from_cart('$uid', '$sp_type', $pid)");

Replace that with:

$r = mysqli_query($dbc, "DELETE FROM carts WHERE user_session_id='$uid' AND product_type='$sp_type' AND product_id=$pid");

Again, this is just executing the query directly, after replacing the stored procedure variables in the query with PHP variables. Note that all of these variables have already been validated prior to this point. The cart.php script also invokes remove_from_wish_list() once, which will also need to be replaced with the appropriate query.

The UPDATE stored procedure is called in cart.php, upon the form submission. In a foreach loop, you’ll find this code:

$r = mysqli_query($dbc, "CALL update_cart('$uid', '$sp_type', $pid, $qty)");

Unlike the other procedures I’ve written about thus far, the update_cart() stored procedure has a bit of logic to it. Namely, it will update the quantity in the cart if the new quantity is greater than 0 or execute the remove_from_cart() procedure if the quantity equals 0. So that logic must be present in the PHP code that replaces the above line:

if ($qty > 0) {
    $r = mysqli_query($dbc, "UPDATE carts SET quantity=$qty, date_modified=NOW() WHERE user_session_id='$uid' AND product_type='$sp_type' AND product_id=$pid");
} elseif ($qty == 0) {
    $r = mysqli_query($dbc, "DELETE FROM carts WHERE user_session_id='$uid' AND product_type='$sp_type' AND product_id=$pid");
}

Arguably, I’d be inclined to use prepared statements there instead (whenever you have a query being executed within a loop, it’s a good candidate for prepared statements), but I don’t want to over-complicate the changes I’m already suggesting.

This leaves us with the last stored procedure, add_to_cart(). You might think this would be a simple INSERT query, but there’s some logic required by it. This procedure will be called when the customer clicks a link. In that case, a simple INSERT is all that’s necessary. However, if the user clicks the same link again later—thereby adding to the cart something already in the cart, another INSERT should not be executed. The decision I made in the book is to assume that the customer purposefully wanted to add another quantity of the same item to the cart in such instances. So the stored procedure runs an UPDATE query when the item exists in the cart.

The first time the add_to_cart() procedure is executed in cart.php looks like this:

$r = mysqli_query($dbc, "CALL add_to_cart('$uid', '$sp_type', $pid, 1)");

The final 1 indicates that one quantity of the item is being added, which is the default behavior when an “Add to Cart” link is clicked. You would replace that code with:

$r = mysqli_query($dbc, "SELECT id FROM carts where user_session_id='$uid' AND product_type='$sp_type' AND product_id=$pid");
if (mysqli_num_rows($r) == 1) { // Exists in cart, UPDATE!
    list($cid) = mysqli_fetch_array($r, MYSQLI_NUM);
    $r = mysqli_query($dbc, "UPDATE carts SET quantity=quantity+1, date_modified=NOW() WHERE id=$cid");
} else { // Not in cart, INSERT!
    $r = mysqli_query($dbc, "INSERT INTO carts (user_session_id, product_type, product_id, quantity) VALUES ('$uid', '$sp_type', $pid, 1)");
}

The first query is basically asking if the user already has this item in their cart. If so, the cart’s id value is selected and assigned to a MySQL variable, @cid. The conditional then checks if one row was returned. If so, an UPDATE query is run, using the just-created MySQL variable in the WHERE clause (if my use of @cid is confusing, I can add explanations of its purpose and usage). If one row wasn’t returned, an INSERT query is executed.

Now the cart.php script also calls the add_to_cart() stored procedure in another instance: If the customer has something in their wish list and they click the “Move to Cart” link, the item gets added to the cart and removed from the wish list. The use of add_to_cart() is exactly the same, except that whatever quantity of the item is in the user’s wish list needs to be transferred, too. In that case, the $qty variable represents that value. So you’d also replace this line:

$r = mysqli_query($dbc, "CALL add_to_cart('$uid', '$sp_type', $pid, $qty)");

With the code above, except you’d use $qty instead of 1.

And that’s it! These procedures are a bit more complicated than those in Chapter 8, as they have some internal logic (whereas Chapter 8′s procedures are merely SELECT statements). But it’s still not hard to rewrite these procedures using standard PHP-MySQL, as I’ve just shown. In a subsequent post, I’ll rewrite the procedures from Chapter 10 using standard PHP-MySQL. One of those procedures has quite a lot of logic to it, and will be the most complicated to translate.

• About The Previous Newsletter
• About This Newsletter
• On the Web => Myows | Free Online Copyright Protection
• On the Web => URL Rewriting for Beginners
• On the Web => Chapter from “Effortless E-Commerce with PHP and MySQL”
• On the Blog => More Links About HTML5
• On the Blog => Rewriting the E-Commerce Stored Procedures
• Q&A => What do you think the future looks like for Flex developers?
• Q&A => Would you ever consider doing video tutorials?
• What is Larry Thinking? => The Evolution of a Newsletter
• Book Giveaway => “Effortless E-Commerce…” and “Effortless Flex…”
• Larry Ullman’s Book News => “Effortless E-Commerce”, “PHP for the Web”, and More!

About the Previous Newsletter

So the first thing to acknowledge is how the last newsletter turned out…As I mentioned at the beginning of that newsletter, it was the first newsletter sent using a new system (specifically, a commercial WordPress plug-in named Newsletter Pro. To start, I wrote the entire newsletter, entered it into the new system, and sent myself a test newsletter. In that test newsletter, I tested all the links. So far, so good. Then I thought: I should add internal links so “In this edition” list at the top is anchored to the articles below. Naturally, being such a minor detail, I didn’t bother to test this again. And that’s where I went astray! Always test again. Always. As many of you discovered, those links didn’t work at all (the others in the newsletter did, or should have).

The cause of the problem is this: one of the features of Newsletter Pro is the ability to track links. I thought it might be interesting to use such a feature. Unfortunately, as I found out, the system is not smart enough to distinguish between absolute URLs and internal anchors. So there’s that then.

Second, I forgot to include an unsubscribe link in the previous newsletter. That’s not the end of the world, but an unsubscribe link should be prominent (in some countries, that’s a legal requirement, too).

Third, as some of you found out, the PDF links in the E-Commerce-related posts on my Web site weren’t working (well, not until I discovered this myself and corrected the issue). This had to do with how WordPress handles relative links (i.e., not consistently well).

All in all, not so good on my part. My apologies for the mistakes and the lack of professionalism. To be fair, I think of the newsletter as something that should be colloquial and casual, but still… I’ll try to do better. Speaking of which…

About This Newsletter

This is the first newsletter using a new, new system! Considering the problems I had with the previous newsletter, and because of secondary concerns about the Newsletter Pro plug-in (more on this later in this edition), I decided to re-investigate the mailing list options. I’m now using commercial email marketing software from Campaign Monitor. As you can hopefully already tell, the end result should be much more professional. Also, towards that end, I believe this newsletter should be easily viewable in plain text, if that’s your preference.

As for this edition’s content, there are links to some good stuff, including an entire chapter from my “Effortless E-Commerce with PHP and MySQL” book available for free online. I also answer a couple of questions and talk in depth about how this newsletter has evolved over the years. If that’s not enough to pique your interest, you may want to check out the book giveaway. There are three titles available!

As always, thanks for reading and let me know what questions, comments, or issues you may have. Especially the issues, because new systems bring new problems!

On the Web => Myows | Free Online Copyright Protection

In previous newsletters, I’ve talked about copyright issues with respect to writing, Web sites, and other content. You don’t actually need to indicate that anything is copyrighted in order to protect it, but having proof of authorship is critical in pursuing copyright violations. Towards that end, one solution is Myows, a free, online copyright management and protection system. I haven’t personally used it but expect that some of you will appreciate what Myows offers.

On the Web => URL Rewriting for Beginners

One of the most important technologies people need to familiarize themselves with after learning dynamic Web development is the Web server itself. Whether it’s Apache, IIS, Abyss, or whatever, harnessing the power of, or simply being able to properly configure, the Web server is a crucial skill set. Among that set is URL Rewriting. There are a number of reasons to use URL Rewriting, the most common being the desire to change a URL from something technically useful, such as www.example.com/browse.php?cat=2 to something semantically useful, such as www.example.com/browse/Hard+Drives/. To get started, check out this nice tutorial on the subject.

On the Web => Chapter from “Effortless E-Commerce with PHP and MySQL”

Peachpit Press, publisher of my book “Effortless E-Commerce with PHP and MySQL”, has posted a chapter from the book on their Web site (technically New Riders is the publisher, but Peachpit owns New Riders). The posted content represents the entire Chapter 4, “User Accounts,” which is the second chapter in Part Two: Selling Virtual Products. The posted content covers how user accounts will be managed in the site (in the particular example, only paid, registered users may access content). The material walks through the creation of several helper functions, then develops an entire registration, logging in, logging out, and password management system. The chapter concludes with some security improvements one could make.

On the Blog => More Links About HTML5

A couple of weeks ago I posted a slew of links that I have come across involving HTML5. If you’re curious about the subject (and if you do any Web development, you really should be), check them out.

On the Blog => Rewriting the E-Commerce Stored Procedures

In the second e-commerce example in my “Effortless E-Commerce with PHP and MySQL” book, stored procedures are used for all of the public-side database-related functionality. This includes: the displaying of product categories, specific items, and sale items; cart and wish list management (adding items, updating quantities, removing items); and order submissions. However, not everyone can use stored procedures, in particular those on some shared hosting environments.

One reader recently said (in the forums) that they couldn’t use stored procedures with their host, so I volunteered to rewrite some of the stored procedures as standard PHP and MySQL. In the first post towards that end, I rewrote the procedures, and corresponding PHP scripts, from Chapter 8, “Creating a Catalog”. Over the next month or so, I’ll rewrite the stored procedures, and the PHP scripts that use them, from Chapters 9 and 10.

Q&A => What do you think the future looks like for Flex developers?

Rob asked this question, specifically referencing the “Apple/Flash logjam”. In other words, with Apple being difficult (to use a polite word) about Flash (not) running on its mobile devices, how does this impact Flex/Flash Builder developers? This is a good question.

Without opining too much on the Great Apple/Adobe War of ‘10, I feel there’s got to come a time when Flash will run on Apple’s devices. Perhaps Adobe will work some with Apple to make Flash run more reliably. Perhaps Apple will cave to pressure (or Department of Justice investigations) and change their position. Probably both will happen and then some. But eventually Flash will run on iPods, iPhones, and iPads. This I believe. And Flash is already available on non-Apple devices, which I think constitutes a larger percentage of the overall market (e.g., even though no individual Android phone sells better than the iPhone, there are more Android-based phones sold than iPhones). The next version of Flex is adding extra features specifically targeting the mobile market, so Adobe is clearly not laying low on that front.

But Flash on mobile devices is just one consideration. While there is increasing interest in what can be done through mobile devices, the fact is that non-mobile devices are still a vastly larger market, and I can’t see that changing for some time. Flash has a huge share of the video market and it’s one of the very few plug-ins that comes included with most browsers. (In fact, Google and Adobe have been working on a version of Flash that’s more tightly integrated with Chrome, even updating Flash automatically when a new version comes out.)

And although it’s a smaller market than Web-based applications, you can use Flex to create cross-platform desktop applications via Adobe AIR. I’m a pretty big fan of this feature, but I admit I’m a bit of an outlier on this particular topic.

So, in short, I’m not particularly concerned about the future for Flex developers. Flex is a very good product with lots of uses and Flash has an extensive user base. Even Apple’s stubbornness or the forthcoming HTML5 (which will be broadly supported when exactly?) can’t change that.

Q&A => Would you ever consider doing video tutorials?

Parker asked this question. I acknowledge that video tutorials are an excellent way to learn and are becoming increasingly more common, but it’s just not my thing. I think of myself as a writer, not a video instructor (or voice-only screencasts, for that matter). Coincidentally, Peachpit Press wanted me to add little video clips for the electronic version of my “PHP for the Web: Visual QuickStart Guide” (4th Edition) and I said “No” to that as well. I appreciate the interest, however!

What is Larry Thinking? => The Evolution of a Newsletter

Largely because of the changes to my Web site (going from www.DMCInsights.com to www.LarryUllman.com and changing from a largely custom system to one based upon WordPress), I’ve lately been thinking about the evolution of this newsletter. As I’ve said many times over by now, I’m not a marketing type of person. Although I’d love it if everyone in the world bought a copy of everyone of my books (why not two copies?), I’m not a salesman. I just don’t want to talk people into buying anything. In my mind, I write what’s hopefully a good book and people will buy it because it’s good. But just as creating a great Web site doesn’t mean people will go visit it, writing a good book doesn’t necessarily mean it will sell. So I believe this newsletter started off, in 2007, as a marketing tool, in part. Still, I never wanted it to be a “Buy! Buy! Buy!” kind of thing, but rather “here’s some other information you might appreciate and oh, by the way, here’s what’s going on with my books”. Although a number of the references in these newsletters are book related, I’ve always put the “Larry Ullman’s Book News” section last, so as not to be overbearing. That’s my thinking with the newsletter, anyway, but it’s interesting to see how it’s changed in three years.

When I began this newsletter, I didn’t think much about where it would go or how popular it might become. For most of the past three years I used the free PHPList. While not great, PHPList is pretty good, especially for being free. It handles subscriptions, both HTML and plain text versions, and, in theory, bounces. Unfortunately, the subscription form required that the user click a link to go to another page (admittedly, I could have changed my design to correct this flaw). Also, I had to maintain two template versions of the site, as PHPList couldn’t integrate into my other code. (When you add in the fact that the blog was separate from the main site, the DMC Insights, Inc. site had three sets of template files to maintain, all to create a similar look. Ugh!)

When I recently moved to a complete WordPress solution for my site, I wanted something that could be integrated into WordPress. I got that with Newsletter Pro, a commercial plug-in (it’s only like $20). Newsletter Pro integrated perfectly with WordPress and by placing a subscription form front and center, there were frequent new subscribers. Then I went to use the plug-in to send a newsletter for the first time and had the aforementioned links problem (what’s the HTML entity for egg on one’s face?) Granted, another review of the newsletter on my part would have caught that, but I was also having a hard time figuring out how to customize the newsletter’s HTML template. Forced into sending HTML-only email, a custom template became a pseudo-requirement in my mind. But the developer of the Newsletter Pro plugin isn’t great about documentation or support (even though it’s a commercial product), so I suspected the template customization was one of several significant hurdles to come. Plus the Newsletter Pro system didn’t seem to handle bounces properly and the spam filters for some users were blocking the content (even though they were subscribers). I decided to look into alternative systems.

In the process of researching how to make HTML emails look sharp across the variety of email clients, I came upon Campaign Monitor, which provides email marketing software. Unlike the solutions I’ve used thus far, it’s a commercial route, but perhaps it’s time for that, if only for a bit more professionalism and peace of mind. It’s going to cost me maybe $20/month to send out one newsletter per month, which seems fair enough. And because of spam protections and the like, the Campaign Monitor system should have better luck getting my newsletter into everyone’s inbox. Campaign Monitor will send out both HTML and plain text versions, and I can still use a WordPress plugin to tie the subscription into my main site. As I’ve said many times over, I hate spending money, but with over 1,200 subscribers, I can’t afford to go the cheap route anymore. And if you’re curious how big the newsletter has become: you’re one of over 1,200 subscribers! I don’t know that that is a lot, but it seems like a grand number to me.

Of course, the key to a good newsletter is the content. In creating the new version of my site, I imported all 32 previous newsletters into WordPress. The first thing that struck me was how long they’ve become! There’s a classic quote from Blaise Pascal that, translated into English, goes “I have made this letter longer only because I have not had the leisure of making it shorter.” Which is to say it takes time to be concise. That is part of the issue for me. Another factor is that the newsletter used to be one main topic, plus maybe a paragraph on three or four others. Now the newsletter is one main topic, plus a paragraph on three or four others and a couple of paragraphs on three or four more. But I’m not getting any complaints and as I’m only sending out one newsletter per month, longer makes more sense (i.e., hopefully there’s something in each newsletter for everyone). On the other hand, perhaps if I were to send them out more frequently, there’d be less I feel the need to say in each.

In terms of how I produce the newsletter, I originally created it in my trusty text editor. I’d look at my email, my browser’s bookmarks, my blog postings, and so forth, compile a random collection of thoughts and questions, write it out, add HTML, etc. For 30 newsletters, that’s the “system” I used. A couple of newsletters back I started using Scrivener, an excellent word processing application for Macs. One benefit of Scrivener is that it organizes projects so that I can have both my research (i.e., my collection of potential topics) and my writing in the same application, saving me from switching from program to program. Once a draft was complete, I’d still output the text and open it in my programming text editor where I could add the HTML. For this newsletter, I’ve finally started using Markdown, a markup syntax supported by Scrivener and many other applications (I may write my JavaScript book using Markdown or Multimarkdown, too). With Markdown, I use very simple symbols and formatting—but absolutely no HTML tags—and can still output HTML. I think adopting Markdown is going to save me a lot of time and if you do any writing yourself that’s intended for one or more destinations, it’s worth your time to check it out, as well.

So looking back, what have I learned in three years? One, my word do I have a lot to say! Two, I’m extremely fortunate to have the following I do (I hate to use that word, but I couldn’t think of a better, less egocentric one offhand). Third, the odds of getting questions and comments goes up dramatically when I’m giving away books! (Although with 1,200 subscribers, it’d be overwhelming if everyone replied to every newsletter.) Fourth, when you don’t really have a long-term plan, you can’t be too surprised by where you end up. Fifth, sometimes spending a little money is worth it. And sometimes not! Finally, and most importantly, the evolution of the newsletter has been a good reminder to me that you have to be willing to constantly reconsider how you do things. The right solution today is virtually guaranteed not to be the best solution tomorrow. Thinking otherwise is how you get left behind.

Book Giveaway => “Effortless E-Commerce…” and “Effortless Flex…”

You must be subscribed to the newsletter in order to qualify for the book giveaway.

Larry Ullman’s Book News => “Effortless E-Commerce”, “PHP for the Web”, and More!

As mentioned in my previous newsletter, five chapters from my “Effortless E-Commerce with PHP and MySQL” book have extra content, available as PDFs. I’m also writing some extra code and posts, such as showing how the stored procedures used in the book’s second example would be written using standard PHP and MySQL (mentioned above). You can find all of this and any other extra that come up specifically for that book through www.LarryUllman.com/tag/ecom/.

On a similar note, I just agreed to write four articles and five blog posts for Peachpit Press’s Web site, all supporting the “Effortless E-Commerce with PHP and MySQL” book. The blog posts will discuss the five most important security criteria for e-commerce sites, similar to a question that I answered in a blog comment. The four articles will explain how to implement extra features in an e-commerce site. The specific features are: adding customer reviews, product recommendations, an Ajax-enabled shopping cart, and an Ajax-enabled product rating system. I’m writing these over the next month and they’ll go online in early 2011. I’ll post links to them on my Web site as they go live.

I just completed Chapter 7 of my next book: the fourth edition of “PHP for the Web: Visual QuickStart Guide”. Largely the revision will fix any minor problems, update the code for the latest version of PHP, and add a “Review and Pursue” section to the end of each chapter. That section will consist of both questions (based upon the chapter’s content) and prompts for what else the reader can try using the information they just learned. If there’s room, I’m thinking about adding one short example chapter, similar to those at the end of the PHP and MySQL book.

My self-published JavaScript book is still on the docket and should be actively pursued starting in January. I have a couple of months before I’ll need to work on the fourth edition of my “PHP and MySQL for Dynamic Web Sites: Visual QuickPro Guide,” so I’ll try to do as much as possible on the JavaScript book in that interim.

• About This Newsletter
• On the Web => Introducing LarryUllman.com!
• On the Blog => Extras for “Effortless E-Commerce with PHP and MySQL”
• Q & A => Why use the Yii framework?
• Q & A => When will you be doing an OOP book?
• Q & A => What are some sites that have been created based upon your work?
• What is Larry Thinking? => OOP vs. Procedural, the Battle Continues
• Book Giveaway => “Effortless E-Commerce with PHP and MySQL”
• Larry Ullman’s Book News => “Effortless E-Commerce with PHP and MySQL” and more

About This Newsletter

As a warning, this is the first newsletter being sent out using my new system. I apologize if something totally goes haywire. If so, please let me know and I’ll correct it ASAP.

When I revamped my Web site (changing the domain name from www.DMCInsights.com to www.LarryUllman.com and going from a mostly hand-coded site to one based upon WordPress), I looked into the best ways to integrate a newsletter into a WordPress theme. The highest regarded option seemed to be the Newsletter Pro commercial plug-in. It’s designed for WordPress and has some great features. Unfortunately, the one feature it does not have is support for a plain text version. I mentioned this in my previous newsletter and received no complaints (in fact, I received one response along the lines of “It’s 2010, who cares about plain text newsletters?”). Hopefully everyone’s okay with receiving an HTML version, although I’m going to keep the HTML relatively simple. Of course, I haven’t yet figured out how to customize the newsletter’s template using this new system, so what you’re seeing is neither plain text nor pretty HTML, but rather plain HTML. It’s a start, though.

I actually thought this newsletter would be about this recent change, but that turned out not to be the case. Largely this newsletter ended up being about my most recent book, “Effortless E-Commerce with PHP and MySQL“, and object-oriented programming. I’ve thrown in some answers to questions and other stuff. Let me know what you think—about the new site, the new newsletter format, this particular newsletter, etc.—and, as always, thanks for reading!

On the Web => Introducing LarryUllman.com!

My new Web site and new domain name, www.LarryUllman.com, went online on October 31st. If you haven’t checked it out yet, I encourage you to do so. In another newsletter I’m going to write more about the change (once I’ve received more data), but so far I’m quite pleased with the end result. I like the cleaner look of this site and it adds features the previous version didn’t have. Plus, it puts my name and my books front and center, which is kind of the point, after all.

On the Blog => Extras for “Effortless E-Commerce with PHP and MySQL”

After finishing my “Effortless E-Commerce with PHP and MySQL” book, I was left with five PDFs of extra materials. This was content originally intended for the book, but that had to be cut due to page count limitations. Mostly these PDFs discuss and detail various ways to expand or just alter the book’s examples. Although the content is specific to that text, you might get some benefit from them even if you haven’t seen the book. You can find these PDFs among all the extras for the book at my new site.

Q&A => Why use the Yii framework?

I’ve received a couple of questions lately (from Brett and from Joel) about why I prefer the Yii framework. I’ve discussed this before, but it bears repeating. But first , let’s set aside the discussion surrounding using a framework or not. Maybe you like frameworks, maybe you don’t. Maybe, like me, you’ve found a framework you really like, but that still doesn’t mean you’d use the framework on every project. The question here is: Yii vs. CakePHP or Kohana or CodeIgniter or Zend Framework or whatever and how one makes that decision.

My first criteria when choosing a framework is that it must be written for PHP 5, which is to say it cannot run on PHP 4. The way PHP treats objects changed dramatically in PHP 5 and, in my opinion, any framework that will run on PHP 4 just isn’t optimal. Offhand, I forget which frameworks this criteria rules out.

Normally my second criteria would probably be the amount of documentation available. But “amount” and “quality” are not the same thing. The Zend Framework has a ton of documentation, but I found that documentation to be cumbersome and often leaving me with unanswered questions. Conversely, especially when I started using it, the Yii documentation was sparse, but I found Yii intuitive enough that the lack of documentation wasn’t (generally) a show-stopper. I would caution that the quality of anything’s documentation is hard to gauge up front; it’s when you’re trying to figure out something hard at 3 AM that you really see how good the documentation and support is!

Acknowledging that today’s Web sites commonly use JavaScript for added functionality, JavaScript support is another criteria and one of the main reasons I went with Yii. The Zend Framework, which was the first PHP framework I used, has the Dojo Toolkit as its built-in JavaScript framework. I prefer jQuery, though, which is Yii’s built-in solution. So if you’re already familiar with one JavaScript framework, you probably want to make sure that your PHP framework uses it natively as well.

On a similar note, you’ll eventually need to tie the framework-based site into some third-party code, be it a forum or a search engine or whatever. For any decently-complex site, there will be some legacy, third-party system that you have to integrate. Finding a framework that nicely adapts to such situations will make that process all the easier. And one thing I like about Yii is that it can use third-party extensions easily. The result is that I’ve often used the Zend Framework’s Search, PDF, and Email modules in otherwise Yii-based sites.

Finally, I like that Yii generates a lot of the code and file structure for you, meaning that most of your time is just spent tweaking existing code. The first framework I used was Ruby on Rails and it does the same thing. I found with the Zend Framework that I spent far too much time creating folders, creating new scripts, cutting and pasting, etc. This is a minor concern, of course, but something that mattered personally to me.

In the end, frameworks are like cars (you know I like my metaphors): they’ll all pretty much get you where you want to go, it’s really a question of what “feels right” to you. The Zend Framework never felt right to me and the Yii framework really does. Perhaps I might feel the same way about CakePHP, CodeIgniter, Kohana, etc., but, for now, I’ve got a car that works for me. And on that note: if you’re currently using a framework that feels right for you and gets you where you need to be, you probably shouldn’t switch to Yii or any other framework. When it comes to being productive, I’m not a proponent of “change for change’s sake”. If you like learning new things, or want to look into a framework for the first time, then maybe you should consider Yii, but when shopping for a new framework, I would start by looking at the PHP version, the available documentation and support, the JavaScript framework integrated, and the framework’s support for third-party extensions.

Q&A => When will you be doing an OOP book?

Parker had asked when I might be doing an OOP book (and thanks for the interest!). In case you’re not familiar with it, my “PHP 5 Advanced: Visual QuickPro Guide” book has about 150 pages or so dedicated to OOP in PHP from A to Z. Specifically the book has three long chapters on the subject: Basic OOP, Advanced OOP, and Real-World OOP. As a point of comparison, the Real-World OOP chapter rewrites an earlier example from the book using OOP. Neither my “PHP for the Web: Visual QuickStart Guide” nor my “PHP and MySQL for Dynamic Web Sites: Visual QuickPro Guide” book discusses OOP in any detail, and for good reason: while you can debate whether or not OOP knowledge is mandatory for today’s PHP programmers (more on that later in the newsletter), a decent discussion of OOP requires at least 100 pages. Putting those 100 pages in one of these other books would mean cutting out 100 pages of content that clearly is more critical, like SQL or MySQL or sessions or… But if you are curious about OOP in PHP, I invite you to check out my “PHP 5 Advanced: Visual QuickPro Guide“.

Q&A => What are some sites that have been created based upon your work?

I’ve received a couple of responses to the previous newsletter’s request for sites you’ve created (using, in part, what you’ve learned from my books). Here’s what two people have done:

Steve, a Web developer in America’s “Music City” of Nashville, Tennessee, shared a couple of sites he has done for musicians: www.janisian.com and www.gretchenpeters.com. Steve uses PHP and MySQL to create administrative areas where the artists themselves, without a lot of technical know-how, can post news items and tour dates on their sites.

Edward really likes applying his math skills to Web sites, creating an online application with dozens upon dozens of conversion calculators (at www.CalculatorSoup.com). He also took what he learned about OOP in the “PHP 5 Advanced: Visual QuickPro Guide” book and has turned a lot of the calculators into reusable classes and methods. Another project of his, www.TeacherWishLists.com, allows educators to create “wish lists” through which generous donors can support what they do. Edward uses PHP and MySQL for logging in and out, session management, authentication and security, administration and more.

Thanks to Steve and Edward for sharing. If you’d like to share what you’ve done, let me know!

What is Larry Thinking? => OOP vs. Procedural, the Battle Continues

I never have a long-term plan for my newsletters. When it’s time to send a new one out, I sit down, look through the odds and ends I’ve collected over the past couple of weeks, and put them together. Sometimes the result is a hodgepodge of things with no cohesive theme. Sometimes a theme develops, as the subject of OOP seems to in this particular newsletter. (Similarly, this is how my brain works: sometimes focused and engaged, sometimes scattered about.) I’ve had a couple of questions recently about OOP and a couple about frameworks, which are almost always OOP-based. There was quite a bit of discussion a few months back about OOP making it into my “Effortless E-Commerce with PHP and MySQL” book (it did not). And I recently had a forum encounter about OOP as well. All in all, a bit of writing about OOP in PHP due, I feel.

First, to be clear, let me state unequivocally that I’m not anti-OOP or pro-OOP. I don’t have formal training in OOP or procedural programming and I don’t have a vested interest in the success of either approach (but I am argumentative). Do I use OOP? Absolutely. Sometimes. Which leads us to the reason this is a discussion at all: PHP is one of the rare languages that supports both OOP and procedural programming (C++ is another). If you’re programming in Java, Ruby, JavaScript, and others, you have no choice but to perform object-oriented programming. If you’re programming in C, you have no choice but to do procedural programming. If you’re using a framework in PHP, you almost always have to use OOP. But for general PHP programming, it’s really up to you.

The arguments for OOP over procedural are that OOP is easier to reuse, extend, and maintain, that it’s better for use in team environments, that it’s more secure and less likely to have bugs, and that it’ll make you three inches taller. Okay, I made one of those up. None of these are true. None.

The arguments for procedural over OOP are that procedural is faster both to program and to execute, among other reasons. None of these are true. None.

Bottom line, I think we do ourselves (as developers) a disservice when we think that X is categorically better than Y. The real question should always be: what is best for this particular situation? For example, OOP has benefits when working on large projects or in teams; conversely, procedural has benefits on smaller projects. So it’d be a mistake to think “Oh, OOP is better, so I should use it to handle this contact form.” And I think that’s the trap people, especially beginners, fall into. I worked with a guy 10 years ago who insisted on using OOP for his projects (and this was back when OOP in PHP was more poorly supported). His version of OOP was to create a class that defined EVERY function the site would need. It was terrible, but he thought himself a superior programmer because he used OOP. On the other hand, two huge projects, in terms of both code and popularity, use procedural PHP. Those projects: phpMyAdmin and WordPress. Procedural.

So here’s the real truth: there are situations where OOP may be better and situations where procedural may be better. And in part it depends upon how you define “better”. Faster? Easier? Extendible? Reusable? What is the project? Who is working on it? How are their OOP skills? It’s safe to say that the OOP created by a beginner programmer will not be better than the procedural code put forth by an experienced one.

To be clear, I’m not arguing against OOP here, just arguing against assumptions people make about OOP (and people don’t really argue for procedural). Every single situation should be decided based upon what’s appropriate for that situation, nothing more (although I acknowledge that’s not the way it always works in the real world). Let’s not lock ourselves into thinking we must do X. PHP allows you to program both procedurally or using OOP, so take advantage of that feature. I’ve worked on several Web sites in 2010, two of them were just procedural and the rest were OOP. In each case I would like to think that I choose not the “better” approach but the better approach for the project, which is to say the right approach. (As a segue, one could make a similar argument for Ajax vs Flash for Rich Internet Applications: each has its strengths and weaknesses and it’s best to pick the right tool for each particular job.)

All of that diatribe is intended to address the question “Should I use OOP or procedural?” to which my answer is an unequivocal “Depends”. But if you change the question to “Should I learn OOP?”, the answer is “Absolutely”. For one, employers seems to prefer it, not that I have much direct experience with employers any more. Second, I’m of the opinion that given a choice between learning more and not learning more, always go for learning more. And third, if you know both OOP and procedural, then you can make the proper, educated decision as to which is the right tool for the job at hand.

Book Giveaway => “Effortless E-Commerce with PHP and MySQL”

I gave away about a dozen copies of my “Effortless E-Commerce with PHP and MySQL” in response to the previous newsletter. If you didn’t win a copy, I may giving more away in the future. Or you can ask for it from your local library. Or you could, you know, buy a copy! As for those that did win copies, if you like the book, I always appreciate positive online reviews!

Larry Ullman’s Book News => “Effortless E-Commerce with PHP and MySQL” and more

I’m very pleased to say that my “Effortless E-Commerce with PHP and MySQL” is now out and available in bookstores near you. Well, that really depends upon where you’re at, but it’s been released in America, and will become available internationally in time, I expect. Unfortunately, I never know the particulars of such things. Right now, Amazon.com has it listed for $23.09. If you’re broke, you can always request that your local library get it for you!

I’ve begun working on the fourth edition of my first book, “PHP for the Web: Visual QuickStart Guide“. This is going to be a rather light update of the book, with maybe only 10-20% of it changing. The main addition are a couple of pages at the end of each chapter with review questions and prompts for experimenting on your own. This addition is largely due to repeated reader requests. I also need to update the regular expressions chapter, as the easier-to-understand ereg_* functions are being deprecated in PHP, meaning Perl Compatible Regular Expressions (PCRE) are to be the default.

I haven’t done much (concretely) on my intended self-published JavaScript book, but I haven’t forgotten about it. Once the PHP book is well underway, I’ll start dedicating more time to the JavaScript book.