Tag Archives: Web Development

Why live shipping calculations for ecommerce are the bane of my existence

I’ll be frank: I don’t really like ecommerce. I’ve floated for most of my 23-year career in web development in the fantasy of a Platonic ideal of an online world: bytes streaming from point to point on a perfect network. No messy complexities of the physical world to concern me.

Well, obviously none of that is true. And I’ve been dealing with ecommerce in some form or another for at least 20 of those 23 years. But I still find the nitpicky details of sales tax and shipping logistics both mind-numbingly dull and infuriatingly (seemingly pointlessly) complex.

Which brings me to the crux of today’s rant. Bringing simplicity to all of this… or, at least, to the part I have to deal with.

Granted, I am not an accountant, and I don’t have to deal with balancing my clients’ numbers at the end of the quarter. But from my perspective, there are some simple solutions to the fact that calculating shipping sucks.

These days I deal mainly with WordPress, and therefore with WooCommerce. There are a lot of extensions to WooCommerce now for live shipping rate calculations. You can pay an annual fee for tools that connect you to shippers’ APIs to give you exact shipping rates. And all you need to do is:

a) determine exact weights and dimensions of all of your products,

b) figure out exactly what types of boxes/packages you’re going to use (and determine their exact weights and dimensions), and

c) plug all of those numbers into WooCommerce, and also

d) decide which of those types of packages are applicable to which products, create the appropriate Shipping Classes, and apply them to the corresponding products; then

e) set up Shipping Zones for each part of the world you’ll ship to,

f) add shipping methods in each of those zones for each of the shippers you’re working with,

g) go into each shipper, in each Shipping Zone, and select from the dozens of shipping services each shipper offers (although you might have to do this multiple times, if you want to restrict the methods you offer based on your Shipping Classes), then

h) test adding these products to your cart, enter an applicable shipping address, and see if you get the right shipping charges… or any shipping charges at all… because you very likely won’t, because for instance you may not realize that

i) WooCommerce Services no longer offers free access to USPS live shipping calculations for new sites created after WooCommerce 3.6, and you now need to buy a separate extension for $79/year to do that. But the free plugin won’t give you any indication that this is the case; it will still show you all of the shipping methods in the configuration pages, it just won’t give you back any rates on the checkout page, and you won’t have a clue as to why until you stumble upon a small note to this effect on the WooCommerce documentation website.

In case you didn’t guess, I just went through all of this today. And this was on a site that only has 7 SKUs!

Of course, there’s a different way to approach this. You could, instead:

a) offer flat-rate shipping.

Obviously it’s not quite that simple. But here’s the thing: there’s no law saying you can’t charge customers more for shipping than it costs you. That’s the whole idea behind “shipping and handling.” In fact, whether you’re doing the fulfillment yourself, or you’ve hired an outside fulfillment vendor, you’re paying more to ship those products than the shipper’s calculated rate anyway, so you should charge more.

Here’s what I recommend.

First, decide on a shipping method. Or maybe a few. Depending on what you sell, you might want to use USPS Media Mail (if it’s applicable). Otherwise, you’ll most likely want to offer two shipping methods: a) ground (cheap but slow) and b) 2-day air (more expensive but reasonably fast). You choose the vendor you like best: USPS, UPS, FedEx, some guy they call “Crusty Pete” with a rusty old pickup truck, etc.

Find out approximately what it will cost, on average, to ship each of your products, by each of these methods. (This is a good use for Shipping Classes.) Then tack on an arbitrary “handling” fee, say $1 per item for ground and $2 per item for 2-day air.

Now, decide: do you want customers to see a shipping charge, or do you want to offer “free” shipping? My logic for this is relatively easy. You just need to balance these two considerations:

  1. People like to see free shipping.

  2. People don’t like to see ridiculously high prices for individual items.

If you are going to offer “free” shipping, you’re really going to take that approximated shipping cost for each item and add it to the selling price of the item itself. Does that make the price of the item seem exorbitant? If not, go for it. People like free shipping.

As long as the shipping price itself isn’t so huge that it causes people to balk when they see it on the checkout page, you can keep the item prices low and present the shipping charge there. Or, a mix: offer “free” ground shipping, included in the price of the item, and then at checkout give the option of “free ground shipping” or paid 2-day air, with the 2-day air prices set at whatever you determined they should be, minus the amount you had already rolled into the item prices for free ground shipping.

Flat-rate shipping isn’t literally flat rate, as in one fixed price no matter what you’re buying. Generally it’s a formula… a base price, plus a multiplier based on the number of items.

