Shopify, ShipStation, and Stamps.com

When we launched the DIY Stitch People Book back in October, we didn’t realize how quickly it would gain traction. Thanks to an active Pinterest crowd, some Facebook ads, and a natural rise in organic search traffic, we’re selling more books than we expected. And as you might expect from two people who have never run a business that consistently ships physical products (sporadic portrait orders don’t count), we found ourselves in need of a better way to manage the shipping/fulfillment aspect of Stitch People.

A typical day at our house

A typical day at our house

We’re avid podcast listeners, so we’ve heard a lot about Stamps.com recently. We signed up for an account and started printing postage at home. It was a pretty slick process and a major improvement over going down to the post office to ship books, but it still didn’t tie in directly with our Shopify store. I kept searching.

I thought I had a solution when I found the Stamps.com Shopify app. I went down that rabbit hole and eventually learned that unless you’re running the Windows client of Stamps.com, there’s no way to integrate it into Shopify. As a Mac user, I was out of luck.

Next I called Stamps.com support and asked if there was anything else I could try. The guy referred me to ShipStation, a company Stamps.com recently acquired. They had a way to integrate Shopify and Stamps.com without using the Windows client, he said. And it turns out he was right.

Ship Station

ShipStation is perfect for us. We can log in to ShipStation, see the latest orders, print labels according to a preset we configured (Media Mail, 13 ounces, etc.), and the tracking numbers are immediately populated into Shopify, the order is fulfilled, and the customer gets the regular Shopify email with the tracking number. And we never had to login to Shopify.

Check out ShipStation here.

Showing multiple currencies in Shopify

We’ve been getting a lot of emails lately from people asking what the DIY Stitch People book costs in their currency (GBP, AUD, etc). We normally just head to Google, grab the latest exchange, and reply to the email with the result. Today I decided to fix that process.

After some searching, I found the article I needed: Showing multiple currencies in a drop-down list on your storefront

It’s pretty straightforward if you know what you’re doing with Shopify theme files. If you follow the instructions in that article, you’ll end up with a currency dropdown in your header. I didn’t love the placement, so I took it a step further and put the currency dropdown right next to the display price:

Screen Shot 2015-02-10 at 7.41.50 PM

To get this, you just need to tweak where you’re including the snippet. To get it in the header, the article asks you to put it in theme.liquid. I instead put it on the product page, product.liquid, below the price (and outside of the span that contains the price):

Then I just added some CSS (style.css.liquid) to get the dropdown sitting next to the price (but not too close):

The result gave me that currency dropdown box right next to price, which I think is much more visible than having it buried in the header.

Caching in WordPress

I’ve been learning a lot about caching in WordPress lately and thought I’d share a few things I’ve learned (and document them for myself).

Why Cache?

Caching is a common technique used to speed up your experience on the Internet. The general idea is that instead of requesting resources (images, files, etc.) directly from the source, you instead request them from a cache, which is generally faster. In the case of WordPress, each time you request a page, the server has to process a bunch of PHP and come up with the HTML to render. Depending on your site, this processing can be pretty resource intensive, making you wait an extra second or two for the page to load.

Caching speeds up that PHP processing by caching the result(s) for future use. Let’s say you have a sidebar widget that displays the most recent posts. Without cache, each time a page was loaded, WordPress would have to query the database and find the three most recent posts. This is inefficient since this list likely doesn’t change between every page load. With cache, the first time this list is generated, it makes sense to put it in cache so that next time someone needs the list of most recent posts, it doesn’t have to query the database–instead, it just pulls it directly from cache.

When the list of recent posts changes (i.e. you publish a new post) you can “bust” the cache and delete the old list. The next time a page is requested, it’ll query the database, get the new list, and put in the cache for any future requests.

Now for the WordPress specific implementations of cache:

WP Object Cache

The object cache does just that–caches objects. It does this by using key/value pairs, with an optional group (for namespacing purposes) and expiration date. By default, however, this cache is not persisted–it lives for the duration of the request only. The WP documentation says that if you need to guarantee that something is cached, use the Transients API instead.

The Transients API

Transients are also cached objects using key/value pairs, like the Object Cache, but with two major differences:

  1. They are persisted in the wp_options table by default (Object Cache isn’t persisted by default), and
  2. They require an expiration date (which is optional for Object Cache)

Transients are better suited for information that you know will expire.

Persistent Cache

If you have a persistent cache plugin enabled and configured, then it changes the behavior of both the Transients API and the WP Object Cache. Most notably: with persistent caching enabled, the Transients API will use the WP Object Cache methods and store to persistent cache instead of saving to the wp_options table. These two caching methods are essentially combined into one and stored in persistent cache.

For example, calling this method:

will actually do this:

The object cache group is automatically set to ‘transient’ when using the Transients API with persistent cache.

How Persistent Cache Works

The way persistent cache works is pretty simple. When persistent cache is configured, each request that would normally go to the database will first check the cache. If nothing is found in cache, then the request continues on to the database. Once the request gets a response from the database, it puts that response in cache for future requests.

With persistent caching enabled, if the requested object is cached, the database is never touched.

Persistent Cache Plugins for WordPress

There are several WordPress plugins that offer persistent caching. You might be familiar with a few of the major players, like W3 Total Cache or WP Super Cache. I’m not going to go into detail on the pros and cons of the plugins here–there are plenty of blog posts out there that address this. Any plugin that deals with caching is going to take some configuration, so expect that upfront.