Using Shopify Inside of Wordpress

This is the first post in what I’m hoping will be a three part series discussing Shopify development. In this post, I discuss our initial experience with the platform using the API and JS Buy SDK. In the next post I’ll be discussing Liquid theme development. If you have any questions or corrections, just let me know in the comments.

My team and I recently finished building a site for one of our clients and because we learned so much building it, I thought we should share some insight into some of the decisions we made.

We had a few requirements. First, we needed a CMS, and seeing as Wordpress is our preferred CMS at the moment, that was a given. So we knew we were building a Wordpress theme, at least for the marketing side of things. Second, we knew we needed to build a store, so we wanted to use a popular framework of some kind that we knew we could trust. Our options were quickly whittled down to either Woo Commerce — the popular Wordpress ecommerce plugin, or Shopify, Canada’s ecommerce powerhouse. We ended up choosing Shopify for the following reasons:

• Our client had already purchased a Shopify account (though we weren’t held to that by any means)
• We already had multiple clients ask us about Shopify, and we had never built anything in Shopify before, so this would give us an opportunity to check it out.
• Shopify has the ability to tie into POS systems. This is something you should strongly consider and that I’ll talk a little more about later.
• Lastly, Shopify has a great reputation, particularly here in Canada. A lot of our friends work for Shopify and we want to see it succeed.

So we chose Shopify, but rather than build a Shopify theme, we decided to integrate the Shopify API and JS Buy SDK into our Wordpress theme. We decided on this approach after thinking through a few things:

For starters, as I’m sure many of you know, Shopify themes are built using their own custom programming language, “Liquid.” Myself, nor any of the developers on my team, were familiar with Liquid, so immediately, we knew that there would be a learning curve getting to know the language. That’s ok though. We were prepared for that (we’re developers, after all). However, designing and building a Liquid theme would also mean supporting two independent code bases — one for our Wordpress theme and another for the Shopify theme. We knew we wanted the store to integrate seamlessly with the rest of the site (use the same header, navigation, icons, colors, etc.), so managing two code bases that shared styles and content would be a pain, particularly when some of that content is dynamic. If we had wanted the store to use a different layout and look different entirely, then we likely would have just developed a Shopify theme in Liquid, but, as I mentioned, integrating the store into the rest of the site was important to us, so we started to think about how we could achieve that.

We knew we wanted the store to integrate seamlessly with the rest of the site, so managing two code bases that shared styles and content would be a pain…

One possible solution to using shared resources across both themes might be to use Git submodules. In theory, we thought that you may be able to have a submodule or multiple submodules that contain only your shared resources (styles, fonts, icons etc.) and then include that in both theme repositories. This would allow you to make an update in one place and have it reflected in both your Shopify and Wordpress themes. Unfortunately, during our discovery phase, we tried out Shopify’s skeleton theme with a development store, but one thing we didn’t understand (and still don’t) was how to develop a Shopify theme using Git. We learned that Shopify themes have their own workflow. You actually need to download and run an app locally that syncs your local theme with a theme on the Shopify server, or as we’ve more recently learned, an officially released CMD line tool. The syncing with the app was done in real time as you edit your theme files, so being able to have multiple people work on the same theme, using our usual workflow of Git branches and code reviews, seemed complicated and difficult, if not down right impossible.

As much as we wanted to explore Shopify theme development, the idea of duplicating our theme styles and content to mirror our Wordpress site and the lack of understanding in using Shopify with Git lead us to explore the API and Buy SDK as an alternative. To start, we made a few simple requests to the Shopify API and very quickly we were able to see products displayed in our Wordpress template. This gave us hope. We knew that displaying Shopify products in our Wordpress site was easy. But could you actually purchase a product? I mean, what good is an online store if you can’t buy anything! We looked over the API docs but didn’t see anything about transactions, or rather, there was a transaction object, but it was only used to get or set previously authorized transactions, not new ones. In other words, as far as we could tell, you couldn’t use the API to actually make a new purchase. This is something we thought was quite strange, seeing as we had just built a project using Stripe’s API where the transaction was an API call, but we had yet to explore the Buy SDK, so we knew we were missing something.

We spent the next month and a half building out the Wordpress theme and adding all of our API calls to bring in products and collections and the ability to search them. The site was a single code base, using our preferred CMS, where every piece of content was editable from our dashboard, and we had our client’s Shopify products being displayed in our store. Great. It was now time to deal with the cart and checkout. Enter the Buy SDK.

With a 90% certainty that the Buy SDK would solve our whole not-being-able-to-actually-purchase-anything-in-our-store issue, we forged ahead. Thankfully, the Buy SDK delivered as promised! But not without a few bumps along the way.

Shopify offers a great example of how to use their Buy SDK and implement a shopping cart on your site, so this is where we started. However, that may have been a mistake. While the example proved helpful as reference, it actually confused us quite a bit, and after wrestling with it for a day or so, we abandoned the example code entirely, went back to the docs, and wrote a lot of it from scratch. Our cart.js file ended up being much leaner and easier to understand. The lesson here, I guess, is that while code examples can be great starting points, it’s just too easy to get caught up in the details of it, when those details may not even be pertinent to your project. Focus on your use case and don’t lose sight of it!

