Your population is 6000000
Note that the file was filtered by Markdown because of `filters: markup-markdown` in the `_info.yaml` file in the directory. The `template-liquid` filter is provided by the plugin `ryver-template-liquid`. It may seem silly to add variables and then reference them in the templates directly like I did. However, their importance is more evident when you add more plugin to the mix, since plugins can (and will) create interesting (and useful!) variables. What you learned in this chapter: * You can enable the `template-liquid` filter by adding it to the `postProcessFilters` variable, enabling powerful templating based on variables. * Variables in the frontmatter are accessible with in the `info.` namespace (or the `info` object) * One of the things plugins do is provide extra variables for you to use ### Nested directories and variables It's important now to take a deep breath and realise the power of Ryver and its variable system. When you have a `_info.yaml` file in a directory, the variables set there will be available to every filtered file in that directory, as well as _every filtered file in any nested directory_. This means that for every directory you can have a "master" `_info.yaml` file, where you set variables to sane values, but then you can redifine _some_ (of all) of the values in sub-directories creating a `_info.yaml` file inside each one. And then, again, you can have files defining variables themselves using their own frontmatter. This implies that you will want the _generic_ settings for variables in the site's "main" `_info.yaml` file, and then get more and more specific as you go deeper into the file system. What you learned in this chapter: * Variables set in `_info.yaml` files will influence variables for every filtered file in that directory and in any subsirectory. Frontmatter in files will also redefine variables on a per-file basis. ### Filtering lifecycle At this point, you saw two cases where filtering was added: setting the `filters` variable, and setting the `postProcessFilters` variable. The basics of Ryver are simple: every file is filtered by the specified filters. Filters are made available by _plugins_. By default, all plugins available in stock Ryver are loaded (although this can be changed). You can decide what filters will apply to a file by setting the following phases: * `preProcessFilters`. * `preFilters`. * `filters`. * `postFilters`. * `postProcessFilters`. Generally speaking, you can place a filter anywhere here. However, some filters might need to be placed in specific spots. For example, you want `template-liquid` to have some action only when _all_ variables have been set by other plugins. The only time when you are _guaranteed_ that that will have happen is at `postProcessfilters` time. The stages are there mainly for grouping convenience. You can use all of them, or only a subset depending on how you want to organise your site. For example, it's common to only really use three of them, and set something like this in your `_info.yaml` file: preFilters: filters: markup-markdown postFilters: layout This will set a general behaviour you want nearly every page to have. I haven't yet explained the `layout` filter, but its meaning is pretty straightforward (it will place the contents of each file into a specified template). Generally speaking, every HTML page will have a layout, and it will be filtered as Markdown first (before being placed in the layout, obviously). For some inner pages, you might want to add more filters but still have `layout` there. So, in an inner directory, you might set: filters: markup-markdown,pager This will only affect pages within that subdirectory, and the `postFilters` variable will be untouched. So, `layout` will still be applied, along with `markup-markdown` and `pager` -- which is what you want. Basically, the five different stages are there to help you group what filters apply where. The scenario above is the most common one, but having five different groups five you the freedom to deal with the most complex scenarios. The only special phase is `postProcessFilters`: filters will be able to run once _all_ of the variables set by other plugins are fully set (which is why `template-liquid`, which is often used for variable substitution, is placed there). What you learned in this chapter: * You can plce filters in whichever phase you like, depending on how you decide to group them * All phases are equal, except `postProcessFilters` which guarantees that all variables set by plugins are set. * You should use grouping to simplify how you redefine filters according to filter definition in `_info.yaml`. You will usually put the most common case in the root `_info.yaml`, and then redefine specific groups in inner directories. ### Ryver's `_config.yaml` file Some of Ryver's plugins are configurable. If you place a file called `_config.yaml` in Ryver, you will be able to change some of the default configuration settings. Ryver uses the config file to those settings that are 1) Global in scope 2) Affecting how a plugin will work. For example, in `_config.yaml` you can define the list of plugins installed by default by Ryver, or where the layout files are (for the layout plugin). This sort of setting is global in scope, meaning that it wouldn't make sense to have it in `_info.yaml` (which has a per-directory scope) or in the file's frontmatter. I will now explain several filters; for each one, I will explain what confguration options you have in `_config.yaml` (which, I remind you, should be at the root of your source directory). What you learned in this chapter: * You can have a global config file called `_config.yaml` in the root of your source directory called * The `_config.yaml` file has global confguration options for plugins and filters ### Layout This is probably one of the most important plugins in Ryver. It allows you to place the contents of a file into a template. For example, create a file called `templateHelloWorld.md` with the following contents: --- layout: page.html postFilters: layout --- # Hello world! Mind you, it's a templated world! Running Ryver will result in an error: `Ryver · ENOENT, open 'src/_layouts/page.html'`` This error is there because Ryver expects, by default, to find `page.html` (the template file) in the `_layouts` directory. (NOTE: the `_layouts` directory will _not_ be in the resulting site since its name starts with an underscore). So, create a `_layouts` directory in the root of your source directory, and place a `page.html` file as follows:Mind you, it’s a templated world!
Note that this is the first time we do something actually useful using Ryver: you had a simple Markdown file called `templateHelloWorld.md` and produced, as a result, a functioning and well formatted HTML file called `templateHelloWorld.html`. Don't forget that the `markup-markdown` filter was applied because you have a `_info.yaml` file in the root of your source directory, with the following: filters: markup-markdown Finally, you can configure the layout plugin to change the name of the `_layouts` directory, by placing something like this in your `_config.yaml` file: `layoutsFolder: _alternativeLayoutsFolder` It's important for the directory name to start with an underscore, so that it won't be copied over to the final result. What you learned in this chapter: * You can filter contents though the `layout` filter, which will place the contents within a template with `postFilters: layout` in your frontmatter * In order for filtering to do anything, you need to have a `layout` variable set (on a per-directory bases, in a `_info.yaml` file, or in your frontmatter). E.g. `layout: page.html` will use the template in `_layouts/page.html` * The template file will be just text, with the special placeholder `` which will be replaced with the contents of the file ### Layout and liquid together If you worked with HTML generators before, you probably noticed an eye-sore in the `page.html` file:Mind you, it’s a templated world!
This is what happened in terms of filtering. The file had the following fiters set: * `filters: markup-markdown` (from `_info.yaml`) * `postFilters: layout` (from the file's frontmatter) * `postProcessFilters: template-liquid` (from the file's frontmatter) So, the filters will be applied in the following order: `markup-markdown`, `layout`, `template-liquid`. After `markup-markdown`, the contents will go from: # Hello world! Mind you, it's a templated world! To:Mind you, it’s a templated world!
Note that the file's name will also change to `templateHelloWorld.html` (the filter will actually rename the file). After `layout`, the contents will be placed accodding to the placeholder in `page.html`, and the contents will be transformed into:Mind you, it’s a templated world!
After `template-liquid`, all of the `liquid` directives will be executed, including `{{info.title}}`, and the contents will be transformed into:Mind you, it’s a templated world!
As you can see, _the order in which the filters are executed actually matters_. If you ran the `template-liquid` filter before `layout`, the variable `{{info.title}}` would never be resolved. If you ran `markup-markdown` after `layout`, the markdown filter would not work since it wouldn't compile anything within a `{{page.pageNumber}}