How I built my first Shopify theme from scratch as a certified partner
Developing private themes for Shopify isn’t that difficult, but you may encounter unexpected issues
I spent the latest three working weeks to develop a full-featured Shopify theme for a customer — and it was harder than I’ve ever thought. I passed three out of four Partner Academy certifications in the last months: it has been a great opportunity to understand how Shopify works and how-to build something with its platform. Anyway, being ready for production requires more than a certificate to actually deal with third-parties projects… especially if customers don’t come from the ICT sector. Here’s how I achieved the goal.
First of, I’m working for a local startup (although this project took me back to the days of freelancing) as a front-end developer. We adopted an Agile/Scrum methodology with week-long sprints: shorter than usual. My CEO and I tried to apply the same framework to this consultancy, and I had three weeks to do the job. Being a mobile-first business, we agreed to spend the first sprint on the mobile version of the e-Commerce theme. I’ll had had to build the desktop version in the second to be ready for production in the third.
It’s usually an ideal planning for these kinds of works, assuming you have all the things you need to complete your tasks. Unfortunately, I didn’t. Let me say that build a Shopify private theme from scratch for the first time is challenging per se: I met Liquid “playing” with Jekyll on GitHub Pages some years ago, but I wasn’t ready to apply what I’d learned yet. Of course, building a developer blog is far less difficult than building a complete e-Commerce site with hundreds of actual customers. That’s why I’ve never build one… before.
So, make sure to have all that you’ll need for a realistic planning. This kind of project needs at least a product manager, a designer and a front-end developer: if you’re a freelancer, you should be ready to play each role. Customers often don’t know anything about web developing and have absurd expectations! In my case, neither the designer I work with knew how-to deal with Shopify’s policy. He sketched a full checkout process I couldn’t reproduce, for example, because the platform reserves it only for Shopify Plus subscribers — honestly, it was pretty hard to explain this to our customer.
If you think that I’m going to show you some code here, you’ll be disappointed. Once you learn how to deal with the Liquid template system, coding is the last thing you have to take care of. Keep in mind that I’ve always avoided to develop e-Commerce projects before, because I thought that they are too dangerous from a legal point of view. That’s where Shopify comes in handy, taking care of the checkout process for you: unless your customer is a Shopify Plus subscriber, you don’t have to worry about
Speaking about the front-end development,
checkout.liquid is definitely the harder file to work on. It lets you to customize the entire checkout process from the beginning, overwriting the existing settings: anyway, it won’t work, unless your customer is a Shopify Plus subscriber! So, you can just edit the theme’s settings instead… once you have access to the customer store. Development stores from partners don’t allow its customization, then you can’t see how it works before trying an imported theme in a production stage.
Yes, it could be «a huge pain in the ass». PayPal Express Checkout can also be integrated in a
cart.liquid file, before being redirected to the actual checkout process, but you need a link to the customer PayPal account. You can’t mock it in a development sandbox without real credentials — excluding a non-functional, useless placeholder. This is one of the tons of advices I can give about building a Shopify theme from scratch you may have missed, even if you got certified like me. The marketplace documentation is actually huge.
Let’s speak about styling. Shopify (oh… yes, please) supports the Sass/SCSS syntax. But it doesn’t allow you to use
@import to create a main file, then a series of imported partials: basically, you need to put all of your declarations in the same document. My first
theme.scss.liquid have more than three thousand lines of code — which isn’t good at all. Of course, you can always add single stylesheets to the head of your
theme.liquid file. It’s far from being a best practice! And there’s a well-known reason to do so by Shopify.
On its side, importing external files could be a serious security issue. Assets from the same domain shouldn’t, but we’re speaking about an e-Commerce platform: you wouldn’t be glad if your money disappeared for a f*cking stylesheet! That said, from a developer point of view, these limitations matter. I had to adapt my company’s coding styles to fit the Shopify policy on SCSS and I’m not 100% satisfied with the performances. BTW, I like how it manages static image files… solving lots of sizing and memory problems.
Nesting classes is great, but you can’t use a BEM naming specification as I use to do elsewhere. Children starting with special characters will be warned as errors and escaped: let’s say that I have a
.shop main class with a
.shop__header child, or a more generic
--is-desktop modifier, then I must specify different containers for each in Shopify. You can’t nest them under a single pair of brackets, just saying. This is a bad indentation caused by an outdated Sass/SCSS version; I can’t figure out why it could be a security issue.
I’m not a great jQuery fan, neither a hater. It’s just for security: to date, I don’t really understand why Sass/SCSS could be so dangerous for the platform and it couldn’t. I mean, someone at Shopify should reconsider these choices. Right now, I chose to write my scripts from scratch as well and I found easier to embed them directly on the template file, than putting them in the default
theme.js file. Some simply didn’t work elsewhere… and it was a bit hard to understand why, being an e-Commerce theme, in an e-Commerce platform.
If you’re asking, what I liked most is that Shopify makes use of Gulp.js as a task runner to achieve some goals and it provides plugins to interact with. Starting with a huge stylesheet, choosing a third party optimizer sounded good. I didn’t need to use either Babel or TypeScript, but it’s definitely an option: to be honest, I made use of some ECMAScript 6 features I should fix as soon as possibile for being backword-compatible too or I can get errors on older browsers versions. You know, I’m in ❤️ with ES6 and I often forget it.
I don’t understand why Shopify declared the end of support for Slate 1.x in January, 2020: I built my first theme with Theme Kit instead, working on a fake development store. Well, it doesn’t really work as you’re on a real store… since it lacks some functionalities like custom payment platforms (although you can always emulate a full checkout process), but I found it useful enough to achieve the goal. Making your templates even more dynamic requires time and experience, though; I’m still discovering new awesome features to add.