Thank you for the video, it was really great! The way you explain things thoroughly and efficiently is incredible. My only question is, at the 11:00 mark, you use the shortcut ';psjo' to auto-populate the JSON template. What extension is that?
Let's say you are doing this for a single page like an about page. I can set up the template for the page to have editable content sections for my users. They will make content edits in production, but will I get those changes in my git commit history? If I need to pull changes down to a branch and work on some things on that about page and preview my changes on a separate staging theme, will I get the production content ported into it or will I just have the staging theme content?
@@jaimegalvan1972 so I developed on the 2.0 theme and I figured out the content is API based meaning that you won't be able to track changes in content. However you can make changes on the local instance of content and it will stay on local until you push it up as well as pull down content changes in production into local. I've been working with API based CMS lately and I haven't run into issues of content changes breaking deploys and I believe Shopify has built a pretty foolproof UI so you shouldn't have to worry about content crashing the site.
@@edcupaioli8167 So if you pull your latest commit from github (your own version of page.json), the page.json that is on live (where merchant added a section), it auto updates even after you deploy your own version of page.json?
@@edcupaioli8167 Also, you get why I'm confused right? basically with Shopify CLI you pull from the live theme and then you pull from GitHub. 2 pulls and then fix the code? make it make sense please lol
@@jaimegalvan1972 So the content is stored in a database and your code is stored in github and the CLI mixes it together on your computer via some wizardry (I'm self-taught, not a comp-sci major lol). I worked with Sanity (an API based CMS) recently and they actually have versioning for the content (eg each save is tracked and stored so you can roll back, but you wont see it in git). But you can also do local content edits and then push them up to the API. Perhaps they're using local storage? Either way, you'll need to follow that work flow: pull from git, pull from shopify-cli, then start the local dev.
You are amazing!!! I've seriously spent HOURS searching for a tutorial like yours! THANK YOU!! Can you show how I would code a sidebar into my article page (and also into the blog list/grid page) so that I could put any sections into it? Similar to how you created JSON templates for Products and Blog, but it would be the sidebar so I could add an image, html code for ads, etc? Thank you!
Hello Liam, awesome tutorials, saved me time, however, quick question, how do I implement alternate themes layout for Debut with OS 2.0, unfortunately can't render the {% theme 'alternate' %} on json template
Thanks so much for the video - this is super helpful! I couldn't help but wonder what VS Code extensions you were using for autocompletion and creating that json snippet. 🤩
We have an issue with the 50 blocks limit. Since you cannot load a section inside a section, we cannot access all product_fields needed. Any solutions ?
That is an excessive amount of blocks to crame in one section on a product page, what's your use case. When you hit a limit like this it's time to step back and look at how things are being constructed before the problem gets even worse. These limites are just performance considerations for shopifys servers they are roadbumps that may indicate a fundamental business problem. Consider breaking apart the problem into blocks that are more composable or just used more than 1 section. An example of a composable block is the product price, you would not want 4 separate blocks for price, sale price, regular price, compare price, variants prices. You would want one block with well through through business logic that handles pricing display.
Is it just me, or you can't create root .json files in the online theme editor - e.g. just 'products.json' in the templates folder, it's always has to be suffixed with a name?
Ok but the cart object is also a json? And good luck putting a wrapper around them. If you start with dawn and you build and build upon to the cart. You all of a sudden notice you can't put a wrapper around it in order to make the main-cart-items and main-cart-footer in a wrapper. Oh my great stuff. Ya'll overcomplicate things.
Would you do the same for a custom templates that you can change in the product itself? I previously used minimal theme and now I moved over to Dawn. I had a custom template set up and in the product-template.liquid I had - {% if template contains 'custom-1' %} then all the code I wanted for the custom template below. I also had a template - product.custom-1. This template is only used for a few products that I custom make and I need that template so people can pick all their options without needing to email me and discuss the options.
Hi Kenzy - so there could be a few options for working with alternative/custom templates and the new templating model. The easiest option could be to use a specific JSON template for the products which are custom - and have different main product sections that correspond with each custom product. This would be the usual approach when you have a category of products which have different properties to your regular products. Alternatively, you could host all the code for different product types in a section file and instead of logic based on a templates name (or what it contains) you could create an if statement based on a products' tags instead. So your if statement could look something like {% if product.tags contains 'custom-1' %} and then all the code you need. Then you'd also need to ensure you've assigned the correct tags to each product. Hope this helps!
@@liamgriffin6897 I really appreciate all your help. I just found out I could add a custom template and those that were labeled custom.1 automatically got updated. Then I went to the custom template ( this is all in the customize website not edit code) and added all the old code in custom liquid and it worked! So I am thankful for that. There's a few things I don't understand in the new Dawn theme like how to add the klaviyo back in stock code but this tutorial definitely helped me start understanding the new 2.0. Also, what bugs me in dawn is that when making nested main menu the anchor doesn't link to "ALL" even with it set up in navigation that way.
I honestly don't understand the supposed advantage of being able to add sections to a page in the theme editor. Adding a section to one page adds the same section to ALL the pages that use that template, which is the same problem we've ALWAYS had with sections (I'm SO sick of article1.liquid, article2.liquid, article3.liquid, article4.liquid, etc; just so we can have unique content in our blog posts). Do we really want to give content editors the ability to easily jack up the layout for ALL your pages, blog posts, or product pages all at once? The layouts for pages on the site need to be coded in the templates, so that they can't be changed in the editor. I get that storing settings data directly in sections files gives a performance boost, but If we still have to code the layouts, what's the functional advantage to completely refactoring our sites into JSON templates?
Hi Boots, You do not have to refactor a site completely , theme developers do not have to use the JSON templates system exclusively for every resource. You can mix and match with vintage section-templates to suit needs among the resource types. So products could use JSON templates, but pages could use vintage templates or old behavior of building landing pages. To clarify something like products can't have both product.liquid and product.json (10:25 ). An advantage is metafield definitions(MFDFS) with the the new JSON template system used with dynamic fields. MFDFS are added to resources(products,pages,etc). So once a mfdfs are created and wired to a themes content settings with dynamic fields then content editors do not even have to have access to themes permissions at all. With large content needs the setting up of lots mfdfs can be a chore to setup and maintain to keep from becoming disorganized or confusing to use , so you'd want to map everything out in advance keys, descriptions; and good namespaces instead of the generic "my_fields" placeholder. Another advantage is custom-liquid sections|blocks being able to have their layout order quickly modified. There are caveats to realize about the different theme architectures tradeoffs : #1 JSON templates are DECLARATIVE with scoped sections(blackboxed). A) Meaning the JSON as a setting has no conditional logic within them so you can't detect a context to change settings in the JSON template itself. B) Sections are privately scoped so no message passing between sections(even with capture hacks) and taking point A into account means obviously no backfeeding into the the JSON template so one setting only affects that one setting; Such as one section detecting if another section is "enabled" in a JSON template to add a CSS modifier such as top margin or z-index,etc. So things like presentation logic has to be in the sections|snippets code. Whereas in vintage templates with static sections if you really need to for complicated content you could use capture hacks to propagate info up into the containing template making sections behave differently depending on what's going on in another sections context. #2 Missing content handling, i.e. empty mfdfs. With an off the shelf theme like dawn placeholders are automatically used. Even if a dynamic field is used if it's connect mfdf is empty then placeholder content may show. For example a custom video mfdf for collection-A is filled in but collection-B's it's left empty then a generic placeholder video may show. Not desirable for publishing when various resources could have empty mfdfs . So complicated theme|sections setups should account for the case when content or it's metafields are empty, or to only show placeholders while in the admins theme designer. You can use the routes.design_mode object to show onboarding to staff but hide empty sections content when published. #3 MFDFS are not first class data citizens so operating on them in bulk really needs an app for editing/exporting/import in bulk.
Yeah this seems stupid, totally missed making this an awesome update to being a more evolved version of the same problem as before! Not sure why you'd want to share page content across all pages - everything now has a custom template to have unique content, unless I'm missing something.
![I.N "HALLUCINATION" | [Stray Kids : SKZ-PLAYER]](http://i.ytimg.com/vi/n5B5q1Hwt_U/mqdefault.jpg)
Nice little tutorial, thanks for sharing Liam.
Thank you for the video, it was really great! The way you explain things thoroughly and efficiently is incredible. My only question is, at the 11:00 mark, you use the shortcut ';psjo' to auto-populate the JSON template. What extension is that?
Also, Liam + @ShopifyDevs, bumping this as I would LOVE if you shared the json you used for yours here! Totally understand if it's privileged info.
I am having the same catch XD..... seems it is self define after a tonnes of search....
Just what I was looking for! Thanks!
Wow, nice sign on the wall behind you...real professional.
LOL thank you - GSD is my motto :)
@@liamgriffin6897 that wasn’t a compliment, jackass.
Let's say you are doing this for a single page like an about page. I can set up the template for the page to have editable content sections for my users. They will make content edits in production, but will I get those changes in my git commit history? If I need to pull changes down to a branch and work on some things on that about page and preview my changes on a separate staging theme, will I get the production content ported into it or will I just have the staging theme content?
Million dollar question
@@jaimegalvan1972 so I developed on the 2.0 theme and I figured out the content is API based meaning that you won't be able to track changes in content. However you can make changes on the local instance of content and it will stay on local until you push it up as well as pull down content changes in production into local. I've been working with API based CMS lately and I haven't run into issues of content changes breaking deploys and I believe Shopify has built a pretty foolproof UI so you shouldn't have to worry about content crashing the site.
@@edcupaioli8167 So if you pull your latest commit from github (your own version of page.json), the page.json that is on live (where merchant added a section), it auto updates even after you deploy your own version of page.json?
@@edcupaioli8167 Also, you get why I'm confused right? basically with Shopify CLI you pull from the live theme and then you pull from GitHub. 2 pulls and then fix the code? make it make sense please lol
@@jaimegalvan1972 So the content is stored in a database and your code is stored in github and the CLI mixes it together on your computer via some wizardry (I'm self-taught, not a comp-sci major lol). I worked with Sanity (an API based CMS) recently and they actually have versioning for the content (eg each save is tracked and stored so you can roll back, but you wont see it in git). But you can also do local content edits and then push them up to the API. Perhaps they're using local storage? Either way, you'll need to follow that work flow: pull from git, pull from shopify-cli, then start the local dev.
Do you have anything on customizing buttons per page based on the content on that page?
I want to create a blog template. Can I do it this way? and How would i?
You are amazing!!! I've seriously spent HOURS searching for a tutorial like yours! THANK YOU!! Can you show how I would code a sidebar into my article page (and also into the blog list/grid page) so that I could put any sections into it? Similar to how you created JSON templates for Products and Blog, but it would be the sidebar so I could add an image, html code for ads, etc?
Thank you!
Hello Liam, awesome tutorials, saved me time, however, quick question, how do I implement alternate themes layout for Debut with OS 2.0, unfortunately can't render the {% theme 'alternate' %} on json template
Thanks so much for the video - this is super helpful! I couldn't help but wonder what VS Code extensions you were using for autocompletion and creating that json snippet. 🤩
We have an issue with the 50 blocks limit. Since you cannot load a section inside a section, we cannot access all product_fields needed. Any solutions ?
That is an excessive amount of blocks to crame in one section on a product page, what's your use case.
When you hit a limit like this it's time to step back and look at how things are being constructed before the problem gets even worse. These limites are just performance considerations for shopifys servers they are roadbumps that may indicate a fundamental business problem.
Consider breaking apart the problem into blocks that are more composable or just used more than 1 section.
An example of a composable block is the product price, you would not want 4 separate blocks for price, sale price, regular price, compare price, variants prices. You would want one block with well through through business logic that handles pricing display.
Is it just me, or you can't create root .json files in the online theme editor - e.g. just 'products.json' in the templates folder, it's always has to be suffixed with a name?
Ok but the cart object is also a json? And good luck putting a wrapper around them. If you start with dawn and you build and build upon to the cart. You all of a sudden notice you can't put a wrapper around it in order to make the main-cart-items and main-cart-footer in a wrapper. Oh my great stuff. Ya'll overcomplicate things.
Ended up fixing it with CSS, but it's far from charming.
Would you do the same for a custom templates that you can change in the product itself? I previously used minimal theme and now I moved over to Dawn. I had a custom template set up and in the product-template.liquid I had - {% if template contains 'custom-1' %} then all the code I wanted for the custom template below. I also had a template - product.custom-1. This template is only used for a few products that I custom make and I need that template so people can pick all their options without needing to email me and discuss the options.
Hi Kenzy - so there could be a few options for working with alternative/custom templates and the new templating model. The easiest option could be to use a specific JSON template for the products which are custom - and have different main product sections that correspond with each custom product. This would be the usual approach when you have a category of products which have different properties to your regular products. Alternatively, you could host all the code for different product types in a section file and instead of logic based on a templates name (or what it contains) you could create an if statement based on a products' tags instead. So your if statement could look something like {% if product.tags contains 'custom-1' %} and then all the code you need. Then you'd also need to ensure you've assigned the correct tags to each product. Hope this helps!
@@liamgriffin6897 I really appreciate all your help. I just found out I could add a custom template and those that were labeled custom.1 automatically got updated. Then I went to the custom template ( this is all in the customize website not edit code) and added all the old code in custom liquid and it worked! So I am thankful for that. There's a few things I don't understand in the new Dawn theme like how to add the klaviyo back in stock code but this tutorial definitely helped me start understanding the new 2.0. Also, what bugs me in dawn is that when making nested main menu the anchor doesn't link to "ALL" even with it set up in navigation that way.
I honestly don't understand the supposed advantage of being able to add sections to a page in the theme editor. Adding a section to one page adds the same section to ALL the pages that use that template, which is the same problem we've ALWAYS had with sections (I'm SO sick of article1.liquid, article2.liquid, article3.liquid, article4.liquid, etc; just so we can have unique content in our blog posts). Do we really want to give content editors the ability to easily jack up the layout for ALL your pages, blog posts, or product pages all at once? The layouts for pages on the site need to be coded in the templates, so that they can't be changed in the editor. I get that storing settings data directly in sections files gives a performance boost, but If we still have to code the layouts, what's the functional advantage to completely refactoring our sites into JSON templates?
Hi Boots, You do not have to refactor a site completely , theme developers do not have to use the JSON templates system exclusively for every resource. You can mix and match with vintage section-templates to suit needs among the resource types. So products could use JSON templates, but pages could use vintage templates or old behavior of building landing pages. To clarify something like products can't have both product.liquid and product.json (10:25 ).
An advantage is metafield definitions(MFDFS) with the the new JSON template system used with dynamic fields.
MFDFS are added to resources(products,pages,etc). So once a mfdfs are created and wired to a themes content settings with dynamic fields then content editors do not even have to have access to themes permissions at all.
With large content needs the setting up of lots mfdfs can be a chore to setup and maintain to keep from becoming disorganized or confusing to use , so you'd want to map everything out in advance keys, descriptions; and good namespaces instead of the generic "my_fields" placeholder.
Another advantage is custom-liquid sections|blocks being able to have their layout order quickly modified.
There are caveats to realize about the different theme architectures tradeoffs :
#1 JSON templates are DECLARATIVE with scoped sections(blackboxed). A) Meaning the JSON as a setting has no conditional logic within them so you can't detect a context to change settings in the JSON template itself. B) Sections are privately scoped so no message passing between sections(even with capture hacks) and taking point A into account means obviously no backfeeding into the the JSON template so one setting only affects that one setting; Such as one section detecting if another section is "enabled" in a JSON template to add a CSS modifier such as top margin or z-index,etc.
So things like presentation logic has to be in the sections|snippets code. Whereas in vintage templates with static sections if you really need to for complicated content you could use capture hacks to propagate info up into the containing template making sections behave differently depending on what's going on in another sections context.
#2 Missing content handling, i.e. empty mfdfs. With an off the shelf theme like dawn placeholders are automatically used. Even if a dynamic field is used if it's connect mfdf is empty then placeholder content may show.
For example a custom video mfdf for collection-A is filled in but collection-B's it's left empty then a generic placeholder video may show.
Not desirable for publishing when various resources could have empty mfdfs .
So complicated theme|sections setups should account for the case when content or it's metafields are empty, or to only show placeholders while in the admins theme designer. You can use the routes.design_mode object to show onboarding to staff but hide empty sections content when published.
#3 MFDFS are not first class data citizens so operating on them in bulk really needs an app for editing/exporting/import in bulk.
Yeah this seems stupid, totally missed making this an awesome update to being a more evolved version of the same problem as before! Not sure why you'd want to share page content across all pages - everything now has a custom template to have unique content, unless I'm missing something.
i fall asleep
Super confusing tutorial. Your documentation seriously lack REAL explanation!