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.
If 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:
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.
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.
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:
Then the following two commands will be equivalent:
For 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:
An 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
We 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:
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:
Specifying 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:
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.
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
.
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
.
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:
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.
The 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:
tables
no_intra_emphasis
autolink
In 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:
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:
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:
Where 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:
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:
Linking to a PDF for readers to download:
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:
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:
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:
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:
You 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:
And the output will look like this:
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:
To 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:
There 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:
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:
You can optionally specify metadata for your collection in the configuration:
Default attributes can also be set for a collection:
Create 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
:
This 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:
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):
Every album in the collection could be listed on a single page with a template:
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
:
Or _data/members.csv
:
This 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:
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
:
In _data/orgs/doeorg.yml
:
The organizations can then be accessed via site.data.orgs
, followed by the
file name:
Pages and posts can also access a specific data item. The example below shows how to access a specific item:
_data/people.yml
:
The author can then be specified as a page variable in a post’s frontmatter:
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:
Jekyll 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:
The 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:
These 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:Jekyll 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.
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:
These parameters are available via Liquid in the include:
You can also choose to include file fragments relative to the current file:
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:
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:
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.
If you organize your posts in subdirectories, you need to include subdirectory path to the 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:
Use the gist
tag to easily embed a GitHub Gist onto your site. This works
with public or secret gists:
You may also optionally specify the filename in the gist to display:
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:
The 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:
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:
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.
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.
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:
… then make sure that you access the site at:
It won’t work to just access:
The 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:
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::Drop
s instead of Hash
es 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::Post
s 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 String
s 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 StaticFile
s (#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.2
paginate_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--lsi
related_posts
when there is only one post (@JackDanger)\r\n
and \n
in YAML header (@vanpelt){{ page.url }}