If you’re in Turkey specifically, or nearby, I’d recommend you attend. And if anyone has any recommendations as to what I should do while I’m in Istanbul, please let me know!

The sad fact is that most online ventures, particularly e-commerce ones, will fail. It is irresponsible to go into a new project without being aware of that fact, and without acknowledging that the same fate could befall you or your organization. But it is exactly by recognizing the possibility, if not likelihood, of failure, that you better your chance of success. Or, if success is not to be, then the odds of failing without being crippled by the experience.

In this speech, writer and Web development expert Larry Ullman presents his best advice for succeeding in your e-commerce ventures. The speech begins with the big picture of what e-commerce is, in all its facets, and puts forth a healthy and prosperous perspective that you should have when starting a new project. The speech then goes into making the right, smart technical decisions, before concluding with case studies from Larry’s own experiences.

Some of the specific points covered include:
• Establishing project goals
• Allowing a site to expand organically
• Understanding and enforcing security
• Avoiding the common causes of failure

Whether you’re looking to create or expand an online extension of a conventional business, or are dreaming of creating the next Amazon, you’re sure to hear lots of practical, specific, and real-world advice in this speech.

PayPal’s Website Payments Pro provides two APIs for processing payments: Direct Payment and Express Checkout. Both allow you to accept debit and credit cards (the specific cards will differ slightly from one region to the next), while Express Checkout also allows users to pay with their PayPal account. In both cases, the customer never leaves your site, unlike when using PayPal’s Website Payments Standard. PayPal does require you to use both APIs in order to use Website Payments Pro. To keep this post from getting too long, I’ll only address the Direct Payment, which most easily correlates to the Authorize.net code in the book. If you need help with the Express Checkout aspect, let me know.

To understand how to use Website Payments Pro instead of Authorize.net for the second example, let’s first look at how Authorize.net is used. The customer begins the checkout process on checkout.php. This script takes and validates the user’s shipping information. Upon successful validation, the user is redirected to billing.php, which takes and validates the billing information, including the credit card. Upon successful validation, the payment is processed by including two scripts: gateway_setup.php and gateway_process.php. For extra security, these two files are stored in a private folder outside of the Web root directory.

Within gateway_setup.php, a bunch of parameters are set within an array named $data:

<?php
$data = array();
$data['x_type'] = 'AUTH_ONLY';
$data['x_card_num'] = $cc_number;
$data['x_exp_date'] = $cc_exp;
// etc. 

Then the gateway_process.php script adds some more details to the array:

// Your account info:
$data['x_login'] = '75sqQ96qHEP8';
$data['x_tran_key'] = '7r83Sb4HUd58Tz5p';
// etc. 

Finally, gateway_process.php converts that data into a useable format for the cURL request, performs the cURL request, and reads the response into the $response variable. Finally, this variable is converted into an array:

$response_array = explode($data["x_delim_char"],$response);

That’s the end of the gateway_process.php script. The script that invokes it—billing.php—will then use $response_array to take the next logical steps.

In order to switch the payment gateway in use, you must replace the code in gateway_setup.php and gateway_process.php. This is much easier than you might think. For PayPal’s Website Payments Pro, you’ll need to change the code in those two files so that instead of creating, for example, $data['x_card_num'], it creates $data['ACCT']. The proper values and their meanings can be found in the PayPal documentation.  This means that gateway_setup.php would contain:

<?php
$data['PAYMENTACTION'] = 'Authorization';

// Billing info:
$data['ACCT'] = $cc_number;
$data['EXPDATE'] = $cc_exp;
$data['CREDITCARDTYPE'] = $cc_type;
$data['CVV2'] = $cc_cvv;
$data['FIRSTNAME'] = $cc_first_name;
$data['LASTNAME'] = $cc_last_name;
$data['STREET'] = $cc_address;
$data['STATE'] = $cc_state;
$data['CITY'] = $cc_city;
$data['ZIP'] = $cc_zip;
$data['COUNTRY'] = 'US'; // Or other, if accepting international orders.
$data['IPADDRESS'] = $_SERVER['REMOTE_ADDR'];

