Hey, Scott Austin here.

In this episode, I'll give you the tips and tricks that I've learned in using Online Store 2.0 since it launched in Summer 2021. And for the rest of this podcast, I'll refer to Online Store 2.0 as OS2.0.

As any regular listener will know, I typically use the Flex theme when building or redesigning a store. That hasn't changed in OS2.0. Flex is still my go to theme, and even more so now. And I've been using the OS2.0 version of Flex on my projects since it came out around last October. So I've used OS2.0 enough now that I've developed a number of best practices that I can share with you. So let's dig in.

A. My first best practice is that you should use an OS2.0 theme on any new store or redesign. I think this is pretty obvious and I haven't heard of any one not doing this, but I thought I'd mention it just in case. OS2.0 makes it much easier to build and maintain your store. I enjoy working in it much more than my legacy stores and I've quickly become accustomed to all of the new features and conveniences.

B. One of the things that I've grown to appreciate over time is the benefits of JSON templates over liquid templates. JSON is the preferred template structure in OS2.0 where was previously Liquid. In a JSON template, the content and settings that you add and set in Theme Customization get stored in the JSON file. Before OS2.0, all the theme customization was stored in a single file called settings_data.json. That file is still used for liquid templates, just not JSON templates. And this has a number of advantages. The first is that the settings_data.json file size is decreased. And that's a good thing as that file is used to render every page. And by page in this instance, I mean all of the Shopify content types like page, product, collection and article. Another benefit is that now the structure and the content of a page are stored in one file if the template is JSON. That makes it easier to copy an entire page in your store. Let's say you want to add a new landing page for to your store for a new ad campaign. You can copy the full JSON from an existing landing page template and create a new JSON template with it. That way, the new landing page starts with all the sections, settings and content from the source template. Store staff can then edit from that more complete starting point saving a lot of data entry. For many stores that I build, I create a series of landing pages for the various holidays that are appropriate for the business, like Valentine's Day, Mother's Day, Graduation, etc. So in OS2.0, what I do is build out a complete landing page for one of the holidays. Once that is done, I create new JSON templates for all of the other holidays and copy and paste the full JSON code from the prototype holiday. Then all of my new landing pages have all of the structure and most of the content that I need. To finish the new holiday pages I just edit each one changing images and copy from Valentine's Day to Mother's Day for example as needed.

C. There is a drawback to JSON templates. And that is that in a JSON template you can't have liquid code. The JSON files just brings in sections and holds the content settings for the sections. Here's an example where that becomes an issue. Before OS2.0, I would make a template in liquid that would restrict access to a page based on the customer having a certain tag in their account or not. The template would need to present different content for these three different states:

1. When the customer is not logged in.
2. When the customer is logged in but does not have the required tag.
3. When the customer is logged in and does have the required tag.

With Liquid code, we can easily check for these conditions and present the right content.

In OS2.0, we can't have liquid in the template file. Here are a couple of alternative solutions.

1. Use a liquid template. In OS2.0, templates do not have to be JSON. They can be JSON or Liquid. So we could still make a liquid template and check for the different states like we would before OS2.0. The downside of this solution is that a liquid template doesn't benefit from OS2.0's sections anywhere feature. So we won't be able to add or move sections in the liquid template from within Theme Customization.
2. Alternatively, we can still use JSON templates and keep the sections anywhere feature. But we'll need to move the Liquid conditions for checking the customer states elsewhere. In a recent store design that I did restricting access to certain pages, I moved the state detection to the header navigation menu. I created 3 unique pages with unique JSON templates. Then I changed which navigation menu got displayed based on which state the customer was in.

D. In OS2.0, we have a new section type and that is called Custom Liquid. This is a powerful new tool as we can now bring Liquid logic or Shopify data elements into theme customization. Here's one example of how I use the Custom Liquid section in each store I build. I'm not a fan of how the store policies look in the standard policy template in the Flex theme. So I create a page for each of the policies with their own JSON template. Then, in theme customizations, I add whatever standard elements that store uses with things like banner images or email sign-ups. I also add a Custom Liquid section. The liquid code I add is for each policy. For example, the liquid code for the Privacy Policy is {{ shop.privacy_policy }}. And the result is a much better looking policy page that supports the brand and site consistency.

E. In OS2.0, I find myself re-using custom sections much more across stores. In most store builds that I do, I create custom sections to extend the theme's capabilities or to build a bespoke experience to map to a store's uniqueness. And the reason that I'm reusing them much more is that sections can now be atomic and built to work entirely on their own. Pre-OS2.0, sections could not be atomic. At the very least, you would need to edit the template of the page that you wanted to add the section to to include that section. To make the section atomic and reusable, I do the following:

