--- a/docs/docs/04_content-model.md	Fri Jun 03 20:21:58 2016 -0700
+++ b/docs/docs/04_content-model.md	Sat Jun 04 09:20:30 2016 -0700
@@ -11,29 +11,28 @@
 simple blog site where you can have pages and posts.
 
 To create more complex or customized websites, you can define another content
-model by specifying [sources][], [routes][], and [taxonomies][] in the [site
+model by specifying [sources][], [routes][], and [generators][] in the [site
 configuration][siteconf]:
 
 * [Sources][] are how you tell PieCrust where to find your content. It defines
-  in what sub-directories it will find what kind of pages, with what kind of
-  naming convention, and what kind of metadata. In theory, sources can also
-  provide pages from other places than the file-system -- like a network
-  connection or a ZIP file or a database or whatever.
+  what sub-directories contain what kind of pages, with what kind of naming
+  convention, and what kind of metadata. In theory, sources can also provide
+  pages from other places than the file-system -- like a network connection or
+  a ZIP file or a database or whatever.
 
 * [Routes][] define how the content returned by the sources is exposed to your
   visitors. This defines both the URLs for that content, and the place on disk
   where it will be baked to.
 
-* [Taxonomies][] define special types of metadata on which PieCrust will create
-  index pages. You can generally define any type of metadata on your pages in a
-  completely free-form way, without having to declare anything, but in some
-  situations -- like blog post categories -- you want PieCrust to create a page
-  that lists all pages assigned with each category.
+* [Generators][] define special types of sources which can procedurally generate
+  pages based on other content. A common type of generator is a "taxonomy"
+  generator, for things like "tags" or "categories". Based on how you've tagged
+  your blog posts, a generator would generate one page for each unique tag.
 
 
 [def]: {{docurl('content-model/default-model')}}
 [sources]: {{docurl('content-model/sources')}}
 [routes]: {{docurl('content-model/routes')}}
-[taxonomies]: {{docurl('content-model/taxonomies')}}
+[generators]: {{docurl('content-model/generators')}}
 [siteconf]: {{docurl('general/website-configuration')}}
 

--- a/docs/docs/04_content-model/01_sources.md	Fri Jun 03 20:21:58 2016 -0700
+++ b/docs/docs/04_content-model/01_sources.md	Sat Jun 04 09:20:30 2016 -0700
@@ -33,7 +33,8 @@
 * `data_endpoint`: Most sources will also want to expose all their pages to a
   template data endpoint, so you can easily iterate on them -- for example to
   show an archive or a site map. By default, this endpoint is the same as the
-  source's name, but it can be customized with the `data_endpoint` setting.
+  source's name, but it can be customized with the `data_endpoint` setting. For
+  more information on data providers, see [the reference page][refdata].
 
 * `data_type`: The data that's exposed through the `data_endpoint` is an
   `iterator` by default, which means it's a simple flat list of pages. There are
@@ -44,5 +45,6 @@
 For an example of sources configuration, see the [default content model][def].
 
 [refsrc]: {{docurl('reference/sources')}}
+[refdata]: {{docurl('reference/data-providers')}}
 [def]: {{docurl('content-model/default-model')}}
 

--- a/docs/docs/04_content-model/02_routes.md	Fri Jun 03 20:21:58 2016 -0700
+++ b/docs/docs/04_content-model/02_routes.md	Sat Jun 04 09:20:30 2016 -0700
@@ -23,14 +23,13 @@
   tied to this route. See the [list of available sources][refsrc] to see what
   kind of routing information they expose.
 
-* `source`: This defines the source that this route is defined for. Only pages
-  coming from that source will have their bake output generated from this route.
+* `source` or `generator`: This defines the source or generator that this route
+  is defined for. Only pages originating from the source or generator of that
+  name will have their bake output generated from this route. You can't define
+  both `source` and `generator` -- it needs to be one or the other.
 
 Optional settings include:
 
-* `taxonomy`: If this route is meant to match a taxonomy index page, you have to
-  define which taxonomy that is.
-
 * `page_suffix`: Pages that create _sub-pages_ (_e.g._ when using pagination)
   will append this suffix to the route. By default, this is `/%num%`. You _must_
   use the `%num%` placeholder somewhere in this setting.

--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/docs/docs/04_content-model/03_generators.md	Sat Jun 04 09:20:30 2016 -0700
@@ -0,0 +1,34 @@
+---
+title: Generators
+---
+
+Generators are like [sources][], but they procedurally generate pages based on
+the rest of your site's content.
+
+The [default content model][def] defines generators for your taxonomies (tags,
+categories, or whatever else you want to classify your posts with), and one
+generator for your blog archives (to generate one archive page per year).
+
+Generators are defined in the website configuration. For example:
+
+```
+site:
+  generators:
+    my_archives:
+      type: blog_archives
+        source: posts
+        page: 'page:_year.md'
+```
+
+The only required setting for a generator is the `type` setting, which specifies
+what type of generator this should be. Other settings depend on the type of
+generator.
+
+To see what generators are available in PieCrust out of the box, see the
+[reference page on generators][refgen].
+
+
+[sources]: {{docurl('content-model/routes')}}
+[refgen]: {{docurl('reference/generators')}}
+[def]: {{docurl('content-model/default-model')}}
+

--- a/docs/docs/04_content-model/03_taxonomies.md	Fri Jun 03 20:21:58 2016 -0700
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,54 +0,0 @@
----
-title: Taxonomies
----
-
-Taxonomies in PieCrust define pieces of page metadata for which you want to have
-_index pages_ created for you.
-
-## Taxonomy example
-
-A common example of taxonomies is the "_category_" of a blog post. If you have
-blog posts in categories "_recipes_", "_kitchen tips_" and "_restaurant
-reviews_", you want 3 pages to be created automatically for you so that someone
-can see a list of all recipes, kitchen tips, and restaurant reviews (and those
-pages may have _sub-pages_ if they're using pagination to only show 10 or so at
-a time).
-
-But if you write a new blog post and put it in category "_utensil reviews_", you
-want a new page listing all utensil reviews to also be created.
-
-You basically want PieCrust to "dynamically" generate those listing pages
-(called "_taxonomy index pages_") for each _value_ ever used in that given
-taxonomy.
-
-
-## Taxonomy configuration
-
-Taxonomies are defined under `site/taxonomies` in the website configuration:
-
-    site:
-        taxonomies:
-            categories:
-                multiple: true
-                page: pages:_cat.md
-            authors:
-                page: pages:_author.md
-
-These settings should be defined as a map. Each entry is the name of the
-taxonomy, and is associated with the settings for that taxonomy. Settings
-include:
-
-* `multiple`: Defines whether a page can have more than one value assigned for
-  this taxonomy. Defaults to `false` (_i.e._ only a single value can be
-  assigned).
-
-* `term`: Taxonomies are usually named using plural nouns. The `term` setting
-  lets you define the singular form, which is used to make some messages read
-  better.
-
-* `page`: Defines the page to use to generate the _index page_ for this
-  taxonomy. This is a [page reference][pageref].
-
-
-[pageref]: {{docurl('content-model/page-references')}}
-

--- a/docs/docs/04_content-model/05_default-model.md	Fri Jun 03 20:21:58 2016 -0700
+++ b/docs/docs/04_content-model/05_default-model.md	Sat Jun 04 09:20:30 2016 -0700
@@ -15,6 +15,8 @@
 The default sources define the strict minimum for a personal website:
 "free-form" pages (`pages`) and blog posts (`posts`).
 
+First, the pages:
+
     sources:
       pages:
         data_endpoint: site.pages
@@ -39,9 +41,6 @@
         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:
@@ -58,15 +57,11 @@
   each blog will have its `data_endpoint` set to its name.
 * The default layout to use for all blog posts is set to `post` instead of
   `default`.
-* Taxonomy index pages are defined for `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.
 
 
-## Taxonomies
+## Generators
+
+### Taxonomies
 
 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
@@ -75,12 +70,53 @@
 
 This shows up more or less like this in the website configuration:
 
-    taxonomies:
-      categories:
-        term: category
-      tags:
-        multiple: true
-        term: tag
+    site:
+      taxonomies:
+        categories:
+          term: category
+          func_name: pccaturl
+        tags:
+          multiple: true
+          term: tag
+
+PieCrust then creates a `taxonomy` generator for each defined taxonomy
+(including custom taxonomies you added). Each taxonomy generator will look like
+this:
+
+    site:
+      generators:
+        posts_FOOS:
+          type: taxonomy
+          taxonomy: FOOS
+          source: posts
+          page: "pages:_FOO.%ext%;theme_pages:_FOO.%ext%"
+
+In this example, `FOOS` is the name of the taxonomy (_e.g._: `tags`), and `FOO`
+is the `term` value (_e.g._: `tag`). If no `term` is defined, the name of the
+taxonomy is used.
+
+As you can see, the taxonomy index pages are set to `_category.*` and `_tag.*`
+respectively, where the extension can be any of the auto-formats (which means
+`.md`, `.textile`, and `.html` 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, for instance.
+
+### Archives
+
+The blog archives generator is defined like this by default:
+
+    site:
+      generators:
+        posts_archives:
+          type: blog_archives
+          source: posts
+          page: "pages:_year.%ext%;theme_pages:_year.%ext%"
+
+The index page for each year of archives is set to `_year.*`, where the
+extension can be any of the auto-formats (which means `.md`, `.textile`, and
+`.html` by default). It can also fall back to the same page defined in the
+current theme (whose source name is `theme_pages`), which is what makes the
+default (built-in) PieCrust theme work, for instance.
 
 
 ## Routes
@@ -91,17 +127,23 @@
     - url: /%path:slug%
       source: pages
       func: pcurl(slug)
+
     - url: /%year%/%month%/%day%/%slug%
       source: posts
       func: pcposturl(year,month,day,slug)
+
+    - url: /archives/%year%
+      generator: posts_archives
+      func: pcyearurl(year)
+
     - url: /tag/%tag%
-      source: posts
+      generator: posts_tags
       func: pctagurl(tag)
-      taxonomy: tags
+
     - url: /category/%category%
-      source: posts
+      generator: posts_categories
       func: pccaturl(category)
-      taxonomy: categories
+
     - url: /%path:slug%
       source: theme_pages
       func: pcurl(slug)
@@ -111,15 +153,24 @@
 * The `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.
+
 * Blog posts (from the `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>`.
-* There are then 2 routes for the taxonomies defined in the default content
-  model (tags and categories).
+
+* The next route is for the blog archives generator.
+
+* There are then routes for the taxonomy generators. By default, there are
+  2 taxonomies (tags and categories) so that's 2 routes.
+
 * All routes define some URL functions for use in your pages and templates
-  (`pcurl` for pages, `pcposturl` for posts, etc.).
+  (`pcurl` for pages, `pcposturl` for posts, etc.). Note that by default the
+  `categories` taxonomy would have a `pccategoryurl` route function, which is
+  a bit too long to type, so by default that taxonomy specifies a `func_name` to
+  override that to `pccaturl`.
+
 * The last route is meant to match any page defined in the theme. It happens
   last so that a page with the same relative path in your website will properly
   override it.

--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/docs/docs/99_reference/04_generators.md	Sat Jun 04 09:20:30 2016 -0700
@@ -0,0 +1,120 @@
+---
+title: "Appendix 4: Generators Reference"
+short_title: Generators Reference
+---
+
+Here are the generators that come with PieCrust by default.
+
+
+## Taxonomy generator
+
+A taxonomy is a way to classify content. The most common taxonomies are things
+like "_tags_" or "_categories_" that you use to classify blog posts.
+
+The taxonomy generator creates _index pages_ that list all the content in every
+_taxonomy term_ in use. 
+
+### Taxonomy example
+
+A common example of taxonomies is the "_category_" of a blog post. If you have
+blog posts in categories "_recipes_", "_kitchen tips_" and "_restaurant
+reviews_", you want 3 pages to be created automatically for you so that someone
+can see a list of all recipes, kitchen tips, and restaurant reviews. Those
+3 pages may of course have _sub-pages_ if they're using pagination to only show
+10 or so at a time.
+
+If you write a new blog post and put it in category "_utensil reviews_", you
+want a new page listing all utensil reviews to also be created.
+
+### Generator configuration
+
+The taxonomy generator takes the following configuration settings:
+
+* `type`: Needs to be `taxonomy`.
+
+* `taxonomy`: The name of a taxonomy, defined under `site/taxonomies`. See below
+  for more information.
+
+* `source`: The name of a source from which to look for classified content. For
+  example, `posts` is the name of the default blog posts source.
+
+* `page`: A [page reference][pageref] to an index page to use for each generated
+  page. This index page will be passed some template data to list the
+  appropriate content (more on this later).
+
+### Taxonomy configuration
+
+Taxonomies are defined under `site/taxonomies` in the website configuration:
+
+    site:
+        taxonomies:
+            tags:
+                multiple: true
+                term: tag
+
+These settings should be defined as a map. Each entry is the name of the
+taxonomy, and is associated with the settings for that taxonomy. Settings
+include:
+
+* `multiple`: Defines whether a page can have more than one value assigned for
+  this taxonomy. Defaults to `false` (_i.e._ only a single value can be
+  assigned).
+
+* `term`: Taxonomies are usually named using plural nouns. The `term` setting
+  lets you define the singular form, which is used in multiple places.
+
+### Template data
+
+When the taxonomy generator renders your _index page_, it will pass it the
+following template data:
+
+* `<taxonomy_name>` (the taxonomy name) will contain the term, or terms, for the
+  current listing. For instance, for a "_tags_" taxonomy, it will contain the
+  list of tags for the current listing. In 99% of cases, that list will contain
+  only one term, but for "_term combinations_" (i.e. listing pages tagged with
+  2 or more tags), it could contain more than one. For taxonomies that don't
+  have the `multiple` flag, though, that template data will only be a single
+  term (_i.e._ a string value).
+
+* `pagination.items` will list the classified content, _i.e._ content from the
+  generator's `source`, filtered for only content with the current term. For
+  instance, the list of blog posts with the current tag or category or whatever.
+  Note that this is still pagination data, so it will create _sub-pages_.
+
+
+## Blog archives
+
+This generator will generate one page per year for a given source of pages. This
+is useful for generating yearly blog archives.
+
+### Generator configuration
+
+The blog archives generator takes the following configuration settings:
+
+* `type`: Needs to be `blog_archives`.
+
+* `source`: The name of a source from which to look for dated content.
+
+* `page`: A [page reference][pageref] to an index page to use for each generated
+  yearly archive page.
+
+### Template data
+
+When the blog archives generator renders your _index page_, it will pass it the
+following template data:
+
+* `year` is the current year.
+
+* `pagination.items` lists the content dated for the current year, in
+  reverse-chronological order. This will potentially create _sub-pages_ since
+  this is pagination data.
+
+* `archives` lists the same thing as `pagination.items`, but without paginating
+  anyting, _i.e._ even if you have _lots_ of blog posts in a given year, they
+  will all be listed on the same page, instead of being listed, say, 10 per
+  page, with _sub-pages_ created for the rest. Also, `archives` will list posts
+  in chronological order.
+
+
+[pageref]: {{docurl('content-model/page-references')}}
+

--- a/docs/docs/99_reference/04_templating-data.md	Fri Jun 03 20:21:58 2016 -0700
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,128 +0,0 @@
----
-title: "Appendix 4: Templating Data Reference"
-short_title: Templating Data Reference
----
-
-When a page or layout gets rendered, it goes through a templating phase. During
-that phase, PieCrust builds the _template data_ that gets passed to the template
-engine.
-
-This page shows a list of all the data that gets created for this occasion. Note
-that most of this data is in fact created "on-demand" (_i.e._ lazily evaluated)
-so that you only pay the price of whatever you use.
-
-Note that you can inspect this data yourself by using the debug window.
-
-
-* `piecrust`: Contains data specific to PieCrust itself.
-
-    * `version`: The version number of PieCrust.
-
-    * `url`: URL to the official PieCrust website.
-
-    * `branding`: A short message saying "_Baked with PieCrust_", along with a
-      link to the official website.
-
-    * `debug_info`: If enabled, the debug window.
-
-* `page`: Contains the page's metadata. This is basically the page's configuration header, as you wrote it, plus any default values for things you omitted, and any additional values set by sources (like the `ordered` or `autoconfig` sources) or plugins.
-
-  Notable additional data includes:
-
-    * `url`: The URL of the page.
-    * `slug`: The slug of the page.
-    * `timestamp`: The UNIX timestamp of the page.
-    * `date`: The formatted (user-friendly) version of the page's timestamp,
-      according to the `site/date_format` setting.
-
-* `assets`: The list of assets for this page.
-
-    * It can be iterated upon, to list all assets.
-    * It can be accessed by name, to access a specific asset.
-
-* `pagination`: Gives access to a paginating version of the default source's
-  list of pages. The default source will be the first blog in the website, if
-  any (as defined by `site/blogs`). It can be overriden by setting the `source`
-  or `blog` setting on the current page, in which case a source of that name
-  will be used.
-
-  Note that the object returned by `pagination`, called a paginator, can also be
-  returned by other things, like the `paginate()` template function, for
-  instance. As such, it does not assume that the items it is paginating are
-  posts or pages.
-
-    * `has_more`: Whether there are more items.
-
-    * `items` (or `posts`): The list of items.
-
-    * `has_items`: Whether there are any items.
-
-    * `items_per_page`: Returns how many maxiumum items there are for each
-      sub-page. Can be overriden locally with the `items_per_page` setting in
-      the page configuration.
-
-    * `items_this_page`: Returns the number of actual items on the current
-      sub-page. This will always be `items_per_page` except for the last page
-      (which can be the first page).
-    
-    * `prev_page_number`: The previous sub-page number, if any.
-
-    * `this_page_number`: The current sub-page number. The first page is number
-      `1`.
-    
-    * `next_page_number`: The next sub-page number, if any.
-
-    * `prev_page`: The URL to the previous sub-page, if any.
-
-    * `this_page`: The URL to the current sub-page.
-
-    * `next_page`: The URL to the next sub-page, if any.
-
-    * `total_item_count`: The total number of items across all sub-pages.
-
-    * `total_page_count`: The total number of sub-pages.
-
-    * `next_item`: The next item, if any.
-
-    * `prev_item`: The previous item, if any.
-
-    * `all_page_numbers(radius)`: A function that returns a list of page
-      numbers. With no argument, this returns a list of all page numbers, from 1
-      to the last number. With an argument, this returns a subset of this list,
-      with a "radius" equal to the argument "around" the current sub-page.
-
-    * `page(index)`: Returns the URL of a sub-page of the given number.
-
-* `family`: Returns a piece of data that lets you access parents, siblings, and
-  children of the current page. This is only possible for page sources that
-  support hierarchical navigation (but most of those shipping with PieCrust do).
-
-    * `parent`: Returns the data for a parent page, _i.e._ a page with the same
-      name as the current page's directory name. So if the current page is
-      `/foo/bar/something.md`, this would return the data for a page named
-      `/foo/bar.md`.
-
-    * `ancestors`: Returns a list of data for all parents, all the way to the
-      root. In the previous example, this would return `/foo/bar.md` and
-      `/foo.md` (if they exist).
-
-    * `siblings`: Returns a list of the current page's siblings, _i.e._ pages on
-      the same "level" as the current one.
-
-    * `children`: Returns a list of the current page's children, _i.e._ pages
-      that are "under" the current page. In most cases, this means pages that
-      are in a sub-directory with the same name as the current page's file name.
-
-    * `root`: Returns the root of the current page's source, so that you can
-      traverse all pages in a hierarchical manner.
-
-    * `forpath(path)`: Returns the family data starting at the given relative
-      path.
-
-* All the website configuration is merged with the data.
-
-* All source data providers are also included. For example, in the default
-  content model, the `pages` source is exposed to `site/pages`, so using
-  `site.pages` through the template engine would return a complete list of all
-  the pages in your website.
-

--- a/docs/docs/99_reference/05_asset-processors.md	Fri Jun 03 20:21:58 2016 -0700
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,159 +0,0 @@
----
-title: "Appendix 5: Asset Processors"
-short_title: "Asset Processors"
----
-
-Here's a list of the PieCrust pipeline's asset processors that ship with
-PieCrust by default.
-
-Configuration settings for asset processors must be defined in the website
-configuration, unless noted otherwise.
-
-
-## CleanCSS
-
-Compresses CSS files using the `cleancss` utility.
-
-Name: `cleancss`
-
-Configuration settings (under `cleancss/`):
-
-* `bin`: The name or path of the `cleancss` executable. Defaults to `cleancss`,
-  which means it's expected you have it in your `PATH`.
-
-* `options`: A list of miscellaneous options to pass to `cleancss`. Defaults to
-  `--skip-rebase`.
-
-
-## Compass
-
-A processor that runs `compass` as part of the bake.
-
-Name: `compass`
-
-Configuration settings (under `compass/`):
-
-* `enable`: This processor is disabled by default. You need to set this
-  setting to `true`.
-
-* `bin`: The name or path of the `compass` executable. Defaults to `compass`,
-  which means it's expected you have it in your `PATH`.
-
-* `frameworks`: The list of frameworks to enable.
-
-* `options`: A list of miscellaneous options to pass to `compass`. You can use
-  the placeholders `%out_dir%` and `%tmp_dir%` to refer to the temporary and
-  output directories of the current bake.
-
-Notes:
-
-* It's expected that the Compass configuration file is called `config.rb` and is
-  located in your website's root directory.
-
-* To troubleshoot any problems, run `chef` with the `--debug` option to see the
-  full command-line invocation of `compass`.
-
-
-## Concat
-
-A simple processor that concatenates multiple other files.
-
-The input for this processor must be a `.concat` file whose file name without
-the `.concat` extension will be the output file name. The contents must be a
-YAML configuration that lists the files to concatenate.
-
-So for instance, a `foo.js.concat` file will generate an output file named
-`foo.js`. If the concents of the `.concat` file are the same as below, it will
-end up being the concatenation of files `something.js` and `lib/vendor/blah.js`:
-
-    files:
-        - foo.js
-        - lib/vendor/blah.js
-
-Other settings are possible in the YAML file:
-
-* `path_mode`: Either `relative` or `absolute`. If `relative`, the `files` list
-  specifies files relative to the `.concat` file. Otherwise, they're relative to
-  the asset root directory.
-
-* `delim`: The delimiter string to use between each concatenated file. Defaults
-  to a line feed (`\n`).
-
-
-## Copy
-
-A simple processor that copies the input file to the same place (relative to the
-asset directory, and to the output directory).
-
-Name: `copy`
-
-
-## LessCSS
-
-Converts LESS CSS files into normal CSS.
-
-Name: `less`
-
-Configuration settings (under `less/`):
-
-* `bin`: The name or path of the `lessc` executable. Defaults to `lessc`,
-  which means it's expected you have it in your `PATH`.
-
-* `options`: A list of miscellaneous options to pass to `lessc`. Defaults to
-  `--compress`.
-
-
-## Sass
-
-Converts Sass files (`.scss`, `.sass`) into normal CSS.
-
-Name: `sass`
-
-Configuration settings (under `sass/`):
-
-* `bin`: The name or path of the `scss` executable. Defaults to `scss`,
-  which means it's expected you have it in your `PATH`.
-
-* `style`: The output CSS style. Defaults to `nested`.
-
-* `load_paths`: A list of additional include paths. Defaults to an empty
-  list.
-
-* `options`: A list of miscellaneous options to pass to `lessc`. Defaults to
-  an empty list.
-
-
-## Sitemap
-
-Creates a Sitemap file by transforming a `.sitemap` file into a `.xml` file of
-the same name with contents that match the Sitemap specification.
-
-The `.sitemap` must be a YAML file (_i.e._ something a bit like the website
-configuration file) that can contain either:
-
-* `locations`: A list of locations to include in the Sitemap file. Each location
-  must have a `url` setting. Optionally, they can have a `lastmod`,
-  `changefreq`, and/or `priority` setting. This is basically boiling down to
-  writing the Sitemap in YAML instead of XML.
-
-* `autogen`: This should be a list of page source names for which to
-  auto-generate the Sitemap. Each source listed here will have all its pages
-  included in the Sitemap. The `url` and `lastmod` of each entry will be set
-  accordingly to their corresponding page. Each page can define a `sitemap`
-  configuration setting to override or add to the corresponding entry.
-  
-
-## UglifyJS
-
-Compresses Javascript files using the `uglifyjs` utility.
-
-Name: `uglifyjs`
-
-Configuration settings (under `uglifyjs/`):
-
-* `bin`: The name or path of the `uglifyjs` executable. Defaults to `uglifyjs`,
-  which means it's expected you have it in your `PATH`.
-
-* `options`: A list of miscellaneous options to pass to `uglifyjs`. Defaults to
-  `--compress`.
-

--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/docs/docs/99_reference/05_data-providers.md	Sat Jun 04 09:20:30 2016 -0700
@@ -0,0 +1,49 @@
+---
+title: "Appendix 5: Data Providers Reference"
+short_title: Data Providers Reference
+---
+
+Data providers expose [templating data][tpldata] to the [template
+engine][tpleng]. They are used, among other places, by the [sources][src].
+
+
+## Iterator provider
+
+The iterator provider just provides a list of pages for a given source. This is
+the simplest provider.
+
+* `type`: Must be `iterator`.
+
+
+## Blog provider
+
+This provider gives some structured access to blog data.
+
+* `type`: Must be `blog`.
+
+The templating data exposed by this provider includes:
+
+* `posts`: The list of posts in the given source.
+* `years`: A list of years containing blog posts.
+* `months`: A list of months containing blog posts.
+* `<taxonomy name>`: For any existing taxonomy, lists the terms in use and, for
+  each of those, the posts classified with it.
+
+Each `years` and `months` entry contains:
+
+* `name`: The name of the year or month.
+* `timestamp`: The timestamp for the year or month.
+* `posts`: The list of posts in the year or month.
+
+Each taxonomy term entry contains:
+
+* `name`: The name of the term.
+* `posts`: The list of posts classified with the term.
+* `post_count`: The number of posts classified with the term. It's useful for
+  making things like tag clouds.
+
+
+[tpldata]: {{docurl('reference/templating-data')}}
+[tpleng]: {{docurl('content/templating')}}
+[src]: {{docurl('content-model/sources')}}
+

--- a/docs/docs/99_reference/06_publishers.md	Fri Jun 03 20:21:58 2016 -0700
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,57 +0,0 @@
----
-title: "Appendix 6: Publishers"
-short_title: "Publishers"
----
-
-Here's a list of website publishers that ship by default with PieCrust.
-
-Publishers are declared and configured in the website configuration like so:
-
-```
-publish:
-    <target_name>:
-        type: <publisher_type>
-        <config1>: <value1>
-        <config2>: <value2>
-```
-
-Note that apart for the `type` setting, all publishers also share a few common
-configuration settings:
-
-* `bake` (`true`): Unless set to `false`, PieCrust will first bake your website
-  into a temporary folder (`_cache/pub/<target_name>`). The publisher will then
-  by default pick it up from there.
-
-In addition to specifying publish targets via configuration settings, you can
-also (if you don't need anything fancy) specify some of them via a simple
-URL-like line:
-
-```
-publish:
-    <target_name>: <something://foo/bar>
-```
-
-The URL-like format is specified below on a per-publisher basis.
-
-
-## Shell Command
-
-This simple publisher runs the specified command from inside your website root
-directory.
-
-* `type`: `shell`.
-* `command`: The command to run.
-
-
-## Rsync
-
-This publisher will run `rsync` to copy or upload your website's bake output to
-a given destination.
-
-* `type`: `rsync`.
-* `destination`: The destination given to the `rsync` executable.
-* `source` (`_cache/pub/<target_name>`): The source given to the `rsync`
-  executable. It defaults to the automatic pre-publish bake output folder.
-* `options` (`-avc --delete`): The options to pass to the `rsync` executable. By
-  default, those will run `rsync` in "mirroring" mode.
-

--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/docs/docs/99_reference/06_templating-data.md	Sat Jun 04 09:20:30 2016 -0700
@@ -0,0 +1,128 @@
+---
+title: "Appendix 6: Templating Data Reference"
+short_title: Templating Data Reference
+---
+
+When a page or layout gets rendered, it goes through a templating phase. During
+that phase, PieCrust builds the _template data_ that gets passed to the template
+engine.
+
+This page shows a list of all the data that gets created for this occasion. Note
+that most of this data is in fact created "on-demand" (_i.e._ lazily evaluated)
+so that you only pay the price of whatever you use.
+
+Note that you can inspect this data yourself by using the debug window.
+
+
+* `piecrust`: Contains data specific to PieCrust itself.
+
+    * `version`: The version number of PieCrust.
+
+    * `url`: URL to the official PieCrust website.
+
+    * `branding`: A short message saying "_Baked with PieCrust_", along with a
+      link to the official website.
+
+    * `debug_info`: If enabled, the debug window.
+
+* `page`: Contains the page's metadata. This is basically the page's configuration header, as you wrote it, plus any default values for things you omitted, and any additional values set by sources (like the `ordered` or `autoconfig` sources) or plugins.
+
+  Notable additional data includes:
+
+    * `url`: The URL of the page.
+    * `slug`: The slug of the page.
+    * `timestamp`: The UNIX timestamp of the page.
+    * `date`: The formatted (user-friendly) version of the page's timestamp,
+      according to the `site/date_format` setting.
+
+* `assets`: The list of assets for this page.
+
+    * It can be iterated upon, to list all assets.
+    * It can be accessed by name, to access a specific asset.
+
+* `pagination`: Gives access to a paginating version of the default source's
+  list of pages. The default source will be the first blog in the website, if
+  any (as defined by `site/blogs`). It can be overriden by setting the `source`
+  or `blog` setting on the current page, in which case a source of that name
+  will be used.
+
+  Note that the object returned by `pagination`, called a paginator, can also be
+  returned by other things, like the `paginate()` template function, for
+  instance. As such, it does not assume that the items it is paginating are
+  posts or pages.
+
+    * `has_more`: Whether there are more items.
+
+    * `items` (or `posts`): The list of items.
+
+    * `has_items`: Whether there are any items.
+
+    * `items_per_page`: Returns how many maxiumum items there are for each
+      sub-page. Can be overriden locally with the `items_per_page` setting in
+      the page configuration.
+
+    * `items_this_page`: Returns the number of actual items on the current
+      sub-page. This will always be `items_per_page` except for the last page
+      (which can be the first page).
+    
+    * `prev_page_number`: The previous sub-page number, if any.
+
+    * `this_page_number`: The current sub-page number. The first page is number
+      `1`.
+    
+    * `next_page_number`: The next sub-page number, if any.
+
+    * `prev_page`: The URL to the previous sub-page, if any.
+
+    * `this_page`: The URL to the current sub-page.
+
+    * `next_page`: The URL to the next sub-page, if any.
+
+    * `total_item_count`: The total number of items across all sub-pages.
+
+    * `total_page_count`: The total number of sub-pages.
+
+    * `next_item`: The next item, if any.
+
+    * `prev_item`: The previous item, if any.
+
+    * `all_page_numbers(radius)`: A function that returns a list of page
+      numbers. With no argument, this returns a list of all page numbers, from 1
+      to the last number. With an argument, this returns a subset of this list,
+      with a "radius" equal to the argument "around" the current sub-page.
+
+    * `page(index)`: Returns the URL of a sub-page of the given number.
+
+* `family`: Returns a piece of data that lets you access parents, siblings, and
+  children of the current page. This is only possible for page sources that
+  support hierarchical navigation (but most of those shipping with PieCrust do).
+
+    * `parent`: Returns the data for a parent page, _i.e._ a page with the same
+      name as the current page's directory name. So if the current page is
+      `/foo/bar/something.md`, this would return the data for a page named
+      `/foo/bar.md`.
+
+    * `ancestors`: Returns a list of data for all parents, all the way to the
+      root. In the previous example, this would return `/foo/bar.md` and
+      `/foo.md` (if they exist).
+
+    * `siblings`: Returns a list of the current page's siblings, _i.e._ pages on
+      the same "level" as the current one.
+
+    * `children`: Returns a list of the current page's children, _i.e._ pages
+      that are "under" the current page. In most cases, this means pages that
+      are in a sub-directory with the same name as the current page's file name.
+
+    * `root`: Returns the root of the current page's source, so that you can
+      traverse all pages in a hierarchical manner.
+
+    * `forpath(path)`: Returns the family data starting at the given relative
+      path.
+
+* All the website configuration is merged with the data.
+
+* All source data providers are also included. For example, in the default
+  content model, the `pages` source is exposed to `site/pages`, so using
+  `site.pages` through the template engine would return a complete list of all
+  the pages in your website.
+

--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/docs/docs/99_reference/20_asset-processors.md	Sat Jun 04 09:20:30 2016 -0700
@@ -0,0 +1,159 @@
+---
+title: "Appendix 7: Asset Processors"
+short_title: "Asset Processors"
+---
+
+Here's a list of the PieCrust pipeline's asset processors that ship with
+PieCrust by default.
+
+Configuration settings for asset processors must be defined in the website
+configuration, unless noted otherwise.
+
+
+## CleanCSS
+
+Compresses CSS files using the `cleancss` utility.
+
+Name: `cleancss`
+
+Configuration settings (under `cleancss/`):
+
+* `bin`: The name or path of the `cleancss` executable. Defaults to `cleancss`,
+  which means it's expected you have it in your `PATH`.
+
+* `options`: A list of miscellaneous options to pass to `cleancss`. Defaults to
+  `--skip-rebase`.
+
+
+## Compass
+
+A processor that runs `compass` as part of the bake.
+
+Name: `compass`
+
+Configuration settings (under `compass/`):
+
+* `enable`: This processor is disabled by default. You need to set this
+  setting to `true`.
+
+* `bin`: The name or path of the `compass` executable. Defaults to `compass`,
+  which means it's expected you have it in your `PATH`.
+
+* `frameworks`: The list of frameworks to enable.
+
+* `options`: A list of miscellaneous options to pass to `compass`. You can use
+  the placeholders `%out_dir%` and `%tmp_dir%` to refer to the temporary and
+  output directories of the current bake.
+
+Notes:
+
+* It's expected that the Compass configuration file is called `config.rb` and is
+  located in your website's root directory.
+
+* To troubleshoot any problems, run `chef` with the `--debug` option to see the
+  full command-line invocation of `compass`.
+
+
+## Concat
+
+A simple processor that concatenates multiple other files.
+
+The input for this processor must be a `.concat` file whose file name without
+the `.concat` extension will be the output file name. The contents must be a
+YAML configuration that lists the files to concatenate.
+
+So for instance, a `foo.js.concat` file will generate an output file named
+`foo.js`. If the concents of the `.concat` file are the same as below, it will
+end up being the concatenation of files `something.js` and `lib/vendor/blah.js`:
+
+    files:
+        - foo.js
+        - lib/vendor/blah.js
+
+Other settings are possible in the YAML file:
+
+* `path_mode`: Either `relative` or `absolute`. If `relative`, the `files` list
+  specifies files relative to the `.concat` file. Otherwise, they're relative to
+  the asset root directory.
+
+* `delim`: The delimiter string to use between each concatenated file. Defaults
+  to a line feed (`\n`).
+
+
+## Copy
+
+A simple processor that copies the input file to the same place (relative to the
+asset directory, and to the output directory).
+
+Name: `copy`
+
+
+## LessCSS
+
+Converts LESS CSS files into normal CSS.
+
+Name: `less`
+
+Configuration settings (under `less/`):
+
+* `bin`: The name or path of the `lessc` executable. Defaults to `lessc`,
+  which means it's expected you have it in your `PATH`.
+
+* `options`: A list of miscellaneous options to pass to `lessc`. Defaults to
+  `--compress`.
+
+
+## Sass
+
+Converts Sass files (`.scss`, `.sass`) into normal CSS.
+
+Name: `sass`
+
+Configuration settings (under `sass/`):
+
+* `bin`: The name or path of the `scss` executable. Defaults to `scss`,
+  which means it's expected you have it in your `PATH`.
+
+* `style`: The output CSS style. Defaults to `nested`.
+
+* `load_paths`: A list of additional include paths. Defaults to an empty
+  list.
+
+* `options`: A list of miscellaneous options to pass to `lessc`. Defaults to
+  an empty list.
+
+
+## Sitemap
+
+Creates a Sitemap file by transforming a `.sitemap` file into a `.xml` file of
+the same name with contents that match the Sitemap specification.
+
+The `.sitemap` must be a YAML file (_i.e._ something a bit like the website
+configuration file) that can contain either:
+
+* `locations`: A list of locations to include in the Sitemap file. Each location
+  must have a `url` setting. Optionally, they can have a `lastmod`,
+  `changefreq`, and/or `priority` setting. This is basically boiling down to
+  writing the Sitemap in YAML instead of XML.
+
+* `autogen`: This should be a list of page source names for which to
+  auto-generate the Sitemap. Each source listed here will have all its pages
+  included in the Sitemap. The `url` and `lastmod` of each entry will be set
+  accordingly to their corresponding page. Each page can define a `sitemap`
+  configuration setting to override or add to the corresponding entry.
+  
+
+## UglifyJS
+
+Compresses Javascript files using the `uglifyjs` utility.
+
+Name: `uglifyjs`
+
+Configuration settings (under `uglifyjs/`):
+
+* `bin`: The name or path of the `uglifyjs` executable. Defaults to `uglifyjs`,
+  which means it's expected you have it in your `PATH`.
+
+* `options`: A list of miscellaneous options to pass to `uglifyjs`. Defaults to
+  `--compress`.
+

--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/docs/docs/99_reference/40_publishers.md	Sat Jun 04 09:20:30 2016 -0700
@@ -0,0 +1,57 @@
+---
+title: "Appendix 8: Publishers"
+short_title: "Publishers"
+---
+
+Here's a list of website publishers that ship by default with PieCrust.
+
+Publishers are declared and configured in the website configuration like so:
+
+```
+publish:
+    <target_name>:
+        type: <publisher_type>
+        <config1>: <value1>
+        <config2>: <value2>
+```
+
+Note that apart for the `type` setting, all publishers also share a few common
+configuration settings:
+
+* `bake` (`true`): Unless set to `false`, PieCrust will first bake your website
+  into a temporary folder (`_cache/pub/<target_name>`). The publisher will then
+  by default pick it up from there.
+
+In addition to specifying publish targets via configuration settings, you can
+also (if you don't need anything fancy) specify some of them via a simple
+URL-like line:
+
+```
+publish:
+    <target_name>: <something://foo/bar>
+```
+
+The URL-like format is specified below on a per-publisher basis.
+
+
+## Shell Command
+
+This simple publisher runs the specified command from inside your website root
+directory.
+
+* `type`: `shell`.
+* `command`: The command to run.
+
+
+## Rsync
+
+This publisher will run `rsync` to copy or upload your website's bake output to
+a given destination.
+
+* `type`: `rsync`.
+* `destination`: The destination given to the `rsync` executable.
+* `source` (`_cache/pub/<target_name>`): The source given to the `rsync`
+  executable. It defaults to the automatic pre-publish bake output folder.
+* `options` (`-avc --delete`): The options to pass to the `rsync` executable. By
+  default, those will run `rsync` in "mirroring" mode.
+