As in the book, these orders are being authorized first and captured later. The actual transfer of funds takes place in a second step, when the order ships. For simplicity sake, you could change the PAYMENTACTION to Sale, assuming that would be appropriate (and legal) in your situation. PayPal also wants you to pass along the customer’s IP address, for fraud prevention purposes. And you’ll need to get the credit card type from the user, which isn’t requested in the book’s original code.

Next, gateway_process.php needs your own information:

// Your account info:
$data['SIGNATURE'] = 'your API signature';
$data['USER'] = 'your API username';
$data['PWD'] = 'your API password';

This information will be determined when you sign up for Website Payments Pro with your PayPal business account.
Next, there’s the payment gateway stuff:

// PayPal Website Payments Pro Stuff:
$data['VERSION'] = '85.0';

// Transaction stuff:
$data['METHOD'] = 'DoDirectPayment';

And then there’s the order information:

// Order info:
$data['AMT'] = $order_total;
$data['CURRENCYCODE'] = 'USD';
$data['INVNUM'] = $order_id;
$data['CUSTOM'] = $customer_id;

The CUSTOM option lets you send your own data along, in this case the customer ID (although the customer ID could also be retrieved later via the transaction ID).

(Note: Dividing the data into these two files may seem odd, but it’s done so that the administrative side can easily use the same gateway_process.php script, after running a gateway_setup_admin.php script. If you need help with the admin process, to capture a prior authorization, let me know.)

Also, the GATEWAY_API_URL constant in gateway_process.php needs to be changed to PayPal’s proper URL: https://api-3t.sandbox.paypal.com/nvp for testing, https://api-3t.paypal.com/nvp for live purposes.

After identifying all the values, the gateway_process.php script converts that data into a string of URL-encoded name-value pairs. That does not need to be changed, nor does the cURL request made at the end of that script.

In response to the request, PayPal will return a string which contains more name-value pairs: TIMESTAMP=X&ACK=Success&VERSION=85&… This must be broken into an array:

$a = explode('&', $response);
$response_array = array();
foreach ($a as $item) {
 list($key, $value) = explode('=', $item);
 $response_array[$key] = $value;
}

This code is a bit different and more complex than the Authorize.net code, as Authorize.net only returns a string broken up by the pipe character (|). But at this point, <strong>$response_array</strong> is usable. Unfortunately, <strong>billing.php</strong> will need to be modified, because that script assumes a numerically indexed array. First, you’ll need to change the call to the stored procedure:

$r = mysqli_query($dbc, "CALL add_transaction($order_id, '{$data['PAYMENTACTION']}', $response_array['AMT'], $response_array['ACK'], '$response_array['PAYMENTADVICECODE']', $response_array['TRANSACTIONID'], '$response')");

After that code, different reactions occur based upon the success of the transaction. To check that, use $response_array['ACK'], which should have a value of Success. Other values include SuccessWithWarning, Failure, and FailureWithWarning. The response array will store the actual reasons in order elements in those situations. The unique transaction ID will be stored in $response_array['TRANSACTIONID']. This would be needed for the capture phase, if using that route. Again, if you need help with updating the admin pieces, let me know.

So that’s the gist of how you would use PayPal’s Website Payments Pro instead of Authorize.net for direct payment with the second e-commerce example in the book. As already mentioned, PayPal does insist that you create an Express Checkout process, too. It’s actually slightly simpler than this code because the user’s billing and shipping information is already stored in PayPal. To integrate this option, you’d add PayPal’s Express Checkout button to your cart.php page, and that would take the user to a different page on your site, where he or she enters his or her PayPal email address and password. This is then sent to PayPal for authorization, along with the order particulars. For more, see PayPal’s documentation.

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.