Transform your plain text into static sites and blogs
Note: The book edition is still an early release and a work-in-progess.
This is the (official) documentation for the Jekyll static site builder / generator reformatted in a single-page book edition.
See the source repo for how the book gets auto-built with "plain" Jekyll - of course - and hosted on GitHub Pages.
Questions? Comments? Send them to the Jekyll Talk forum post titled Jekyll Docu Reformatted as a Single-Page in Black 'n' White (Book Version) - Why? Why Not?.
Onwards.
Thanks to all Jekyll contributors for making it all possible.
This site aims to be a comprehensive guide to Jekyll. We’ll cover topics such as getting your site up and running, creating and managing your content, customizing the way your site works and looks, deploying to various environments, and give you some advice on participating in the future development of Jekyll itself.
Jekyll is a simple, blog-aware, static site generator. It takes a template directory containing raw text files in various formats, runs it through a converter (like Markdown) and our Liquid renderer, and spits out a complete, ready-to-publish static website suitable for serving with your favorite web server. Jekyll also happens to be the engine behind GitHub Pages, which means you can use Jekyll to host your project’s page, blog, or website from GitHub’s servers for free.
Throughout this guide there are a number of small-but-handy pieces of information that can make using Jekyll easier, more interesting, and less hazardous. Here’s what to look out for.
These are tips and tricks that will help you be a Jekyll wizard!
These are for the extra tidbits sometimes necessary to understand Jekyll.
Be aware of these messages if you wish to avoid certain death.
Some pieces of this website are for future versions of Jekyll that are not yet released.
If you come across anything along the way that we haven’t covered, or if you know of a tip you think others would find handy, please file an issue and we’ll see about including it in this guide.
For the impatient, here’s how to get a boilerplate Jekyll site up and running.
~ $ gem install jekyll
~ $ jekyll new myblog
~ $ cd myblog
~/myblog $ jekyll serve
# => Now browse to http://localhost:4000If you wish to install jekyll into an existing directory, you can do so by running jekyll new . from within the directory instead of creating a new one. If the existing directory isn’t empty, you’ll also have to pass the --force option like so jekyll new . --force.
That’s nothing, though. The real magic happens when you start creating blog posts, using the front matter to control templates and layouts, and taking advantage of all the awesome configuration options Jekyll makes available.
If you’re running into problems, ensure you have all the requirements installed.
The Jekyll gem makes a jekyll executable available to you in your Terminal
window. You can use this command in a number of ways:
$ jekyll build
# => The current folder will be generated into ./_site
$ jekyll build --destination <destination>
# => The current folder will be generated into <destination>
$ jekyll build --source <source> --destination <destination>
# => The <source> folder will be generated into <destination>
$ jekyll build --watch
# => The current folder will be generated into ./_site,
# watched for changes, and regenerated automatically.
The _config.yml master configuration file contains global configurations
and variable definitions that are read once at execution time. Changes made to _config.yml
during automatic regeneration are not loaded until the next execution.
Note Data Files are included and reloaded during automatic regeneration.
The contents of <destination> are automatically
cleaned, by default, when the site is built. Files or folders that are not
created by your site will be removed. Files and folders you wish to retain
in <destination> may be specified within the <keep_files>
configuration directive.
Do not use an important location for <destination>;
instead, use it as a staging area and copy files from there to your web server.
Jekyll also comes with a built-in development server that will allow you to preview what the generated site will look like in your browser locally.
$ jekyll serve
# => A development server will run at http://localhost:4000/
# Auto-regeneration: enabled. Use `--no-watch` to disable.
$ jekyll serve --detach
# => Same as `jekyll serve` but will detach from the current terminal.
# If you need to kill the server, you can `kill -9 1234` where "1234" is the PID.
# If you cannot find the PID, then do, `ps aux | grep jekyll` and kill the instance. [Read more](http://unixhelp.ed.ac.uk/shell/jobz5.html).
As of version 2.4, the serve command will watch for changes automatically. To disable this, you can use jekyll serve --no-watch, which preserves the old behavior.
$ jekyll serve --no-watch
# => Same as `jekyll serve` but will not watch for changes.These are just a few of the available configuration options.
Many configuration options can either be specified as flags on the command line,
or alternatively (and more commonly) they can be specified in a _config.yml
file at the root of the source directory. Jekyll will automatically use the
options from this file when run. For example, if you place the following lines
in your _config.yml file:
source: _source
destination: _deployThen the following two commands will be equivalent:
$ jekyll build
$ jekyll build --source _source --destination _deployFor more about the possible configuration options, see the configuration page.
If you’re interested in browsing these docs on-the-go, install the
jekyll-docs gem and run jekyll docs in your terminal.
Jekyll is, at its core, a text transformation engine. The concept behind the system is this: you give it text written in your favorite markup language, be that Markdown, Textile, or just plain HTML, and it churns that through a layout or series of layout files. Throughout that process you can tweak how you want the site URLs to look, what data gets displayed in the layout, and more. This is all done through editing text files, and the static web site is the final product.
A basic Jekyll site usually looks something like this:
.
├── _config.yml
├── _drafts
| ├── begin-with-the-crazy-ideas.textile
| └── on-simplicity-in-technology.markdown
├── _includes
| ├── footer.html
| └── header.html
├── _layouts
| ├── default.html
| └── post.html
├── _posts
| ├── 2007-10-29-why-every-programmer-should-play-nethack.textile
| └── 2009-04-26-barcamp-boston-4-roundup.textile
├── _data
| └── members.yml
├── _site
├── .jekyll-metadata
└── index.htmlAn overview of what each of these does:
| File / Directory | Description |
|---|---|
|
|
Stores configuration data. Many of these options can be specified from the command line executable but it’s easier to specify them here so you don’t have to remember them. |
|
|
Drafts are unpublished posts. The format of these files is without a
date: |
|
|
These are the partials that can be mixed and matched by your layouts
and posts to facilitate reuse. The liquid tag
|
|
|
These are the templates that wrap posts. Layouts are chosen on a
post-by-post basis in the
YAML Front Matter,
which is described in the next section. The liquid tag
|
|
|
Your dynamic content, so to speak. The naming convention of these
files is important, and must follow the format:
|
|
|
Well-formatted site data should be placed here. The jekyll engine
will autoload all YAML files in this directory (using either the
|
|
|
This is where the generated site will be placed (by default) once
Jekyll is done transforming it. It’s probably a good idea to add this
to your |
|
|
This helps Jekyll keep track of which files have not been modified
since the site was last built, and which files will need to be
regenerated on the next build. This file will not be included in the
generated site. It’s probably a good idea to add this to your
|
|
|
Provided that the file has a YAML Front
Matter section, it will be transformed by Jekyll. The same will
happen for any |
|
Other Files/Folders |
Every other directory and file except for those listed above—such as
|
Jekyll allows you to concoct your sites in any way you can dream up, and it’s
thanks to the powerful and flexible configuration options that this is possible.
These options can either be specified in a _config.yml file placed in your
site’s root directory, or can be specified as flags for the jekyll executable
in the terminal.
The table below lists the available settings for Jekyll, and the various options (specified in the configuration file) and flags (specified on the command-line) that control them.
| Setting | Options and Flags |
|---|---|
|
Site Source Change the directory where Jekyll will read files |
|
|
Site Destination Change the directory where Jekyll will write files |
|
|
Safe |
|
|
Exclude Exclude directories and/or files from the conversion. These exclusions are relative to the site's source directory and cannot be outside the source directory. |
|
|
Include
Force inclusion of directories and/or files in the conversion.
|
|
|
Keep files
When clobbering the site destination, keep the selected files.
Useful for files that are not generated by jekyll; e.g. files or
assets that are generated by your build tool.
The paths are relative to the |
|
|
Time Zone
Set the time zone for site generation. This sets the |
|
|
Encoding
Set the encoding of files by name. Only available for Ruby
1.9 or later).
The default value is |
|
|
Defaults Set defaults for YAML Front Matter variables. |
see below |
The contents of <destination> are automatically
cleaned, by default, when the site is built. Files or folders that are not
created by your site will be removed. Some files could be retained
by specifying them within the <keep_files> configuration directive.
Do not use an important location for <destination>; instead, use it as
a staging area and copy files from there to your web server.
| Setting | Options and Flags |
|---|---|
|
Regeneration Enable auto-regeneration of the site when files are modified. |
|
|
Configuration Specify config files instead of using |
|
|
Drafts Process and render draft posts. |
|
|
Environment Use a specific environment value in the build. |
|
|
Future Publish posts with a future date. |
|
|
LSI Produce an index for related posts. |
|
|
Limit Posts Limit the number of posts to parse and publish. |
|
|
Force polling Force watch to use polling. |
|
|
Verbose output Print verbose output. |
|
|
Silence Output Silence the normal output from Jekyll during a build |
|
|
Incremental build Enable the experimental incremental build feature. Incremental build only re-builds posts and pages that have changed, resulting in significant performance improvements for large sites, but may also break site generation in certain cases. |
|
In addition to the options below, the serve sub-command can accept any of the options
for the build sub-command, which are then applied to the site build which occurs right
before your site is served.
| Setting | Options and Flags |
|---|---|
|
Local Server Port Listen on the given port. |
|
|
Local Server Hostname Listen at the given hostname. |
|
|
Base URL Serve the website from the given base URL |
|
|
Detach Detach the server from the terminal |
|
|
Skips the initial site build. Skips the initial site build which occurs before the server is started. |
|
|
X.509 (SSL) Private Key SSL Private Key. |
|
|
X.509 (SSL) Certificate SSL Public certificate. |
|
This will either lead to parsing errors, or Jekyll will revert to the default settings. Use spaces instead.
You can provide custom headers for your site by adding them to _config.yml
# File: _config.yml
webrick:
headers:
My-Header: My-Value
My-Other-Header: My-Other-ValueWe only provide one default and that’s a Content-Type header that disables caching in development so that you don’t have to fight with Chrome’s aggressive caching when you are in development mode.
In the build (or serve) arguments, you can specify a Jekyll environment and value. The build will then apply this value in any conditional statements in your content.
For example, suppose you set this conditional statement in your code:
{% if jekyll.environment == "production" %}
{% include disqus.html %}
{% endif %}When you build your Jekyll site, the content inside the if statement won’t be run unless you also specify a production environment in the build command, like this:
JEKYLL_ENV=production jekyll buildSpecifying an environment value allows you to make certain content available only within specific environments.
The default value for JEKYLL_ENV is development. Therefore if you omit JEKYLL_ENV from the build arguments, the default value will be JEKYLL_ENV=development. Any content inside {% if jekyll.environment == "development" %} tags will automatically appear in the build.
Your environment values can be anything you want (not just development or production). Some elements you might want to hide in development environments include Disqus comment forms or Google Analytics. Conversely, you might want to expose an “Edit me in GitHub” button in a development environment but not include it in production environments.
By specifying the option in the build command, you avoid having to change values in your configuration files when moving from one environment to another.
Using YAML Front Matter is one way that you can specify configuration in the pages and posts for your site. Setting things like a default layout, or customizing the title, or specifying a more precise date/time for the post can all be added to your page or post front matter.
Often times, you will find that you are repeating a lot of configuration options. Setting the same layout in each file, adding the same category - or categories - to a post, etc. You can even add custom variables like author names, which might be the same for the majority of posts on your blog.
Instead of repeating this configuration each time you create a new post or page, Jekyll provides a way to set these defaults in the site configuration. To do this, you can specify site-wide defaults using the defaults key in the _config.yml file in your projects root directory.
The defaults key holds an array of scope/values pairs that define what defaults should be set for a particular file path, and optionally, a file type in that path.
Let’s say that you want to add a default layout to all pages and posts in your site. You would add this to your _config.yml file:
defaults:
-
scope:
path: "" # an empty string here means all files in the project
values:
layout: "default"Here, we are scoping the values to any file that exists in the scopes path. Since the path is set as an empty string, it will apply to all files in your project. You probably don’t want to set a layout on every file in your project - like css files, for example - so you can also specify a type value under the scope key.
defaults:
-
scope:
path: "" # an empty string here means all files in the project
type: "posts" # previously `post` in Jekyll 2.2.
values:
layout: "default"Now, this will only set the layout for files where the type is posts.
The different types that are available to you are pages, posts, drafts or any collection in your site. While type is optional, you must specify a value for path when creating a scope/values pair.
As mentioned earlier, you can set multiple scope/values pairs for defaults.
defaults:
-
scope:
path: ""
type: "posts"
values:
layout: "my-site"
-
scope:
path: "projects"
type: "pages" # previously `page` in Jekyll 2.2.
values:
layout: "project" # overrides previous default layout
author: "Mr. Hyde"With these defaults, all posts would use the my-site layout. Any html files that exist in the projects/ folder will use the project layout, if it exists. Those files will also have the page.author liquid variable set to Mr. Hyde as well as have the category for the page set to project.
collections:
- my_collection:
output: true
defaults:
-
scope:
path: ""
type: "my_collection" # a collection in your site, in plural form
values:
layout: "default"In this example the layout is set to default inside the collection with the name my_collection.
Jekyll will apply all of the configuration settings you specify in the defaults section of your _config.yml file. However, you can choose to override settings from other scope/values pair by specifying a more specific path for the scope.
You can see that in the second to last example above. First, we set the default layout to my-site. Then, using a more specific path, we set the default layout for files in the projects/ path to project. This can be done with any value that you would set in the page or post front matter.
Finally, if you set defaults in the site configuration by adding a defaults section to your _config.yml file, you can override those settings in a post or page file. All you need to do is specify the settings in the post or page front matter. For example:
# In _config.yml
...
defaults:
-
scope:
path: "projects"
type: "pages"
values:
layout: "project"
author: "Mr. Hyde"
category: "project"
...# In projects/foo_project.md
---
author: "John Smith"
layout: "foobar"
---
The post text goes here...The projects/foo_project.md would have the layout set to foobar instead
of project and the author set to John Smith instead of Mr. Hyde when
the site is built.
Jekyll runs with the following configuration options by default. Alternative settings for these options can be explicitly specified in the configuration file or on the command-line.
Please note that both remove_block_html_tags and
remove_span_html_tags are currently unsupported in Jekyll due
to the fact that they are not included within the kramdown HTML converter.
# Where things are
source: .
destination: ./_site
plugins_dir: ./_plugins
layouts_dir: ./_layouts
data_dir: ./_data
includes_dir: ./_includes
collections: null
# Handling Reading
safe: false
include: [".htaccess"]
exclude: []
keep_files: [".git", ".svn"]
encoding: "utf-8"
markdown_ext: "markdown,mkdown,mkdn,mkd,md"
# Filtering Content
show_drafts: null
limit_posts: 0
future: false
unpublished: false
# Plugins
whitelist: []
gems: []
# Conversion
markdown: kramdown
highlighter: rouge
lsi: false
excerpt_separator: "\n\n"
incremental: false
# Serving
detach: false
port: 4000
host: 127.0.0.1
baseurl: "" # does not include hostname
# Outputting
permalink: date
paginate_path: /page:num
timezone: null
quiet: false
defaults: []
# Markdown Processors
rdiscount:
extensions: []
redcarpet:
extensions: []
kramdown:
auto_ids: true
footnote_nr: 1
entity_output: as_char
toc_levels: 1..6
smart_quotes: lsquo,rsquo,ldquo,rdquo
enable_coderay: false
coderay:
coderay_wrap: div
coderay_line_numbers: inline
coderay_line_number_start: 1
coderay_tab_width: 4
coderay_bold_every: 10
coderay_css: styleThe various Markdown renderers supported by Jekyll sometimes have extra options available.
Redcarpet can be configured by providing an extensions sub-setting, whose
value should be an array of strings. Each string should be the name of one of
the Redcarpet::Markdown class’s extensions; if present in the array, it will
set the corresponding extension to true.
Jekyll handles two special Redcarpet extensions:
no_fenced_code_blocks — By default, Jekyll sets the fenced_code_blocks
extension (for delimiting code blocks with triple tildes or triple backticks)
to true, probably because GitHub’s eager adoption of them is starting to make
them inescapable. Redcarpet’s normal fenced_code_blocks extension is inert
when used with Jekyll; instead, you can use this inverted version of the
extension for disabling fenced code.Note that you can also specify a language for highlighting after the first delimiter:
```ruby
# ...ruby code
```
With both fenced code blocks and highlighter enabled, this will statically
highlight the code; without any syntax highlighter, it will add a
class="LANGUAGE" attribute to the <code> element, which can be used as a
hint by various JavaScript code highlighting libraries.
smart — This pseudo-extension turns on SmartyPants, which converts
straight quotes to curly quotes and runs of hyphens to em (---) and en (--) dashes.All other extensions retain their usual names from Redcarpet, and no renderer
options aside from smart can be specified in Jekyll. A list of available
extensions can be found in the Redcarpet README file.
Make sure you’re looking at the README for the right version of
Redcarpet: Jekyll currently uses v3.2.x. The most commonly used
extensions are:
tablesno_intra_emphasisautolinkIn addition to the defaults mentioned above, you can also turn on recognition
of GitHub Flavored Markdown by passing an input option with a value of “GFM”.
For example, in your _config.yml:
kramdown:
input: GFM
While incremental regeneration will work for the most common cases, it will not work correctly in every scenario. Please be extremely cautious when using the feature, and report any problems not listed below by opening an issue on GitHub.
Incremental regeneration helps shorten build times by only generating documents
and pages that were updated since the previous build. It does this by keeping
track of both file modification times and inter-document dependencies in the
.jekyll-metadata file.
Under the current implementation, incremental regeneration will only generate a
document or page if either it, or one of its dependencies, is modified. Currently,
the only types of dependencies tracked are includes (using the
{% include %} tag) and layouts. This means that plain
references to other documents (for example, the common case of iterating over
site.posts in a post listings page) will not be detected as a dependency.
To remedy some of these shortfalls, putting regenerate: true in the front-matter
of a document will force Jekyll to regenerate it regardless of whether it has been
modified. Note that this will generate the specified document only; references
to other documents’ contents will not work since they won’t be re-rendered.
Incremental regeneration can be enabled via the --incremental flag (-I for
short) from the command-line or by setting incremental: true in your
configuration file.
The front matter is where Jekyll starts to get really cool. Any file that contains a YAML front matter block will be processed by Jekyll as a special file. The front matter must be the first thing in the file and must take the form of valid YAML set between triple-dashed lines. Here is a basic example:
---
layout: post
title: Blogging Like a Hacker
---Between these triple-dashed lines, you can set predefined variables (see below for a reference) or even create custom ones of your own. These variables will then be available to you to access using Liquid tags both further down in the file and also in any layouts or includes that the page or post in question relies on.
If you use UTF-8 encoding, make sure that no BOM header
characters exist in your files or very, very bad things will happen to
Jekyll. This is especially relevant if you’re running
Jekyll on Windows.
If you want to use Liquid tags and variables but don’t need anything in your front matter, just leave it empty! The set of triple-dashed lines with nothing in between will still get Jekyll to process your file. (This is useful for things like CSS and RSS feeds!)
There are a number of predefined global variables that you can set in the front matter of a page or post.
| Variable | Description |
|---|---|
|
|
If set, this specifies the layout file to use. Use the layout file
name without the file extension. Layout files must be placed in the
|
|
|
If you need your processed blog post URLs to be something other than
the site-wide style (default |
|
|
Set to false if you don’t want a specific post to show up when the site is generated. |
|
|
Instead of placing posts inside of folders, you can specify one or more categories that the post belongs to. When the site is generated the post will act as though it had been set with these categories normally. Categories (plural key) can be specified as a YAML list or a comma-separated string. |
|
|
Similar to categories, one or multiple tags can be added to a post. Also like categories, tags can be specified as a YAML list or a comma-separated string. |
Any variables in the front matter that are not predefined are mixed into the data that is sent to the Liquid templating engine during the conversion. For instance, if you set a title, you can use that in your layout to set the page title:
<!DOCTYPE HTML>
<html>
<head>
<title>{{ page.title }}</title>
</head>
<body>
...These are available out-of-the-box to be used in the front matter for a post.
| Variable | Description |
|---|---|
|
|
A date here overrides the date from the name of the post. This can be
used to ensure correct sorting of posts. A date is specified in the
format |
If you don't want to repeat your frequently used front matter variables over and over, just define defaults for them and only override them where necessary (or not at all). This works both for predefined and custom variables.
One of Jekyll’s best aspects is that it is “blog aware”. What does this mean, exactly? Well, simply put, it means that blogging is baked into Jekyll’s functionality. If you write articles and publish them online, this means that you can publish and maintain a blog simply by managing a folder of text-files on your computer. Compared to the hassle of configuring and maintaining databases and web-based CMS systems, this will be a welcome change!
As explained on the directory structure page, the _posts
folder is where your blog posts will live. These files are generally
Markdown or HTML, but can
be other formats with the proper converter installed.
All posts must have YAML Front Matter, and they will be
converted from their source format into an HTML page that is part of your
static site.
To create a new post, all you need to do is create a new file in the _posts
directory. How you name files in this folder is important. Jekyll requires blog
post files to be named according to the following format:
YEAR-MONTH-DAY-title.MARKUPWhere YEAR is a four-digit number, MONTH and DAY are both two-digit
numbers, and MARKUP is the file extension representing the format used in the
file. For example, the following are examples of valid post filenames:
2011-12-31-new-years-eve-is-awesome.md
2012-09-12-how-to-write-a-blog.textile
Use the post_url
tag to link to other posts without having to worry about the URL's
breaking when the site permalink style changes.
All blog post files must begin with YAML Front Matter. After that, it’s simply a matter of deciding which format you prefer. Jekyll supports Markdown out of the box, and has myriad extensions for other formats as well, including the popular Textile format. These formats each have their own way of marking up different types of content within a post, so you should familiarize yourself with these formats and decide which one best suits your needs.
Content processors can modify certain characters to make them look nicer.
For example, the smart extension in Redcarpet converts standard,
ASCII quotation characters to curly, Unicode ones. In order for the browser
to display those characters properly, define the charset meta value by
including <meta charset="utf-8"> in the
<head> of your layout.
Chances are, at some point, you’ll want to include images, downloads, or other digital assets along with your text content. While the syntax for linking to these resources differs between Markdown and Textile, the problem of working out where to store these files in your site is something everyone will face.
Because of Jekyll’s flexibility, there are many solutions to how to do this.
One common solution is to create a folder in the root of the project directory
called something like assets or downloads, into which any images, downloads
or other resources are placed. Then, from within any post, they can be linked
to using the site’s root as the path for the asset to include. Again, this will
depend on the way your site’s (sub)domain and path are configured, but here are
some examples (in Markdown) of how you could do this using the site.url
variable in a post.
Including an image asset in a post:
... which is shown in the screenshot below:
Linking to a PDF for readers to download:
... you can [get the PDF]({{ site.url }}/assets/mydoc.pdf) directly.
You can skip the {{ site.url }} variable
if you know your site will only ever be displayed at the
root URL of your domain. In this case you can reference assets directly with
just /path/file.jpg.
It’s all well and good to have posts in a folder, but a blog is no use unless you have a list of posts somewhere. Creating an index of posts on another page (or in a template) is easy, thanks to the Liquid template language and its tags. Here’s a basic example of how to create a list of links to your blog posts:
<ul>
{% for post in site.posts %}
<li>
<a href="{{ post.url }}">{{ post.title }}</a>
</li>
{% endfor %}
</ul>Of course, you have full control over how (and where) you display your posts, and how you structure your site. You should read more about how templates work with Jekyll if you want to know more.
Note that the post variable only exists inside the for loop above. If
you wish to access the currently-rendering page/posts’s variables (the
variables of the post/page that has the for loop in it), use the page
variable instead.
Each post automatically takes the first block of text, from the beginning of
the content to the first occurrence of excerpt_separator, and sets it as the post.excerpt.
Take the above example of an index of posts. Perhaps you want to include
a little hint about the post’s content by adding the first paragraph of each of
your posts:
<ul>
{% for post in site.posts %}
<li>
<a href="{{ post.url }}">{{ post.title }}</a>
{{ post.excerpt }}
</li>
{% endfor %}
</ul>Because Jekyll grabs the first paragraph you will not need to wrap the excerpt
in p tags, which is already done for you. These tags can be removed with the
following if you’d prefer:
{{ post.excerpt | remove: '<p>' | remove: '</p>' }}If you don’t like the automatically-generated post excerpt, it can be
explicitly overridden by adding an excerpt value to your post’s YAML
Front Matter. Alternatively, you can choose to define a custom
excerpt_separator in the post’s YAML front matter:
---
excerpt_separator: <!--more-->
---
Excerpt
<!--more-->
Out-of-excerptYou can also set the excerpt_separator globally in your _config.yml
configuration file.
Completely disable excerpts by setting your excerpt_separator to "".
Also, as with any output generated by Liquid tags, you can pass the
| strip_html filter to remove any html tags in the output. This is
particularly helpful if you wish to output a post excerpt as a
meta="description" tag within the post head, or anywhere else having
html tags along with the content is not desirable.
Jekyll also has built-in support for syntax highlighting of code snippets using either Pygments or Rouge, and including a code snippet in any post is easy. Just use the dedicated Liquid tag as follows:
{% highlight ruby %}
def show
@widget = Widget(params[:id])
respond_to do |format|
format.html # show.html.erb
format.json { render json: @widget }
end
end
{% endhighlight %}And the output will look like this:
def show
@widget = Widget(params[:id])
respond_to do |format|
format.html # show.html.erb
format.json { render json: @widget }
end
end
You can make code snippets include line-numbers by adding the word
linenos to the end of the opening highlight tag like this:
{% highlight ruby linenos %}.
These basics should be enough to get you started writing your first posts. When you’re ready to dig into what else is possible, you might be interested in doing things like customizing post permalinks or using custom variables in your posts and elsewhere on your site.
Drafts are posts without a date. They’re posts you’re still working on and
don’t want to publish yet. To get up and running with drafts, create a
_drafts folder in your site’s root (as described in the site structure section) and create your
first draft:
|-- _drafts/
| |-- a-draft-post.mdTo preview your site with drafts, simply run jekyll serve or jekyll build
with the --drafts switch. Each will be assigned the value modification time
of the draft file for its date, and thus you will see currently edited drafts
as the latest posts.
In addition to writing posts, another thing you may want to do with your Jekyll site is create static pages. By taking advantage of the way Jekyll copies files and directories, this is easy to do.
Just about every web server configuration you come across will look for an HTML
file called index.html (by convention) in the site’s root folder and display
that as the homepage. Unless the web server you’re using is configured to look
for some different filename as the default, this file will turn into the
homepage of your Jekyll-generated site.
Any HTML file on your site can use layouts and/or includes, even the homepage. Common content, like headers and footers, make excellent candidates for extraction into a layout.
Where you put HTML or Markdown files for pages depends on how you want the pages to work. There are two main ways of creating pages:
Both methods work fine (and can be used in conjunction with each other), with the only real difference being the resulting URLs.
The simplest way of adding a page is just to add an HTML file in the root directory with a suitable name for the page you want to create. For a site with a homepage, an about page, and a contact page, here’s what the root directory and associated URLs might look like:
.
|-- _config.yml
|-- _includes/
|-- _layouts/
|-- _posts/
|-- _site/
|-- about.html # => http://example.com/about.html
|-- index.html # => http://example.com/
|-- other.md # => http://example.com/other.html
└── contact.html # => http://example.com/contact.htmlThere is nothing wrong with the above method. However, some people like to keep
their URLs free from things like filename extensions. To achieve clean URLs for
pages using Jekyll, you simply need to create a folder for each top-level page
you want, and then place an index.html file in each page’s folder. This way
the page URL ends up being the folder name, and the web server will serve up
the respective index.html file. Here’s an example of what this structure
might look like:
.
├── _config.yml
├── _includes/
├── _layouts/
├── _posts/
├── _site/
├── about/
| └── index.html # => http://example.com/about/
├── contact/
| └── index.html # => http://example.com/contact/
|── other/
| └── index.md # => http://example.com/other/
└── index.html # => http://example.com/This approach may not suit everyone, but for people who like clean URLs it’s simple and it works. In the end the decision is yours!
Clean URLs can also be achieved using the permalink front
matter variable. In the example above, using the first method, you can
get URL http://example.com/other for the file
other.md by setting this at the top of the file:
permalink: /other
In addition to renderable and convertible content, we also have static files.
A static file is a file that does not contain any YAML front matter. These include images, PDFs, and other un-rendered content.
They’re accessible in Liquid via site.static_files and contain the
following metadata:
| Variable | Description |
|---|---|
|
The relative path to the file. |
|
The `Time` the file was last modified. |
|
The extension name for the file, e.g.
|
Jekyll traverses your site looking for files to process. Any files with YAML front matter are subject to processing. For each of these files, Jekyll makes a variety of data available via the Liquid templating system. The following is a reference of the available data.
| Variable | Description |
|---|---|
|
Sitewide information + configuration settings from
|
|
Page specific information + the YAML front matter. Custom variables set via the YAML Front Matter will be available here. See below for details. |
|
In layout files, the rendered content of the Post or Page being wrapped. Not defined in Post or Page files. |
|
When the |
| Variable | Description |
|---|---|
|
The current time (when you run the |
|
A list of all Pages. |
|
A reverse chronological list of all Posts. |
|
If the page being processed is a Post, this contains a list of up to ten
related Posts. By default, these are the ten most recent posts.
For high quality but slow to compute results, run the
|
|
A list of all static files (i.e.
files not processed by Jekyll's converters or the Liquid renderer).
Each file has three properties: |
|
A subset of `site.pages` listing those which end in `.html`. |
|
A subset of `site.static_files` listing those which end in `.html`. |
|
A list of all the collections. |
|
A list containing the data loaded from the YAML files located in the |
|
A list of all the documents in every collection. |
|
The list of all Posts in category |
|
The list of all Posts with tag |
|
All the variables set via the command line and your
|
| Variable | Description |
|---|---|
|
The content of the Page, rendered or un-rendered depending upon
what Liquid is being processed and what |
|
The title of the Page. |
|
The un-rendered excerpt of the Page. |
|
The URL of the Post without the domain, but
with a leading slash, e.g.
|
|
The Date assigned to the Post. This can be overridden in a Post’s front
matter by specifying a new date/time in the format
|
|
An identifier unique to the Post (useful in RSS feeds). e.g.
|
|
The list of categories to which this post belongs. Categories are
derived from the directory structure above the |
|
The list of tags to which this post belongs. These can be specified in the YAML Front Matter. |
|
The path to the raw post or page. Example usage: Linking back to the page or post’s source on GitHub. This can be overridden in the YAML Front Matter. |
|
The next post relative to the position of the current post in
|
|
The previous post relative to the position of the current post in
|
Any custom front matter that you specify will be available under
page. For example, if you specify custom_css: true
in a page’s front matter, that value will be available as
page.custom_css.
| Variable | Description |
|---|---|
|
Number of Posts per page. |
|
Posts available for that page. |
|
Total number of Posts. |
|
Total number of Pages. |
|
The number of the current page. |
|
The number of the previous page. |
|
The path to the previous page. |
|
The number of the next page. |
|
The path to the next page. |
These are only available in index files, however they can be located in a
subdirectory, such as /blog/index.html.
This is an experimental feature and the API may change until the feature stabilizes.
Not everything is a post or a page. Maybe you want to document the various methods in your open source project, members of a team, or talks at a conference. Collections allow you to define a new type of document that behave like Pages or Posts do normally, but also have their own unique properties and namespace.
Add the following to your site’s _config.yml file, replacing my_collection
with the name of your collection:
collections:
- my_collectionYou can optionally specify metadata for your collection in the configuration:
collections:
my_collection:
foo: barDefault attributes can also be set for a collection:
defaults:
- scope:
path: ""
type: my_collection
values:
layout: pageCreate a corresponding folder (e.g. <source>/_my_collection) and add
documents. YAML Front Matter is read in as data if it exists, and everything
after it is stuck in the Document’s content attribute. If no YAML Front
Matter is provided, Jekyll will not generate the file in your collection.
The folder must be named identically to the collection you defined in
your _config.yml file, with the addition of the preceding _ character.
If you’d like Jekyll to create a public-facing, rendered version of each
document in your collection, set the output key to true in your collection
metadata in your _config.yml:
collections:
my_collection:
output: trueThis will produce a file for each document in the collection.
For example, if you have _my_collection/some_subdir/some_doc.md,
it will be rendered using Liquid and the Markdown converter of your
choice and written out to <dest>/my_collection/some_subdir/some_doc.html.
As for posts with Permalinks, the document
URL can be customized by setting permalink metadata for the collection:
collections:
my_collection:
output: true
permalink: /awesome/:path/For example, if you have _my_collection/some_subdir/some_doc.md, it will be
written out to <dest>/awesome/some_subdir/some_doc/index.html.
Files in collections that do not have front matter are treated as static files and simply copied to their output location without processing.
| Variable | Description |
|---|---|
|
|
Label of the containing collection. |
|
|
Path to the document relative to the collection's directory. |
|
|
The document's base filename, with every sequence of spaces and non-alphanumeric characters replaced by a hyphen. |
|
|
The document's lowercase title (as defined in its front matter), with every sequence of spaces and non-alphanumeric characters replaced by a hyphen. If the document does not define a title in its front matter, this is equivalent to |
|
|
Extension of the output file. |
Each collection is accessible via the site Liquid variable. For example, if
you want to access the albums collection found in _albums, you’d use
site.albums. Each collection is itself an array of documents
(e.g. site.albums is an array of documents, much like site.pages and
site.posts). See below for how to access attributes of those documents.
The collections are also available under site.collections, with the metadata
you specified in your _config.yml (if present) and the following information:
| Variable | Description |
|---|---|
|
|
The name of your collection, e.g. |
|
|
An array of documents. |
|
|
An array of static files in the collection. |
|
|
The path to the collection's source directory, relative to the site source. |
|
|
The full path to the collections's source directory. |
|
|
Whether the collection's documents will be output as individual files. |
In addition to any YAML Front Matter provided in the document’s corresponding file, each document has the following attributes:
| Variable | Description |
|---|---|
|
|
The (unrendered) content of the document. If no YAML Front Matter is provided, Jekyll will not generate the file in your collection. If YAML Front Matter is used, then this is all the contents of the file after the terminating `---` of the front matter. |
|
|
The rendered output of the document, based on the
|
|
|
The full path to the document's source file. |
|
|
The path to the document's source file relative to the site source. |
|
|
The URL of the rendered collection. The file is only written to the
destination when the name of the collection to which it belongs is
included in the |
|
|
The name of the document's collection. |
Attributes from the YAML front matter can be accessed as data anywhere in the
site. Using the above example for configuring a collection as site.albums,
one might have front matter in an individual file structured as follows (which
must use a supported markup format, and cannot be saved with a .yaml
extension):
title: "Josquin: Missa De beata virgine and Missa Ave maris stella"
artist: "The Tallis Scholars"
director: "Peter Phillips"
works:
- title: "Missa De beata virgine"
composer: "Josquin des Prez"
tracks:
- title: "Kyrie"
duration: "4:25"
- title: "Gloria"
duration: "9:53"
- title: "Credo"
duration: "9:09"
- title: "Sanctus & Benedictus"
duration: "7:47"
- title: "Agnus Dei I, II & III"
duration: "6:49"Every album in the collection could be listed on a single page with a template:
{% for album in site.albums %}
<h2>{{ album.title }}</h2>
<p>Performed by {{ album.artist }}{% if album.director %}, directed by {{ album.director }}{% endif %}</p>
{% for work in album.works %}
<h3>{{ work.title }}</h3>
<p>Composed by {{ work.composer }}</p>
<ul>
{% for track in work.tracks %}
<li>{{ track.title }} ({{ track.duration }})</li>
{% endfor %}
</ul>
{% endfor %}
{% endfor %}In addition to the built-in variables available from Jekyll, you can specify your own custom data that can be accessed via the Liquid templating system.
Jekyll supports loading data from YAML, JSON,
and CSV files located in the _data directory.
Note that CSV files must contain a header row.
This powerful feature allows you to avoid repetition in your templates and to
set site specific options without changing _config.yml.
Plugins/themes can also leverage Data Files to set configuration variables.
As explained on the directory structure page, the _data
folder is where you can store additional data for Jekyll to use when generating
your site. These files must be YAML files
(using either the .yml, .yaml, .json or csv extension) and they will be
accessible via site.data.
Here is a basic example of using Data Files to avoid copy-pasting large chunks of code in your Jekyll templates:
In _data/members.yml:
- name: Tom Preston-Werner
github: mojombo
- name: Parker Moore
github: parkr
- name: Liu Fengyun
github: liufengyunOr _data/members.csv:
name,github
Tom Preston-Werner,mojombo
Parker Moore,parkr
Liu Fengyun,liufengyunThis data can be accessed via site.data.members (notice that the filename
determines the variable name).
You can now render the list of members in a template:
<ul>
{% for member in site.data.members %}
<li>
<a href="https://github.com/{{ member.github }}">
{{ member.name }}
</a>
</li>
{% endfor %}
</ul>Data files can also be placed in sub-folders of the _data folder. Each folder
level will be added to a variable’s namespace. The example below shows how
GitHub organizations could be defined separately in a file under the orgs
folder:
In _data/orgs/jekyll.yml:
username: jekyll
name: Jekyll
members:
- name: Tom Preston-Werner
github: mojombo
- name: Parker Moore
github: parkrIn _data/orgs/doeorg.yml:
username: doeorg
name: Doe Org
members:
- name: John Doe
github: jdoeThe organizations can then be accessed via site.data.orgs, followed by the
file name:
<ul>
{% for org_hash in site.data.orgs %}
{% assign org = org_hash[1] %}
<li>
<a href="https://github.com/{{ org.username }}">
{{ org.name }}
</a>
({{ org.members | size }} members)
</li>
{% endfor %}
</ul>Pages and posts can also access a specific data item. The example below shows how to access a specific item:
_data/people.yml:
dave:
name: David Smith
twitter: DavidSilvaSmithThe author can then be specified as a page variable in a post’s frontmatter:
---
title: sample post
author: dave
---
{% assign author = site.data.people[page.author] %}
<a rel="author"
href="{{ author.twitter }}"
title="{{ author.name }}">
{{ author.name }}
</a>Jekyll provides built-in support for Sass and can work with CoffeeScript via
a Ruby gem. In order to use them, you must first create a file with the
proper extension name (one of .sass, .scss, or .coffee) and start the
file with two lines of triple dashes, like this:
---
---
// start content
.my-definition
font-size: 1.2emJekyll treats these files the same as a regular page, in that the output file
will be placed in the same directory that it came from. For instance, if you
have a file named css/styles.scss in your site’s source folder, Jekyll
will process it and put it in your site’s destination folder under
css/styles.css.
If you are using Mustache
or another JavaScript templating language that conflicts with
the Liquid template syntax, you
will need to place {% raw %} and
{% endraw %} tags around your code.
Jekyll allows you to customize your Sass conversion in certain ways.
Place all your partials in your sass_dir, which defaults to
<source>/_sass. Place your main SCSS or Sass files in the place you want
them to be in the output file, such as <source>/css. For an example, take
a look at this example site using Sass support in Jekyll.
If you are using Sass @import statements, you’ll need to ensure that your
sass_dir is set to the base directory that contains your Sass files. You
can do that thusly:
sass:
sass_dir: _sassThe Sass converter will default the sass_dir configuration option to
_sass.
sass_dir is only used by Sass
Note that the sass_dir becomes the load path for Sass imports,
nothing more. This means that Jekyll does not know about these files
directly, so any files here should not contain the YAML Front Matter as
described above nor will they be transformed as described above. This
folder should only contain imports.
You may also specify the output style with the style option in your
_config.yml file:
sass:
style: compressedThese are passed to Sass, so any output style options Sass supports are valid here, too.
To enable Coffeescript in Jekyll 3.0 and up you must
jekyll-coffeescript gem_config.yml is up-to-date and includes the following:gems:
- jekyll-coffeescriptJekyll uses the Liquid templating language to process templates. All of the standard Liquid tags and filters are supported. Jekyll even adds a few handy filters and tags of its own to make common tasks easier.
| Description | Filter and Output |
|---|---|
|
Date to XML Schema Convert a Date into XML Schema (ISO 8601) format. |
|
|
Date to RFC-822 Format Convert a Date into the RFC-822 format used for RSS feeds. |
|
|
Date to String Convert a date to short format. |
|
|
Date to Long String Format a date to long format. |
|
|
Where Select all the objects in an array where the key has the given value. |
|
|
Group By Group an array's items by a given property. |
|
|
XML Escape Escape some text for use in XML. |
|
|
CGI Escape CGI escape a string for use in a URL. Replaces any special characters with appropriate %XX replacements. |
|
|
URI Escape URI escape a string. |
|
|
Number of Words Count the number of words in some text. |
|
|
Array to Sentence Convert an array into a sentence. Useful for listing tags. |
|
|
Markdownify Convert a Markdown-formatted string into HTML. |
|
|
Smartify Convert "quotes" into “smart quotes.” |
|
|
Converting Sass/SCSS Convert a Sass- or SCSS-formatted string into CSS. |
|
|
Slugify Convert a string into a lowercase URL "slug". See below for options. |
|
|
Data To JSON Convert Hash or Array to JSON. |
|
|
Sort Sort an array. Optional arguments for hashes: 1. property name 2. nils order (first or last). |
|
|
Sample Pick a random value from an array. Optional: pick multiple values. |
|
slugify filterThe slugify filter accepts an option, each specifying what to filter.
The default is default. They are as follows (with what they filter):
none: no charactersraw: spacesdefault: spaces and non-alphanumeric characterspretty: spaces and non-alphanumeric characters except for ._~!$&'()+,;=@If you have small page fragments that you wish to include in multiple places on
your site, you can use the include tag.
{% include footer.html %}Jekyll expects all include files to be placed in an _includes directory at the
root of your source directory. This will embed the contents of
<source>/_includes/footer.html into the calling file.
The name of the file you wish to embed can be literal (as in the example above),
or you can use a variable, using liquid-like variable syntax as in
{% include {{my_variable}} %}.
You can also pass parameters to an include. Omit the quotation marks to send a variable’s value. Liquid curly brackets should not be used here:
{% include footer.html param="value" variable-param=page.variable %}These parameters are available via Liquid in the include:
{{ include.param }}You can also choose to include file fragments relative to the current file:
{% include_relative somedir/footer.html %}You won’t need to place your included content within the _includes directory. Instead,
the inclusion is specifically relative to the file where the tag is being used. For example,
if _posts/2014-09-03-my-file.markdown uses the include_relative tag, the included file
must be within the _posts directory, or one of its subdirectories. You cannot include
files in other locations.
All the other capabilities of the include tag are available to the include_relative tag,
such as using variables.
Jekyll has built in support for syntax highlighting of over 60 languages
thanks to Rouge. Rouge is the default highlighter
in Jekyll 3 and above. To use it in Jekyll 2, set highlighter to rouge
and ensure the rouge gem is installed properly.
Alternatively, you can use Pygments to highlight
your code snippets. To use Pygments, you must have Python installed on your
system, have the pygments.rb gem installed and set highlighter to
pygments in your site’s configuration file. Pygments supports over 100
languages
To render a code block with syntax highlighting, surround your code as follows:
{% highlight ruby %}
def foo
puts 'foo'
end
{% endhighlight %}The argument to the highlight tag (ruby in the example above) is the
language identifier. To find the appropriate identifier to use for the language
you want to highlight, look for the “short name” on the Rouge
wiki
or the Pygments’ Lexers page.
There is a second argument to highlight called linenos that is optional.
Including the linenos argument will force the highlighted code to include line
numbers. For instance, the following code block would include line numbers next
to each line:
{% highlight ruby linenos %}
def foo
puts 'foo'
end
{% endhighlight %}In order for the highlighting to show up, you’ll need to include a highlighting
stylesheet. For an example stylesheet you can look at
syntax.css. These
are the same styles as used by GitHub and you are free to use them for your own
site. If you use linenos, you might want to include an additional CSS class
definition for the .lineno class in syntax.css to distinguish the line
numbers from the highlighted code.
If you would like to include a link to a post on your site, the post_url tag
will generate the correct permalink URL for the post you specify.
{% post_url 2010-07-21-name-of-post %}If you organize your posts in subdirectories, you need to include subdirectory path to the post:
{% post_url /subdir/2010-07-21-name-of-post %}There is no need to include the file extension when using the post_url tag.
You can also use this tag to create a link to a post in Markdown as follows:
[Name of Link]({% post_url 2010-07-21-name-of-post %})Use the gist tag to easily embed a GitHub Gist onto your site. This works
with public or secret gists:
{% gist parkr/931c1c8d465a04042403 %}You may also optionally specify the filename in the gist to display:
{% gist parkr/931c1c8d465a04042403 jekyll-private-gist.markdown %}To use the gist tag, you’ll need to add the
jekyll-gist gem to your project.
Jekyll supports a flexible way to build your site’s URLs. You can specify the
permalinks for your site through the Configuration or in
the YAML Front Matter for each post. You’re free to choose
one of the built-in styles to create your links or craft your own. The default
style is date.
Permalinks are constructed by creating a template URL where dynamic elements
are represented by colon-prefixed keywords. For example, the default date
permalink is defined according to the format /:categories/:year/:month/:day/:title.html.
| Variable | Description |
|---|---|
|
|
Year from the Post’s filename |
|
|
Month from the Post’s filename |
|
|
Month from the Post’s filename without leading zeros. |
|
|
Day from the Post’s filename |
|
|
Day from the Post’s filename without leading zeros. |
|
|
Year from the Post’s filename without the century. |
|
|
Hour of the day, 24-hour clock, zero-padded from the post’s |
|
|
Minute of the hour from the post’s |
|
|
Second of the minute from the post’s |
|
|
Title from the document’s filename. May be overridden via
the document’s |
|
|
Slugified title from the document’s filename ( any character
except numbers and letters is replaced as hyphen ). May be
overridden via the document’s |
|
|
The specified categories for this Post. If a post has multiple
categories, Jekyll will create a hierarchy (e.g. |
While you can specify a custom permalink style using template variables, Jekyll also provides the following built-in styles for convenience.
| Permalink Style | URL Template |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
The permalink configuration setting specifies the permalink style used for
posts. Pages and collections each have their own default permalink style; the
default style for pages is /:path/:basename and the default for collections is
/:collection/:path.
These styles are modified to match the suffix style specified in the post
permalink setting. For example, a permalink style of pretty, which contains a
trailing slash, will update page permalinks to also contain a trailing slash:
/:path/:basename/. A permalink style of date, which contains a trailing
file extension, will update page permalinks to also contain a file extension:
/:path/:basename:output_ext. The same is true for any custom permalink style.
The permalink for an individual page or collection document can always be overridden in the YAML Front Matter for the page or document. Additionally, permalinks for a given collection can be customized in the collections configuration.
Given a post named: /2009-04-29-slap-chop.md
| URL Template | Resulting Permalink URL |
|---|---|
|
None specified, or |
|
|
|
|
|
|
|
|
|
|
|
See extensionless permalinks for details. |
|
Jekyll supports permalinks that contain neither a trailing slash nor a file
extension, but this requires additional support from the web server to properly
serve. When using extensionless permalinks, output files written to disk will
still have the proper file extension (typically .html), so the web server
must be able to map requests without file extensions to these files.
Both GitHub Pages and the Jekyll’s built-in WEBrick server handle these requests properly without any additional work.
With many websites — especially blogs — it’s very common to break the main listing of posts up into smaller lists and display them over multiple pages. Jekyll offers a pagination plugin, so you can automatically generate the appropriate files and folders you need for paginated listings.
For Jekyll 3, include the jekyll-paginate plugin in your Gemfile and in
your _config.yml under gems. For Jekyll 2, this is standard.
Pagination does not work from within Markdown or Textile files from
your Jekyll site. Pagination works when called from within the HTML
file, named index.html, which optionally may reside in and
produce pagination from within a subdirectory, via the
paginate_path configuration value.
To enable pagination for your blog, add a line to the _config.yml file that
specifies how many items should be displayed per page:
paginate: 5The number should be the maximum number of Posts you’d like to be displayed per-page in the generated site.
You may also specify the destination of the pagination pages:
paginate_path: "/blog/page:num/"This will read in blog/index.html, send it each pagination page in Liquid as
paginator and write the output to blog/page:num/, where :num is the
pagination page number, starting with 2. If a site has 12 posts and specifies
paginate: 5, Jekyll will write blog/index.html with the first 5 posts, blog/page2/index.html with the next 5 posts
and blog/page3/index.html with the last 2 posts into the destination
directory.
Setting a permalink in the front matter of your blog page will cause pagination to break. Just omit the permalink.
The pagination plugin exposes the paginator liquid object with the following
attributes:
| Attribute | Description |
|---|---|
|
current page number |
|
number of posts per page |
|
a list of posts for the current page |
|
total number of posts in the site |
|
number of pagination pages |
|
page number of the previous pagination page,
or |
|
path of previous pagination page,
or |
|
page number of the next pagination page,
or |
|
path of next pagination page,
or |
Pagination pages through every post in the posts
variable regardless of variables defined in the YAML Front Matter of
each. It does not currently allow paging over groups of posts linked
by a common tag or category. It cannot include any collection of
documents because it is restricted to posts.
The next thing you need to do is to actually display your posts in a list using
the paginator variable that will now be available to you. You’ll probably
want to do this in one of the main pages of your site. Here’s one example of a
simple way of rendering paginated Posts in a HTML file:
---
layout: default
title: My Blog
---
<!-- This loops through the paginated posts -->
{% for post in paginator.posts %}
<h1><a href="{{ post.url }}">{{ post.title }}</a></h1>
<p class="author">
<span class="date">{{ post.date }}</span>
</p>
<div class="content">
{{ post.content }}
</div>
{% endfor %}
<!-- Pagination links -->
<div class="pagination">
{% if paginator.previous_page %}
<a href="{{ paginator.previous_page_path }}" class="previous">Previous</a>
{% else %}
<span class="previous">Previous</span>
{% endif %}
<span class="page_number ">Page: {{ paginator.page }} of {{ paginator.total_pages }}</span>
{% if paginator.next_page %}
<a href="{{ paginator.next_page_path }}" class="next">Next</a>
{% else %}
<span class="next ">Next</span>
{% endif %}
</div>
Jekyll does not generate a ‘page1’ folder, so the above code will not work
when a /page1 link is produced. See below for a way to handle
this if it’s a problem for you.
The following HTML snippet should handle page one, and render a list of each page with links to all but the current page.
{% if paginator.total_pages > 1 %}
<div class="pagination">
{% if paginator.previous_page %}
<a href="{{ paginator.previous_page_path | prepend: site.baseurl | replace: '//', '/' }}">« Prev</a>
{% else %}
<span>« Prev</span>
{% endif %}
{% for page in (1..paginator.total_pages) %}
{% if page == paginator.page %}
<em>{{ page }}</em>
{% elsif page == 1 %}
<a href="{{ paginator.previous_page_path | prepend: site.baseurl | replace: '//', '/' }}">{{ page }}</a>
{% else %}
<a href="{{ site.paginate_path | prepend: site.baseurl | replace: '//', '/' | replace: ':num', page }}">{{ page }}</a>
{% endif %}
{% endfor %}
{% if paginator.next_page %}
<a href="{{ paginator.next_page_path | prepend: site.baseurl | replace: '//', '/' }}">Next »</a>
{% else %}
<span>Next »</span>
{% endif %}
</div>
{% endif %}Jekyll has a plugin system with hooks that allow you to create custom generated content specific to your site. You can run custom code for your site without having to modify the Jekyll source itself.
GitHub Pages is powered by Jekyll.
However, all Pages sites are generated using the --safe option
to disable custom plugins for security reasons. Unfortunately, this means
your plugins won’t work if you’re deploying to GitHub Pages.
You can still use GitHub Pages to publish your site, but you’ll need to
convert the site locally and push the generated static files to your GitHub
repository instead of the Jekyll source files.
You have 3 options for installing plugins:
_plugins directory. Place your plugins
here. Any file ending in *.rb inside this directory will be loaded before
Jekyll generates your site.In your _config.yml file, add a new array with the key gems and the
values of the gem names of the plugins you’d like to use. An example:
gems: [jekyll-coffeescript, jekyll-watch, jekyll-assets]
# This will require each of these gems automatically.
Then install your plugins using gem install jekyll-coffeescript jekyll-watch jekyll-assets
Add the relevant plugins to a Bundler group in your Gemfile. An
example:
group :jekyll_plugins do
gem "my-jekyll-plugin"
gem "another-jekyll-plugin"
end
Now you need to install all plugins from your Bundler group by running single command bundle install
_plugins, _config.yml and Gemfile
can be used simultaneously
You may use any of the aforementioned plugin options simultaneously in the same site if you so choose. Use of one does not restrict the use of the others.
There are a number of (optional) extra features that Jekyll supports that you may want to install, depending on how you plan to use Jekyll.
Kramdown comes with optional support for LaTeX to PNG rendering via MathJax within math blocks. See the Kramdown documentation on math blocks and math support for more details. MathJax requires you to include JavaScript or CSS to render the LaTeX, e.g.
<script src="http://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML" type="text/javascript"></script>For more information about getting started, check out this excellent blog post.
See the Markdown section on the configuration page for instructions on how to use and configure alternative Markdown processors, as well as how to create custom processors.
If you ever run into problems installing or using Jekyll, here are a few tips that might be of help. If the problem you’re experiencing isn’t covered below, please check out our other help resources as well.
If you are using base-url option like:
jekyll serve --baseurl '/blog'… then make sure that you access the site at:
http://localhost:4000/blog/index.htmlIt won’t work to just access:
http://localhost:4000/blogThe order of precedence for conflicting configuration settings is as follows:
That is: defaults are overridden by options specified in _config.yml,
and flags specified at the command-line will override all other settings
specified elsewhere.
The various markup engines that Jekyll uses may have some issues. This page will document them to help others who may run into the same problems.
The latest version, version 2.0, seems to break the use of {{ in
templates. Unlike previous versions, using {{ in 2.0 triggers the
following error:
'{{' was not properly terminated with regexp: /\}\}/ (Liquid::SyntaxError)Since v1.0.0, Jekyll has had automatically-generated post excerpts. Since
v1.1.0, Jekyll also passes these excerpts through Liquid, which can cause
strange errors where references don’t exist or a tag hasn’t been closed. If you
run into these errors, try setting excerpt_separator: "" in your
_config.yml, or set it to some nonsense string.
If you come across a bug, please create an issue on GitHub describing the problem and any work-arounds you find so we can document it here for others.
You can find a few useful plugins at the following locations:
_pages directory for page files which routes its output relative to the project root..textile files into HTML. Also includes the textilize Liquid filter.<div id="extended"> tag.<picture> element, polyfilled with Scott Jehl’s Picturefill.<picture>, srcset, Imager.js, etc), super-flexible configuration.remote_file_content tag you can fetch the content of a remote file and include it as if you would put the content right into your markdown file yourself. Very useful for including code from github repo’s to always have a current repo version.<figure> elements.site.related_posts to use categories to assess relationship._postfiles directory and {{ postfile }} tag so the files a post refers to will always be right there inside your repo.deploy sub-command to Jekyll.contentful sub-command to Jekyll to import data from Contentful.jekyll build all without leaving vim.If you have a Jekyll plugin that you would like to see added to this list, you should read the contributing page to find out how to make that happen.
Page#dir: ensure it ends in a slash (#4403)Utils.merged_file_read_opts to unify reading & strip the BOM (#4404)Renderer#output_ext: honor folders when looking for ext (#4401)Liquid::Drops instead of Hashes in #to_liquid (#4277)-o option to serve command which opens server URL (#4144)PluginManager to use require_with_graceful_fail for better UX (#4233)#to_h to allow for hash introspection (#4281)clean command (#4177)layout instead of page (#4205)Dir.glob with absolute path to allow special characters in the path (#4150)[@options](https://github.com/options) so that it does not impact Liquid. (#4173)Utils.deep_merge_hashes (#4289)has_yaml_header? should accept files with extraneous spaces (#4290)permalink YAML front matter (#4314)jekyll-docs should be easily release-able (#4152).rake files under lib/tasks (#4282)protect_email to the plugins index. (#4169)jekyll-deploy to list of third-party plugins (#4179)draft_posts to configuration docs (#4251)_assets.md (#4259)jekyll-responsive_image to list of third-party plugins (#4286)jekyll-commonmark to list of third-party plugins (#4299)Convertible#render_liquid should use render! to cause failure on bad Liquid (#4077).jekyll-metadata in non-incremental build (#4079)highlighter config val to kramdown.syntax_highlighter (#4090):title and add :slug which is downcased (#4100)site.posts is now a Collection instead of an Array (#4055).html extension stripping behavior in WEBrick (#3452)site.collections as an array instead of a hash. (#3670)--incremental flag to enable incremental regen (disabled by default) (#4059)site_payload once for all collections (#3204)jekyll docs and optimize external gem handling (#3241)Site#getConverterImpl and call it Site#find_converter_instance (#3240)path Liquid variable in Documents for consistency (#2908)Utils#slugify for any scripts (#3047)output property in front matter (#3172)excerpt_separator functionality (#3274)slugify Liquid filter (#2918)Markdown#matches should avoid regexp (#3321)Utils#slugify (#3321)include tag a teensy bit faster. (#3391)pkill -f jekyll to ways to kill. (#3397)text class from p element (#3440)draft? method to identify if Post is a Draft & expose to Liquid (#3456)String#end_with?("/") instead of regexp when checking paths (#3516)page.meta attribute (#3537)Site to reduce responsibilities. (#3545)bin/jekyll: with no args, exit with exit code 1 (#3619)mtime liquid should return a Time obj (#3596)Jekyll::Posts for both LSI indexing and lookup. (#3629)charset=utf-8 for HTML and XML pages in WEBrick (#3649)Document#to_liquid and invalidate where necessary (#3693)Jekyll::Cleaner#existing_files: Call keep_file_regex and keep_dirs only once, not once per iteration (#3696)jekyll doctor test to detect fsnotify (OSX) anomalies. (#3704)div to figure (#3779)~> 2.6 (#3795)*_dir convention for consistency (#3782)_config.yml for clarity & direction (#3997)post_url: fix access deprecation warning & fix deprecation msg (#4060)time()pre-filter method should accept a Date object (#3299)link in site template (#3236)enable_coderay key instead of use_coderay (#3237)Document output path (#2924):categories) in YAML front matter permalinks (#3320)!important from nav SCSS introduced in #3329 (#3375):title URL placeholder for collections should be the filename slug. (#3383)Site#read_data_file: read CSV’s with proper file encoding (#3455).jekyll-metadata in site template (#3496)/blog baseurl comment (#3485)StaticFile (#3632).jekyll-metadata in binary mode to read binary Marshal data (#3713)ensure in LiquidRenderer (#3811)hl_linenos to hl_lines to allow passthrough in safe mode (#3787)future to false in the default config (#3892)where should compare stringified versions of input & comparator (#3935)jekyll clean command (#3828)>.deep_merge_hashes should also merge default_proc (45f69bb)applies_path? as Strings to avoid confusion (7b81f00)script/test. (#3574)site:publish to fix minor bugs. (#3254)FileList instead of Dir.glob in site:publish rake task (#3261)/tmp, create and symlink a local tmp in the tests (#3258)lib/jekyll/frontmatter_defaults.rb (#3322)regenerate? checking to Regenerator (#3326)read_data_file call to keep things clean (#3380)fixture_site for Document tests (#3511)url.rb to follow GitHub style guide (#3544)activesupport (#3612)Jekyll:StaticFile (#3633)script/rubyprof to generate cachegrind callgraphs (#3692)script/cucumber (#3894)jekyll-thumbnail-filter to list of third-party plugins (#2790)keep_files for destination (#3288, #3296)keep_files and a warning about destination cleaning (#3295)next_section and prev_section navigation items (#3292)jekyll-minifier to list of third-party plugins (#3333)highlight Liquid tag instead of the four-space tabs for code (#3336)twa to the list of third-party plugins (#3384)/ to paginate_path in the Pagination documentation (#3479)picture element spec (#3530)excerpt_separator documentation for clarity (#3550).jekyll-metadata file (#3597)jekyll-files to the list of third-party plugins. (#3586)install step in the CI example .travis.yml (#3622)vendor in the CI docs page (#3623)excerpt_separator documentation that it can be set globally (#3667)remote_file_content tag plugin to list of third-party plugins (#3691)jekyll-asciinema to list of third-party plugins (#3750)site.html_files to variables docs (#3880)jekyll-youtube to the list of third-party plugins (#3931)_config.yml is not reloaded during regeneration (#4034). (#3147)jsonify Liquid filter handling of boolean values (#3154)viewport meta tag (#3170)application/rss+xml (#3176)#as_liquid (#3158)[@alfredxing](https://github.com/alfredxing) to the [@jekyll](https://github.com/jekyll)/core team. :tada: (#3218)-q option for the build and serve commands (#3149)keep_files to configuration documentation (#3162)destination directory (#3161)jekyll-jalali plugin added to the list of third-party plugins. (#3198)inline_highlight plugin to list of third-party plugins (#3212)jekyll-mermaid plugin to list of third-party plugins (#3222)post_url should match post.name instead of slugs and dates (#3058):jekyll_plugins (#3119)^\A (#3089)Conversion error: message in Convertible (#3088)Renderer#convert (#3090)paginate_path example. (#3091)excerpt_separator) (#3094):jekyll_plugins Gemfile group unless JEKYLL_NO_BUNDLER_REQUIRE is specified in the environment. (#2865)Site object (#2882)JEKYLL_LOG_LEVEL. (#3067)where filter. (#2986)page.excerpt if it’s available (#2964)head.html of site template to 2 spaces from 4 (#2973)$content-width variable instead of a fixed value in the site template CSS (#2972)<meta> description. (#2982)head of site template files (#2996)Hash#each_key instead of Hash#keys.each to speed up iteration over hash keys. (#3017)--watch from the site template blog post since it defaults to watching in in 2.4.0 (#2922).htm extensions (#2925)Utils.slugify: Don’t create new objects when gsubbing (#2997)jsonify filter to Hashes deeply and effectively (#3063)127.0.0.1 as default host instead of 0.0.0.0 (#3053)Jekyll::URL.escape_path (#3052)jekyll new --blank in TestUnit (#2913)jekyll new --force logic (#2929)Convertible#transform (#2957)NOKOGIRI_USE_SYSTEM_LIBRARIES=true decreases installation time. (#3040)_config.yml filename fixes (#2911)mathml.rb to the list of third-party plugins. (#2937)--force_polling to the list of configuration options (#2943)--watch. (#2954)--skip-initial-build to configuration docs (#2949)build/serve -V option to configuration documentation (#2948):categories in permalinks (#3011)relative_include tag (#2870)push, pop, unshift, shift (#2895):title to collection URL template fillers (#2864)_data directory (#2761)name variable to collection permalinks (#2799)inspect liquid filter. (#2867)slugify Liquid filter (#2880)Jekyll.sanitized_path when adding static files to Collections (#2849)main.scss in site template (#2771)docs/ dir (#2768)<< self idiom to New command (#2817)_base.scss (#2889)name variable for collection permalinks (#2829)jekyll-projectlist plugin from list of third-party plugins (#2742)markdown-writer package for Atom Editor to list of third-party plugins (#2763)sass_dir note on assets page (#2791)include_relative (#2884)jekyll help command (#2707).scss for site_template styles. (#2667)scope key in front matter defaults (#2659)permalink: pretty in the _config.yml for the site template (#2680)Time.parse into a Utils method (#2682)_posts folder (#2705) REVERTS (#2633)collection.files as StaticFiles (#2737)sassify and scssify Liquid filters (#2739)classifier gem with classifier-reborn (#2721)#to_liquid before calling #to_json in jsonify filter (#2729)strftime to avoid parse string twice (#2673)date front matter value & produce nice error message (#2649)Deprecator#gracefully_require error message (#2694)encoding Option (#2720)Document#to_s should produce just the content of the document (#2731)git diff command in proof script (#2672)latest_version.txt file to the site (#2740)page.content. But more transparent. (#2522)jekyll-slim in list of third-party plugins (#2689)null in YAML instead of nil in default config list (#2719)Jekyll::Tags::IncludeTag#blank? method (#2625)bundle exec in script/proof (#2610)Jekyll::AutolinkEmail and Jekyll::GitMetadata to the list of third-party plugins (#2596)highlight to separate code blocks (#2558)html_pages to Variables docs (#2567)_data directory (#2369)EXCERPT_ATTRIBUTES_FOR_LIQUID (#2408)Jekyll.env and jekyll.environment (the Liquid var) (#2417)_config.yaml or _config.yml (.yml takes precedence) (#2406)_data (#2395)jekyll-paginate (#2455)date_to_rfc822 filter in site template (#2437)gist tag into a separate gem (#2469)collection attribute to Document#to_liquid to access the document’s collection label. (#2436)2.7.6 <= x < 3.0.0 (#2492)/ in the site.html_pages list (#2524)highlight tag use language- prefix in CSS class (#2511)item#to_liquid before #data or #[] in filters (#2493)hl_lines in highlight tag (#2532)--watch flag into a separate gem (#2550)sort filter should sort even if one of the values is nil (#2345)pre code in the site template CSS (#2383)log_level earlier to silence info level configuration output (#2393)title in site template (#2411)Numeric values for dates, not Number values (#2377)keep_files (#2458)https for GitHub links in documentation (#2470)Jekyll::Commands::Build#build (#2554)timezone to America/Los_Angeles (#2394)anchor_links.html (#2368)jekyll_github_sample plugin to list of third-party plugins (#2463)https for GitHub links across whole site (#2470)show_drafts to false in default configuration listing (#2536)url from configuration docs (#2547)permalink setting in site template (#2331)site.name with site.title in site template (#2324)Jekyll::Filters#time now accepts UNIX timestamps in string or number form (#2339)item_property for where filter so it doesn’t break on collections (#2359)--watch doesn’t fail (#2364)baseurl default (#2341)upgrading.md (#2351)History.markdown in order to fix history page in docs (#2363)gist plugin so it always includes the username. (#2314)where filter) features in docs (#2316)kramdown gem instead of maruku gemmercenary (#1706)Post#next or Post#previous (#1983)site.static_files to Liquid (#2075)jekyll new (#2050)relative_permalinks configuration option (default to false) (#2307)fnmatch? (#2303)group_by Liquid filter create lists of items grouped by a common property’s value (#1788)fenced_code_blocks option (#1799)include tag variable arguments to use filters (#1841)post_url tag should raise ArgumentError for invalid name (#1825)mercenary to ~> 0.2.0 (#1879)safe_yaml to ~> 1.0 (#1886)--quiet flag to silence output during build and serve (#1898)where filter to filter arrays based on a key/value pair (#1875)jekyll serve to complete parity with GH Pages servers (#1993).mkdown as valid Markdown extension (#2048)index.xml to the list of WEBrick directory index files (#2041)layouts config key relative to CWD or to source (#2058)~> 1.3 (#1894)self (#2090)nil and error out (#2148)force_polling option to the serve command (#2165)<head> in the site template (#2186)File.exist? instead of deprecated File.exists? (#2214)published: false (#1492)Jekyll::LiquidExtensions with .lookup_variable method for easy looking up of variable values in a Liquid context. (#2253)utf-8 encoding in header for webrick error page response (#2289)site.documents to Liquid payload (list of all docs) (#2295)#path to required methods in Jekyll::Convertible (#1866)jekyll docs to be consistent with other subcommands (#1877)SafeYAML.load to avoid conflicts with other projects (#1982)#path for a draft is now _drafts instead of _posts (#2042)normalize_options method call from bin/jekyll (#2121).+ characters from Pygments lexer names when adding as a CSS class (#994)Post#url and Page#url escape (#1568){% highlight %} block content (#1823)rouge only when it’s been requested as the highlighter (#2189)xml_escape liquid filter) (#2244)highlight tag (#2264)has_yaml_header? (#2310)output to Document liquid output hash (#2309)v1-stable branch (#1836)highlight tag feature (#1859)Forwardable for delegation between Excerpt and Post (#1927)read_things to read_content (#1928)script/branding script for ASCII art lovin’ (#1936)bundle install in travis_retry to retry when RubyGems fails (#2160)Command (#2216)rr link in CONTRIBUTING doc (#2247)jekyll subcommands (#2258)Commands::Serve. (#2269)highlight tag (#2154)Util hash functions with latest from Rails (#2273)site in docs (#1864)<code> tag to context.registers[:site] note (#1867)paginate: nil to default configuration in docs (#1896)<p> tags from excerpt (#1933)docs/sites.md link to GitHub Training materials (#1949)master with the release info from 1.4.3 (#1947)next and previous docs for post layouts and templates (#1970)Writing posts page about how to strip html from excerpt (#1962)jekyll-humanize plugin to plugin list (#1998)jekyll-font-awesome plugin to plugin list (#1999)sublime-jekyll to list of Editor plugins (#2001)vim-jekyll to the list of Editor plugins (#2005)p tags in news_item layout (#2013)site.static_files (#2077)jekyll-image-set to the list of third-party plugins (#2105)jekyll-ordinal to list of third-party plugins (#2150)jekyll_figure to list of third-party plugins (#2158)array_to_sentence_string filter when outputting news item categories (#2191)feed.xml (#2192)jekyll-page-collections to list of third-party plugins (#2215)post_url (#2243)jekyll-live-tiles to list of third-party plugins (#2250)jekyll-help (#2277)site.time for the copyright year. (#2305)where and group_by Liquid filters (#2298)cucumber at 1.3.11 (#2167)toml gem to v0.1.0 to maintain compat with Ruby 1.8.7 (#1778)--prefix option to passthrough for the importers (#1669)--watch on 1.8.7 (#1730)Site#filter_entries into its own object (#1697)Time.now (#1695)jekyll-monthly-archive-plugin and jekyll-category-archive-plugin to list of third-party plugins (#1693)jekyll-asset-path-plugin to list of third-party plugins (#1670)emoji-for-jekyll to list of third-part plugins (#1708)org-mode converter plugin to third-party plugins (#1711)post_url when posts are in subdirectories (#1718)example.com (#1448)_data directory (#1003)include tags (#1495)encoding configuration option (#1449)~> 1.2 (#1610)safe_yaml dependency to ~> 0.9.7 (#1602)json liquid filter to be used in sites (#1651)jekyll-import gem is missing (#1662)pathname require in certain cases (#1255)+ instead of Array#concat when building Post attribute list (#1571)~> 0.6.0 in order to avoid changes in rendering (#1598)include tag (#1490)~> 2.3 (#1608)~> 1.1 (#1604)~> 1.3 (#1607)~> 0.7.0 (#1606)~> 10.1 (#1603)site.rb comments to be more concise/uniform (#1616)JekyllImport::WordPress.process arguments (#1554)jekyll-suggested-tweet to list of third-party plugins (#1555)jekyll-import warning note of missing dependencies (#1626)date_to_string always returns a two digit day (#1663)jekyll serve (#1363)~> 2.3.0 (#1515)>= 2.5.2, < 2.6 (#1536)excerpt_separator is "". (#1386)jekyll doctor (#1389)paginate values (#1390)div.container from the default html template for jekyll new (#1315)-D short-form switch for the drafts option (#1394)jekyll serve from it’s controlling terminal (#1443)jekyll.version variable (#1481)Stevenson#message is nil (#1388)encoding for “mailto”’ errors w/ Ruby 1.8 and Kramdown > 0.14.0 (#1397)--layouts option for build and serve commands (#1458)Site#cleanup into Jekyll::Site::Cleaner class (#1429)_site in jekyllrb.com deploy (#1480)jekyll-ditaa to list of third-party plugins (#1370)postfiles to list of third-party plugins (#1373)/ (#1411)pluralize and reading_time filters to docs (#1439)--config will take multiple files (#1474)site.repository for Jekyll’s GitHub URL (#1463)jekyll-pageless-redirects to list of third-party plugins (#1486)date_to_xmlschema returns an ISO 8601 string (#1488)jekyll-good-include to list of third-party plugins (#1491)jekyll-toc-generator to list of third-party plugins (#1506)table selector from main.css in jekyll new template (#1328)site.pages are sorted alphabetically._drafts directory to the directory structure docs (#1320)include example to an HTML file so as not to indicate that Jekyll will automatically convert them. (#1303)docs subcommand to read Jekyll’s docs when offline. (#1046)include tag (#1204)redcarpet as a runtime dependency so jekyll build works out-of-the-box for new sites. (#1247)related_posts (#1271)<= 1.9.2paginate_path to “Templates” page in docs (#1129)site/img through ImageOptim (thanks @qrush!) (#1208)site/docs/plugins (#1210)site.pages to Variables page in docs (#1251)gist tag supports private gists. (#1248)jekyll-timeago to list of third-party plugins. (#1260)jekyll-swfobject to list of third-party plugins. (#1263)jekyll-picture-tag to list of third-party plugins. (#1280)--force option to jekyll new (#1115)exclude and include options backwards compatible with versions of Jekyll prior to 1.0 (#1114)date_to_rfc822 and uri_escape (#1142)relative_permalinks instructions on Upgrading page (#1101)jekyll doctor command to check site for any known compatibility problems (#1081)data-lang="<lang>" attribute to Redcarpet code blocks (#1066)server_port, match to port if port isn’t set (#1084)relative_permalinks (#1081)toc_token when using generate_tok in RDiscount (#1048)language- class name prefix to code blocks (#1037)</div> to site template used by new subcommand, fixed typos in code (#1032)jekyll new subcommand: generate a Jekyll scaffold (#764)_drafts folder via command line (#833)post_url tag (#998)jekyll new exists and is non-empty (#981)timezone configuration option for compilation (#957)page: page.path (#951)paginator.previous_page_path and paginator.next_page_path (#942)jekyll serve (#847, #871)--limit_posts and --future switches (#788)jekyll server to jekyll serve. (#792)limit_posts option (#1004)--plugins to actually accept dirs and files (#993)jekyll serve (#723)post_url with posts with a time in their YAML front matter (#831)_posts dir correctly, fixes truncation of long post names (#775)new command (#966)--default-mimetype option (#279)post_url Liquid tag for internal post linking (#369)limit_posts (#442)smart_quotes (#482)markdownify filter--no-server option.[no-] functionality for better boolean parsing.--limit-posts cli option (#212)uri_escape filter (#234)--base-url cli option (#235)_includes dir from being a symlinkpage.url to include full relative path (#181)site.time on render not per site_payload invocation (#59)site.pages and site.html_pages variablesDir.pwd (#75)<notextile> tags work once again.#to_s on the err object (@Chrononaut)_posts from being copied to the destination directory (@bdimcheff)site.topics accessor (@baz)array_to_sentence_string filter (@mchung)--server option to start a simple WEBrick server on destination directory (@johnreilly and @mchung)_posts (@mreid)_posts_includes_layouts--rdiscount flagsite.related_posts_includes with {% include x.textile %}--pygments is specified--lsirelated_posts when there is only one post (@JackDanger)\r\n and \n in YAML header (@vanpelt){{ page.url }}