For instance, your flat-rate formula might be $5 base plus $2 per item. The customer buys one item? $7 shipping. Two items? $9 shipping. You just plug the formula into the settings, and the rest gets calculated automatically.

The whole purpose of having shipping charges at all is to cover your expenses. Paying an annual license fee for a live shipping calculator extension, plus paying a developer or consultant for their time in helping you wade through all of these complicated configurations, and troubleshoot the problems that crop up, only to end up charging customers exactly what you’re paying for shipping and not a penny more just ends up costing you money. And the fact that these extensions include an option to add on an arbitrary amount above the calculated rate gives the game away… You don’t have to charge customers exactly what you’re paying for shipping. You just need to cover your expenses.

Your time and (my) mental wellbeing are expenses too. As long as your accountant doesn’t get too frustrated with the variable amount of ancillary income you’re getting from the modest overage you’ve calculated into shipping and handling charges, free or flat-rate shipping is a much simpler and more manageable alternative to live shipping calculations.

Fixing a redirect loop on WordPress sites with WooCommerce when converting the site to all-SSL

Best practice these days is to run sites on all-SSL, not just the parts of the site that “need” it. But not long ago, it was common to apply SSL only when it was absolutely necessary, because SSL encryption meant a performance hit. Not anymore.

You may find, if you’re trying to convert an existing WordPress / WooCommerce site to all-SSL, that reconfiguring your URLs, by using a tool such as interconnect/it’s super-slick, powerful (and dangerous) Search Replace DB tool, that once you’ve made the changes, your home page kicks into a redirect loop, indefinitely cycling between http:// and https:// versions of your URL.

WooCommerce may be to blame!

Specifically, a setting in WooCommerce called “Force HTTP when leaving the checkout”. Head on over to WooCommerce > Settings > Checkout and… um… check it out.

Simply uncheck that box, and, while you’re at it, uncheck “Force secure checkout” since it’s unnecessary on an all-SSL site, save your changes, and your home page should come back to live!

Internet Explorer and the centered background SVG problem

We are rapidly approaching, I believe, a time when we no longer need to worry about things that don’t work in Internet Explorer.

But we’re not there yet.

I’ve started using SVG images on the web a lot, especially for logos, which I tend to put into a flexible-width container at the top left corner of pages. Which is great, except IE has this annoying habit of resizing the canvas for SVGs to fill the container they’re in. The whole logo appears on the page, and scaled properly… but it’s horizontally centered in the container, rather than flush against the left edge.

There appear to be many possible solutions, but for a solution that is 100% fluid/responsive (that is, it will scale with the container), this does the trick.

It does involve manually editing the SVG code, but it’s simple and you only need to do it once as part of the image prep process. In the <svg> tag, look for the viewbox attribute. It will most likely consist of four numbers… 0 0 followed by the width and height of the canvas. After this attribute, simply add width="x" height="y" with the same x and y values from the viewbox attribute.

It works!

How to modify WooCommerce to prevent users from selecting UPS shipping for P.O. Box addresses

Anyone who’s dealt with e-commerce in any capacity probably knows that UPS won’t deliver to P.O. boxes. Well, technically they can’t deliver to P.O. boxes. And apparently they’ll forward packages on to the box owner’s physical address, but they charge a big extra fee to do it. So, you want to avoid it.

Unfortunately, WooCommerce and its UPS Shipping add-on do not account for this, and will accept UPS orders to P.O. box addresses. Not good.

The official WooCommerce developer documentation has an article on how to block P.O. box shipping, but it applies to all shippers. Not what we want.

Also, I’m not sure if the documentation is outdated or what, but their code sample didn’t work for me with the latest version (3.4.3) of WooCommerce, because of the wc_add_notice() function.

I’ve modified the original code to add a check for UPS shipping, and also to use the $errors variable. (I also considered removing the global $woocommerce; line since it seems unnecessary, but I didn’t take the time to test whether or not it’s definitely safe to remove, so I left it in.)

