We’re picking up a Shopify site that was put on hold for a little bit, and I’m pleasantly surprised by a few things I’ve come across. The pause might have been blessing in disguise for the site on the whole. The dev tools have progressed a bit during the hiatus, and I’ve come across a Sections workaround that might 🤞 give a little more content flexibility beyond the homepage.
Slate replaced Timber in March
this last (whoops) year. It’s been pretty good so far, the documentation is miles better and it’s much more bare-bones in terms of styles.
Sections have been around since late 2016, but they’ve always been meant for use on the homepage. I’ve looked for workarounds in the past to include Sections on other pages, but everything I came across was too brittle / dubious / hacky / plugin-y for my taste. More recently, I found a how-to for page-template-specific Static Sections on oak.works, and on this thread. It seems relatively legit, with a few caveats.
TL;DR version of full tutorial
- Create a page template for pages that should include Sections.
- Create the section. The section filename should match the page template suffix.
- Define the desired blocks w/in the new section’s schema.
- Create new snippets to display each block. It’s best to match the snippet filename with the block type.
- At the top of the section file, loop through each block in the section and include the appropriate snippet.
The major caveat: this technique essentially ties a reusable aspect of the UI (a page template) to a non-resusable feature (a Static Section). Shopify’s note about Static Sections:
A section can be included in multiple templates, but there exists only one instance of that section. When a merchant changes the configuration of a static section in one place, that change will apply to all other places where the section is included.
This isn’t ideal because it’s not as flexible as it could (IMO should) be, and the content editor might not expect this behaviour. Because of the caveat, it’s best to define a super-specific template for this implementation (i.e.
page.contact.liquid) instead of something more generic that indicates reusability (i.e.
It does worry me a bit that this doesn’t seem to be explicitly documented anywhere officially, there’s a chance that support could be dropped or changed. I’m on the fence about it. On one hand it seems like a great option if the standard content WYSIWYG isn’t satisfying the requirements. On the other, still feels a little more fragile than I’d like. Will weigh it up over time.