Another thing we struggled with was the Shopify docs. For the most part, the docs are well organized, concise and easy to follow, but there are some pretty major flaws with them too, most notably the inconsistency in the language they use. On one page, a collection will be referred to as a collection, but on the next page, they may call it a “category.” Then on a different page, a “tag” may be referred to as a “category.” The truth of it is that Shopify doesn’t have any “categories” at all. In fact, you won’t find the word “category” anywhere in their actual system, but you will see it in the docs. This kind of inconsistency in language hit a breaking point for us when we found that the docs for the Buy SDK continuously referred to an “API key” that was required to initialize the cart. Shopify issues you an API key for your “app,” which is what we had already been using and, logically, what we thought the docs was referring to. In practice, however, the Buy SDK does not require the API key at all, but rather, something completely different that Shopify calls an “access token” — something that is generated by creating an “extension” on one of your sales channels (i.e. the Buy Button). You can learn more about that here.

…the docs are well organized, concise and easy to follow, but there are some pretty major flaws with them too, most notably the inconsistency in the language they use.

Anyway, all said and done, the docs were manageable and more importantly, our solution using Wordpress, the Shopify API and JS Buy SDK worked out. To conclude, I’d like to point out a few things specifically that we learned about the Shopify platform that we would have liked to have known before going into the project:

• Strangely, the Shopify API does not include the Menu object. Shopify uses menus much like Wordpress, where the user can drag and drop items into their navigation and order the items in some kind of hierarchy. Having the menu object accessible from the API would have been ideal.
• If your store doesn’t require a cart, there is another solution available to you — the Shopify buy button. Basically, the buy button is just some code that you can stick on your site that opens up a new window and allows you to purchase a product without leaving your site (no API or SDK required). Using this buy button, Shopify has recently created a Wordpress plugin for you that works very similar to the native “Add Media” button, where instead, you “Add Product” to your post, but you don’t actually need it if you’re a theme developer — only the code it generates, which we used in conjunction with the API to populate the required data attributes. If we didn’t need the cart, this is the approach we would have taken.

Here is the what the code for the Buy Button looks like:

<div data-embed_type="product" data-shop="embeds.myshopify.com" data-product_name="YELLOW WATCHES" data-product_handle="yello-w" data-has_image="true" data-display_size="compact" data-redirect_to="checkout" data-buy_button_text="Buy now" data-buy_button_out_of_stock_text="Out of Stock" data-buy_button_product_unavailable_text="Unavailable" data-button_background_color="30373b" data-button_text_color="ffffff" data-background_color="f1f1e9" data-product_modal="false" data-product_title_color="000000" data-next_page_button_text="Next page"></div>
<script type="text/javascript">
document.getElementById('ShopifyEmbedScript') || document.write('<script type="text/javascript" src="https://widgets.shopifyapps.com/assets/widgets/embed/client.js" id="ShopifyEmbedScript"><\/script>');
</script>
<noscript><a href="https://embeds.myshopify.com/cart/8829753283:1" target="_blank">Buy YELLOW WATCHES</a></noscript>

• Shopify offers something called smart collections — buckets that automatically bring in products that match a certain set of rules. The relationship between the collection and rules it imposes is basically your category system. So for instance, you could have a collection called “Summer” and include products that are tagged with “Shorts,” “T-Shirts,” and “Tank Tops.” Summer is your top level “category,” and shorts, t-shirts and tank tops are your “sub categories.” To make things interesting, our client had requested a three level category system, which is something Shopify isn’t really setup to do (at least, not without using their Menu object!) but is something that we actually managed to hack together using the API and a piece of meta information on each product, the product type. It involved a series of expensive API calls and a lot of confusing, inception-like foreach statements, but we did actually get it to work. Unfortunately, the result was much too slow for our liking (even after caching our requests using Wordpress transients), and after some vigorous testing we eventually conceded to using the basic two level category system that Shopify intended (collection > tags). It just wasn’t worth it.
• Shopify allows you to search products using an API call, but you won’t see the word “search” anywhere, so don’t bother including it in your Google query. The way to search products is to use their Products endpoint with their “title” parameter, like this:

http://YOUR-API-KEY:YOUR-API-PASSWORD@YOUR-USERNAME.myshopify.com/admin/products?title=SEARCH-QUERY

• Like Wordpress, Shopify offers a plethora of free and paid plugins developed by third party developers. A lot of these plugins are written in Liquid and exclusive to Shopify themes though, so we wouldn’t be able to use them in our Wordpress site. This is something you need to accept if you’re going to use the API to build a store.

If we had a chance, would we have done things any differently? Honestly, for our business requirements, I don’t think so, but I do think that if our client was only selling products online and did not require integration with their in-store POS system, then I probably would have preferred to use Woo Commerce and Stripe , however, it is worth mentioning Woo Commerce has just recently released their own POS integration using Square. It would have allowed our client to avoid Shopify’s monthly fee and update all their content in a single place, rather than manage products separately in Shopify, and for our team, it would likely have just been a little more straight forward (though I am glad we finally got the chance to check out Shopify). Also, if we wanted our store to be independent from the regular marketing site, we likely would have built a separate Shopify theme in Liquid. Like I said though, for our use case, I think the Wordpress, API and JS Buy SDK worked the best. The POS integration and hardware they offer really is a deal breaker though. If you plan on integrating your online sales with a brick and mortar storefront (or have any plans to in the future), like our client did, Shopify is definitely the way to go.

I guess that’s it for this post. Did I get anything wrong about the Shopify platform? Or do you have something to add? Let me know in the comments.

In my next post, I hope to detail my first stab at developing a Liquid theme. It should be interesting to see how it will compare. Got any tips? Send them my way.