add_action('woocommerce_after_checkout_validation', function($data, $errors) {
  global $woocommerce;
  if (isset($data['shipping_method'][0]) && strpos($data['shipping_method'][0], 'ups') === 0) {
    $address1 = (isset($data['shipping_address_1'])) ? $data['shipping_address_1'] : $data['billing_address_1'];
    $address2 = (isset($data['shipping_address_2'])) ? $data['shipping_address_2'] : $data['billing_address_2'];

    $replace = array(” “, “.”, “,”);
    $address1 = strtolower(str_replace($replace, '', $address1));
    $address2 = strtolower(str_replace($replace, '', $address2));

    if (strstr($address1, 'pobox') || strstr($address2, 'pobox')) {
      $errors->add('shipping', __('Sorry, UPS cannot deliver to P.O. boxes. Please enter a street address or choose another shipping method.' . $datadump, 'woocommerce'));
    }
  }
}, 10, 2);

Important notes:

1. This code may not immediately work for you; I believe the 'ups' string in the conditional line may vary depending on your Shipping Classes settings, so you may need to investigate exactly what values are returned in $data['shipping_method']. Since this code is fired off by an AJAX call, it can be difficult to debug. I was able to crudely debug it by commenting out the conditional, then appending print_r($data) to the error string.

2. This is using an anonymous function, so it won’t work in PHP versions below 5.3. But you’re not using a PHP version that old, are you? ;)

3. The original version checked the address line 1 and the postcode field, rather than address lines 1 and 2. I’ve United States-ified my code because that’s what I needed. If you’re part of the other 95% of the world, you may need to add that back in, with appropriate adjustments to the nested conditional. (I’m not really sure if this issue is as UPS-specific outside the US, so my modifications may not be relevant.)

Getting Google to remove fake hack URLs from its indexes for your site

As a web developer/systems admin, dealing with a hacked site is one of the most annoying parts of the job. Partly that’s on principle… you just shouldn’t have to waste your time on it. But also because it can just be incredibly frustrating to track down and squash every vector of attack.

Google adds another layer of frustration when they start labeling your site with a “This site may be hacked” warning.

A lot of times, this is happening because the hack invented new URLs under your domain that Google indexed, and for various reasons, Google may not remove these pages from its index after it crawls your thoroughly-cleaned site, even though those URLs are no longer there and are not in your sitemap.xml file. This issue may be exacerbated by the way your site handles redirecting users when they request a non-existent URL. Be sure your site is returning a 404 error in those cases… but even a 404 error may not be enough to deter Google from keeping a URL indexed, because the 404 might be temporary.

410 Gone

Enter the 410 Gone HTTP status. It differs from 404 in one key way. 404 says, “What you’re looking for isn’t here.” 410 says, “What you’re looking for isn’t here and never will be again, so stop trying!”

Or, to put it another way…

A quick way to find (some of) the pages on your site that Google has indexed is to head on over to Google (uh, yeah, like you need me to provide a link) and just do an empty site search, like this:

site:blog.room34.com

Look for anything that doesn’t belong. And if you find some things, make note of their URLs.

A better way of doing this is using Google Search Console. If you run a website, you really need to set yourself up on Google Search Console. Just go do it now. I’ll wait.

OK, welcome back.

Google Search Console lets you see URLs that it has indexed. It also provides helpful notifications, so if Google finds your site has been hacked, it will let you know, and even provide you with (some of) the affected URLs.

Now, look for patterns in those URLs.

Why look for patterns? To make the next step easier. You’re going to edit your site’s .htaccess file (assuming you’re using Apache, anyway… sorry I’m not 1337 enough for nginx), and set up rewrite rules to return a 410 status for these nasty, nasty URLs. And you don’t want to create a rule for every URL if you can avoid it.

When I had to deal with this recently, the pattern I noticed was that the affected URLs all had a query string, and each query string started with a key that was one of two things: either a 3-digit hexadecimal number, or the string SPID. With that observation in hand, I was able to construct the following code to insert into the .htaccess file:

# Force remove hacked URLs from Google
RewriteCond %{QUERY_STRING} ^([0-9a-f]{3})=
RewriteRule (.*) – [L,R=410]
RewriteCond %{QUERY_STRING} ^SPID=
RewriteRule (.*) – [L,R=410]

Astute observers (such as me, right now, looking back on my own handiwork from two months ago) may notice that these could possibly be combined into one. I think that’s true, but I also seem to recall that regular expressions work a bit differently in this context than I am accustomed to, so I kept it simple by… um… keeping it more complicated.

The first RewriteCond matches any query string that begins with a key consisting of a 3-digit hex number. The second matches any query string that begins with a key of SPID. Either way, the response is a 410 Gone status, and no content.

Make that change, then try to cajole Google into recrawling your site. (In my case it took multiple requests over several days before they actually recrawled, even though they’re “supposed” to do it every 48-72 hours.)

Good luck!