sapwood

v1.1 Consolidates Page Types and Templates

Sapwood v1.1 was officially released today! It's the first official minor iteration over the initial public release.

Note: At the time of the release, Sapwood was technically named taproot but has since been renamed.

There was a lot of tinkering with options throughout this production. 70 commits later, we have adjusted the way page types and templates work, and are one minor step closer to improving the site-building workflow.

Page Types & Templates

Previously, page types and templates were separate concepts. The page type defined the fields of the pages created from it, while the template defined the view file used in your code. The reasoning behind this was that there would be some templates that would share attributes (fields), but would need different markup.

v1.1 combines these ideas into one, which simplifies the code-writing process, but does make the content building process more complicated.

To learn more about how pages and templates work together with the current version of the code, visit this page.

Template Structuring Rules

To help drive the content structure of your site, there are a few new options for a template. The exciting new options are:

  • specifying the name of the view file used in your code
  • allowing pages to be created at the root level
  • limiting the number of pages created with a template

These rules dictate where pages can be created, and which templates they can be created with.

See this section in the docs for more information.

Developer Help

The process of providing you developer tools in the UI has begun! Both pages and templates have a Developer Help page which provide a snapshot of some of the dynamic logic for that page or template.

Publishing Fixes

Now, when you have something like this in your service object:

def articles
  @site.templates.find_by_slug('article').pages
end

What you get in response are all the public pages with the Article template. In other words, pages in draft mode are not available to the public.

Consolidating Content Delivery

This is a major alteration to the Communicative Workflow. Instead of worrying about pulling live content down and working with it, v1.1 recommends you tie the two together and always work in production.

When you work in development, your local environment has access to every page, not just published pages. Therefore, you can build out new sections of your site using live data without affecting the live site.

This also means that uploaded files are shared between development and production, so long as your settings are consistent.

Rendering Pages Without a Layout

Sometimes you need to render a page without its layout (which usually means without its styles and javascripts). In other words, you end up with a plain HTML file representing the rendered output of the view file, based on the database content.


I hope you enjoy the feature enhancements in v1.1. This was a good iteration, but after some user testing v1.2 is going to dig much deeper into working with pages and templates. The goal is to come out of v1.2 with a more enhanced workflow for building site content.