The default content model that you get with PieCrust out of the box is a generic “blog engine” model. It can be configured, to a degree, using some simple website configuration settings that operate at a higher level about the content model.
Understanding how this all work can be useful to understand how the PieCrust content model can be tweaked to one’s liking.
The default sources define the strict minimum for a personal website:
“free-form” pages (pages) and blog posts (posts).
sources:
pages:
data_endpoint: site.pages
item_name: page
Here’s a breakdown of those settings:
pages source is anchored at the default location, which is a
sub-directory with the same name as the source (/pages).default) which just returns any
file inside its sub-directory as a page.site.pages.item_name so that you can prepare a new page with chef
prepare page.The posts sources is a bit more complicated:
sources:
posts:
type: posts/flat
fs_endpoint: posts
data_endpoint: blog
data_type: blog
default_layout: post
taxonomy_pages:
categories: pages:_category.%ext%;theme_pages:_category.%ext%
tags: pages:_tag.%ext%;theme_pages:_tag.%ext%
item_name: post
Here’s what this does:
posts source is also anchored at the default location (/posts). But if
the site/blogs setting lists more blogs, each blog will be listed under
/posts/<blogname>, effectively changing the fs_endpoint setting.posts/flat backend, which means blog posts should be named
with the date at the beginning of the filename. The site/posts_fs changes
this to posts/<fsname>.blog data endpoint, with a blog
data provider — which means you can also access blog archives in addition to
a flat list of all blog posts. If the site/blogs setting lists more blogs,
each blog will have its data_endpoint set to its name.post instead of
default.categories and tags. They’re set to
_category.* and _tag.* respectively, where the extension can be any of the
auto-formats (which means .md and .textile by default). They can also fall
back to the same pages defined in the current theme (whose source name is
theme_pages), which is what makes the default (built-in) PieCrust theme
work.The default content model defines 2 taxonomies: categories and tags. Categories are meant to be exclusive, i.e. a blog post can only have one category. Tags are meant to be used more freely, where a blog post can be tagged with multiple terms.
This shows up more or less like this in the website configuration:
taxonomies:
categories:
term: category
tags:
multiple: true
term: tag
The default content model defines routes for the site’s pages and blog posts roughly like such:
- url: /%path:slug%
source: pages
func: pcurl(slug)
- url: /%year%/%month%/%day%/%slug%
source: posts
func: pcposturl(year,month,day,slug)
- url: /tag/%tag%
source: posts
func: pctagurl(tag)
taxonomy: tags
- url: /category/%category%
source: posts
func: pccaturl(category)
taxonomy: categories
- url: /%path:slug%
source: theme_pages
func: pcurl(slug)
Let’s go through it:
pages source is exposed in the most simple way: just a single route,
rooted to /. Whatever slug gets returned for a page (which is pretty much
the relative path of the page’s file) will be its URL.posts source) are exposed with a /year/month/day/slug
URL, which matches the type of routing metadata the posts/* sources offer.
If the post_url is set, the route will be changed accordingly. If there’s
more than one blog in site/blogs, there will be more than one route for
posts, and the route will be rooted with /<blogname>.pcurl for pages, pcposturl for posts, etc.).