Last week I created a Hugo theme called Sawmill, designed to work with a new field type in Forestry.io’s CMS called Blocks. The purpose of the Blocks field type is to make it possible for content creators to build page sections (or even whole pages) out of simple components. Sawmill’s single.html template reads the front matter provided by a Forestry Blocks field, and the two work together to create a page-builder sort of system.
Check out the blog post I wrote to learn about the decisions that led us to pursuing this strategy, and for some info on how Sawmill works. You can also get started with it right away by clicking the button in the blog post, which will import a starter Hugo site pre-configured with Sawmill into your Forestry dashboard.
I think we’re a few people heading in this direction of independant blocks/widgets that can be reused across pages/websites. However your frontmatter integration is a really clever way to tackle this problem.
My main concern is that we end up all developing our own blocks and they won’t interoperate properly. Would you be ready to work on standardizing the interface to these blocks?
This way we can all have our own implementations for banners, site cards, galleries and such but share a common interface to integrate with either the frontmatter or directly in our Hugo templates. And we could switch from a theme to the other without having to rewrite everything… What do you think?
I love the idea of interoperability. My original approach to Sawmill was to make a boilerplate instead of a theme, with minimal styles that would allow the provided components to work with a variety of themes. This turned out to be an interesting challenge, but the end result didn’t quite have the polish I was looking for.
However, I have no idea where to start with such a thing! I’m all for pursuing a standard but [insert relevant xkcd here]. If you have any ideas on this, I’m all ears!
I’ve posted previously (Theme Standardization Through “Feature” Support) about the possibility that Hugo could create space/scaffolding for community-contributed theme tests (and probably the first few examples), which users can use to evaluate their site, developers can use to evaluate their themes, and the theme site could use to communicate (and cross-link) themes that pass the same feature test.
It’d be more chaotic than an One Interface to Rule Them All, but it’d let us haggle towards a standard definition of a given feature (even those of us not directly developing themes, since we can still contribute and advocate for improvements to a feature test that will nudge the ecosystem in the right direction.