Here are some examples of reusable sections that I've built and re-use across stores:

1. Klaviyo sign-up form
2. Promote a product or products in a blog article.
3. Promote product bundles on the product page for bundles that a product is in.
4. Flexible content accordions.
5. Cross-sell for the cart
6. Brand guidelines
7. Site messages
8. Cart messages
9. A section that adds Image with Text as blocks so they can all be controlled with a common set of settings.
10. Dynamic call-to-action buttons for landing pages.
11. Display all of the store's product photos with data about the photos in order to evaluate if the photos conform to brand standards.

F. As you are building re-useable sections, you can also specify what page type they can appear on. Adding this setting is helpful in reducing clutter in the theme customization experience. For example, if you build a section that only works on article pages, you don't want it to appear as an option for product pages or the homepage. To add this restriction to a section, you just add a 'templates' setting under the schema and specify which types templates this section is eligible for. Options include: Cart, Article, Page, Product, Collection and Index.

G. Control over apps has improved in OS2.0. In the past, apps could inject their code into your theme and impact the customer experience. OS2.0 compatible themes give you more control with what's called App embeds. App embeds allow app developers to create atomic additions to the theme and you get to control whether to use them or not. App embeds can be found in Online Store > Themes > Theme Customization > Theme Settings > App embeds. I encourage you to go to your store and see what Apps can be controlled under app embeds and to decide if you want each of them to be on or off.

H. Metafields are much improved in OS2.0. I have always used metafields to enrich the structure and content of a store's data. But pre-OS2.0, you had to be a developer that was comfortable editing liquid code to use metafields. In OS2.0, all stores can access the power of metafields without editing code. In the store settings, you can create metafield definitions that you can pin to the product page so that store staff can easily edit the metafield value for a product. Metafields are good to store common data about your products. For example, in Authentic Vintage Posters, I created metafields for the year a poster was printed and the size of the poster. Then I edited the product template to display the data in a consistent way on the product page. And I also used liquid to manipulate the metafield data. I calculated how old the poster was based on the printed date and showed both. I also converted the dimensions from inches to centimeters and showed the size in both units. Many stores can benefit from creating and using metafields to help improve the structure of their product data.

I. Another advancement in metafields in OS2.0 is that we can connect a metafield to a section element inside of theme customization. This allows us to use a template over and over again and still have different content between products. For example, let's say that a store is selling food and that this food store wants to show the nutrition label for each product on the product page. Well, we can create a product template and add a section to display the image for the nutrition label. Without metafields, we would have to create a unique JSON template for each product, assign the template to the product and then customize the template with the nutrition label image to use. But with metafields, we use one product template. We define a product metafield of the type file to store the nutrition label's url. Then in theme customization we connect the section that shows the image to the metafield that says which image ulr to show. This is called metafields and dynamic sources and saves us a lot of time in wiring everything up. We can connect more than metafields to a theme element. Some of the other dynamic properties that can be used are the data elements that you see in the Shopify Admin. For products that includes data like product title, product type, etc.

The connecting of theme elements to data elements is done with theme customization. Within in a section, you'll see an icon next to some inputs that looks like 3 stacked discs with a plus symbol next to it. Click on the icon and you will see a list of what data elements you can connect to the section element. Metafields must have a definition for them to show up on this list. To create a metafield definition go to Settings > Metafields.

One thing you'll need to think about here is what to do in the case of products that don't have the metafield. What if the food store also sells a branded hat. Well the hat doesn't have a nutrition label so the nutrition label metafield will be blank. Most theme's don't have any logic for what to do if the data source is blank. Here are a couple of options for you:

1. Have two different templates. One template for products that do have the metafield and another template for the products that do not.
2. Add logic to the liquid for the sections that allows for a state where the metafield is blank. This one is more complex than the first option as you would need to be comfortable editing code.

J. With all these tools its even more important to plan out and document your product taxonomy. Properly planning for what product data you want to show customers and how you are going to store and display that information will make the implementation that much easier. And documenting the taxonomy will help future staff members understand the data model so they can also implement it.
K. Lastly. Don't upgrade your existing Shopify store just for these features. While OS2.0 is easier to build and maintain, a theme migration from a OS1.0 to OS2.0 theme is a complex project. I recommend to not do it if the only gain is the OS2.0 features. I recommend holding off until there other business priorities that are pushing for the change, like implementing new branding or changing the shopping paradigm. In other words, if ain't broke, don't fix it. There are plenty of other things you can work on that will move the needle more.

Well, that's my list of OS2.0 best practices. I hope some of these are helpful for you.

Thanks for listening.