Documentation from GitHub: https://help.github.com/articles/about-codeowners/
jekyllbot does too much already -- I'd like to see GitHub help us keep organized.
This is also an exercise in logically splitting up the codebase. The build team
is pretty overloaded it looks like -- can we split anything out?
* ashmaroli-ruby-2.4.0:
test with pygments 1.1 on all ruby versions
update rubygems version on travis
use compatible versions of gems
test against ruby-2.4.0
* Update data.feature
- add .tsv
- add .csv with `\t`
- add .csv with `;`
* Fix Appveyor with dst-aware cucumber steps
* Check for given content in posts
* mention Ruby > 2.1.0 in docs
* Update history to reflect merge of #5983 [ci skip]
* Update history to reflect merge of #5961 [ci skip]
* Update data_reader.rb
- add .tsv support with tab separated columns
- not adding support for auto-detecting `:col_sep`
ftp://ftp.iana.org/assignments/media-types/text/tab-separated-values
https://www.ietf.org/rfc/rfc4180.txt (CSV)
https://ruby-doc.org/stdlib-2.4.1/libdoc/csv/rdoc/CSV.html
* Update data.feature
don't do semicolons and tabs in .csv within this patch
* Update data.feature
I don't know which component replaced my tab characters by space before.
* Update data.feature
t
* Update data_reader.rb
add a single space to satisfy format checker
Removed the paragraph telling a user to visit the navigations page to learn how to build more robust navigation.
The permalink was broken since Navigation no longer exists and no other suitable substitute (closest being ./permalinks) fits the description.
I didn't know the difference between cgi_escape and uri_escape until it bit me when I had a colon in a title I used uri_escape on. Addressable::URI.encode (from addressable 2.4.0 and later) thought it was a URI and raised an error. I should have been using cgi_escape, which is for strings that will be added to URIs and not uri_escape, which is for encoding strings that are already in a URI.
This commit borrows from the addressable docs to make it more specific so that readers choose uri_escape when they already have a URI and cgi_escape when they are just escaping a plain string.
Offenses:
test/test_static_file.rb:151:9: C: [Corrected] Style/TrailingCommaInLiteral: Put a comma after the last item of a multiline hash.
"collection" => nil
^^^^^^^^^^^^^^^^^^^^^^
I moved the section about liquid and yaml to the end and shortened it. i also clarified that isn't an order-of-interpretation issue why liquid doesn't render in yaml. I also fixed the type with HMTL.
This tutorial defines Jekyll's "order of interpretation," as @swizca called it in [#5808](https://github.com/jekyll/jekyll/pull/5698). This tutorial makes it clear how Jekyll processes files as it renders the static HTML output.
This order-of-interpretation info is important for troubleshooting and generally understanding Jekyll. It's important to know how Jekyll generates out the files, what rules it uses, what order it processes things, and so forth.
(Note: Please process 5698 before this request, because 5698 includes the tutorial collection/navigation that this tutorial fits into. I also need to update this commit to add a link in the Tutorials nav to this topic, but I'm waiting for 5698 to be merged so that menu becomes available.)
@jekyll/documentation
@dirtyf
* master: (39 commits)
Update history to reflect merge of #5798 [ci skip]
Update history to reflect merge of #5822 [ci skip]
use logger.info
run codeclimate after success
Update history to reflect merge of #5819 [ci skip]
Fixed inaccuracy in "Built-in permalink styles" docs [skip ci]
Update history to reflect merge of #5802 [ci skip]
Update history to reflect merge of #5811 [ci skip]
Update history to reflect merge of #5690 [ci skip]
Update history to reflect merge of #5815 [ci skip]
Review CI pages
Rework CI doc to include multiple providers.
Update history to reflect merge of #5812 [ci skip]
Add jekyll-ga plug-in
Update configuration.md
Add mention of classifier-reborn for LSI
Update history to reflect merge of #5810 [ci skip]
Got that diaper money?
Added note about --blank flag
Update history to reflect merge of #5797 [ci skip]
...
When viewing a page, it's kind of hard to see what page you're viewing. The little triangle graphic pointing to the page is too subtle. Making the link to the current page orange (the same as the hover color) would make it visually more apparent where you are in the navigation. Here's a screenshot showing the change: [https://www.screencast.com/t/e6NKerSAUL](https://www.screencast.com/t/e6NKerSAUL). The link to the current page is orange even when I'm not hovering over the link with my mouse.
Must be either:
> Rather than typing `permalink: /:categories/:year/:month/:day/:title/`, you can just type `permalink: pretty`.
or:
> Rather than typing `permalink: /:categories/:year/:month/:day/:title.html`, you can just type `permalink: date`.
I guess the former was meant to write because the latter was already mentioned in "Where to configure permalinks" section.
If we do a Dir.chdir before Configuration::DEFAULTS is initialized, then its source and destination values will not be what we expect.
We expect that Dir.pwd should stay as the root of the repo but there are some errant calls to Dir.chdir without a block that are still
not yet cleaned up.
1. Addition of *Running Jekyll on Ubuntu* section, to address Ubuntu stumbling block as per https://github.com/jekyll/jekyll/issues/5719.
2. Restructuring, and I hope I understood correctly when NodeJS/Python are/aren't required.
3. Gentler wording – it's probably not a good idea to tell punters who hit this page because they ran into trouble that installing Jekyll *is* easy and straight-forward; it *ought to be* straight-forward. (There's always the potential for pain and confusion if not all dependencies are in place.)
It turns out Liquid throws an error when you write `{% if {{ include.url }} %}` instead of `{% if {{include.url}} %}`. I updated the examples here to omit the spacing. To avoid inconsistency, I just omitted the spacing from all curly braces. Also added a note explaining the issue and put the blame on Liquid.
- made updates from Parkr's review
- update to Extensionless permalinks section
- update to note about not using built-in perm styles in front matter
- update for readability in places
When running 'script/stackprof object', I noticed that it would be helpful to see
GC information. It appears we create a lot of junk -- a source of optimization if
we decide to go down that path.
An average Jekyll build doesn't run a GC, but auto-regeneration likely would eventually
require a GC run and it would be interesting to see if we can reduce how much we throw
away with each call to 'site.process'.
It turns out Liquid throws an error when you write `{% if {{ include.url }} %}` instead of `{% if {{include.url}} %}`. I updated the examples here to omit the spacing. To avoid inconsistency, I just omitted the spacing from all curly braces. Also added a note explaining the issue and put the blame on Liquid.
I added a documentation page on how to build navigation for your site. This topic is primarily intended for users who have a lot of pages on their site (such as for documentation websites), and want to build a more robust sidebar navigation.
Jekyll combines Liquid with YAML in interesting ways that aren't really documented clearly in the existing docs, except for a brief reference [here](http://jekyllrb.com/docs/datafiles/#the-data-folder). You can read about Liquid on Shopify and YAML in YAML's docs, but exactly how you store YAML files in a Jekyll project and iterate through them using Liquid loops and filters to generate lists of pages is something that isn't clear to a lot of people. (You can see origins of these questions in [previous help issues](https://github.com/jekyll/jekyll-help/issues/266).) The documentation on navigation would fit well into the Jekyll docs.
I created more advanced details about includes and created a new page for it instead of putting all the info on the templates page.
See https://github.com/jekyll/jekyll/pull/5630 for more details on the update.
@jekyll/documentation
@DirtyF
Previously, the post_url function would give error messages when the
post being listed contained special characters for use in regular
expressions. These special characters are now escaped using
Regexp.escape.
Prior to the change backticks were used in an attempt to create a
code block. The problem is that inside block level HTML tags Markdown
is not supported. I have replaced the backticks with a combination of
HTML tags in order to approximately simulate the appearance of a code
block. The docs suggest possible use of span tags in place of the
surrounding div tags as a solution to getting the Markdown to render.
I tried this but no success.
This change improves the readers understanding of the information,
because the reader doesn't have to make sense of raw markdown.
In case of the GitHub example links like `<a href="https://github.com/{{ org.username }}">` with the full URL plus the variable were used, but for the Twitter example link only the `{{ author.name }}` was set as `href`.
Adding a link to updated installation instructions for Jekyll 3 and Ruby 2.2.5. These instructions were adapted and significantly updated from the earlier work of Julian Thilo which is now outdated.
Avoiding errors on `jekyll serve`
```
# jekyll serve -H 0.0.0.0
Configuration file: /jekyll-offline-docs/site/_config.yml
Configuration file: /jekyll-offline-docs/site/_config.yml
Source: /jekyll-offline-docs/site
Destination: /jekyll-offline-docs/site/_site
Incremental build: disabled. Enable with --incremental
Generating...
Conversion error: Jekyll::Converters::Scss encountered an error while converting 'css/screen.scss':
Invalid US-ASCII character "\xE2" on line 30
jekyll 3.3.0 | Error: Invalid US-ASCII character "\xE2" on line 30
```
And line 97 when 30 is adjusted...
Added link to my Jekyll plugin: https://github.com/snaptortoise/jekyll-pinboard-plugin. Interfaces with the Pinboard API to make data for specified tags available to the template, sort of similar to the built-in Data Files support.
I was reading through the "Upgrading from 2.x to 3.x" page in the docs and noticed some of the markdown was janky. I made these small edits to fix the formatting and conform with how it's done elsewhere.
- have the new `Metrics/BlockLength` cop ignore test files and
`jekyll/configuration.rb`
- have `AllCops` ignore Jekyll Executable which is not going to be
altered in the near future.
List no longer exists on that page as an id. Basic_components holds the lists now, and at the top conveniently ✌️
I also added a second link under the tags heading.
this cucumber feature follows the likely steps a theme designer would take
to build a Rubygem of his theme starting from the scaffolding generated by
`jekyll new-theme` command and further checks if the gem built actually
has the files he planned to include.
* master:
Update history to reflect merge of #5381 [ci skip]
Update history to reflect merge of #5383 [ci skip]
run features on windows
Appease Rubocop
Update history to reflect merge of #5372 [ci skip]
Add missing period to sentence in first paragraph.
Don't complain about the deprecated `kramdown.coderay` key when
`highlighter == "coderay"`, since that could have been set with the
legitimate `syntax_highlighter: coderay` setting. Instead, complain
only if the `kramdown.coderay` configuration setting is actually
present.
If the theme includes the 'assets' directory, it will be walked and items will be added to the site based
on the normal rules of Jekyll: if there is YAML front matter, it will be added as a (convertible) Page,
otherwise it will be added as a StaticFile.
* jussikinnula-master:
Fix slugify test
One final "urlsafe" replaced with "ascii"
Change urlsafe to ascii also when actually slugifying
Add tests for ascii slugify mode
Rename urlsafe to ascii, and document it (on utils.rb)
Add urlsafe to accepted slugify modes
Add urlsafe method for slugify
Excerpt link reference extraction is missing all the indented references
at the bottom of the page. Markdown specify that those can be indented up
to three spaces.
This increases our ability to detect Windows, and to detect Windows+Bash. It also adds a message to Windows for users who try to "--watch", also noting to to them to check out the Windows ticket so eventually somebody pings us if this issue is fixed. /cc @TAGraves
The link to the scp deploy script was broken - it appears someone
changed the link text and did not update the matching link text in the
markdown footer.
Because the script is really simple, and the script originally linked
includes some unnecessary scss commands, let's just inline the script.
This PR adds a link to [Staticman](https://staticman.net), a free and open source platform to insert user-generated into a Jekyll site by converting entries to data files and pushing them to the repository where the site lives.
Use shared values in YAML so that only certain pieces of .travis.yml need to be updated in order to update Ruby versions. Things should cascade so that if people send a pull request they can update just RVM field.
* DirtyF-doc-link-tag:
templates.md: {% link %} tag only accepts collection documents
add more link tag usage examples
[docs] link tag example for a post
[docs] Document link Liquid tag
Low priority hooks are being run before higher priority hooks. This is easy to
demonstrate with the following plugin:
1.upto(10).each do |n|
Jekyll::Hooks.register :site, :after_reset, priority: Jekyll::Hooks::PRIORITY_MAP[:low] do
puts "Low #{n}"
end
Jekyll::Hooks.register :site, :after_reset, priority: Jekyll::Hooks::PRIORITY_MAP[:normal] do
puts "Normal #{n}"
end
Jekyll::Hooks.register :site, :after_reset, priority: Jekyll::Hooks::PRIORITY_MAP[:high] do
puts "High #{n}"
end
end
Sorting by the negative of the priority and then by the order the hook was
added does the right thing.
simply run the `jekyll` shows
```
A subcommand is required.
jekyll 3.2.1 -- Jekyll is a blog-aware, static site generator in Ruby
```
need subcommand build
* rename variables
* add `default-site` target
* remove `fast_finish` in order to match Travis CI behavior
* run cucumber tests only on the latest Ruby
* master:
Update history to reflect merge of #5156 [ci skip]
Update history to reflect merge of #5177 [ci skip]
Update history to reflect merge of #5173 [ci skip]
Minor updates and corrections
Future True on GitHub Pages note
resolve theme root before sanitizing
dont double sanitize theme folder paths
* master:
Update history to reflect merge of #5152 [ci skip]
Missing trailing |
Update history to reflect merge of #5158 [ci skip]
Also include LICENSE and README
note that themes have been released
Update history to reflect merge of #5143 [ci skip]
Update history to reflect merge of #5150 [ci skip]
Revert "Readability: lib/jekyll/static_file.rb."
include theme directories in default gemspec
[site] enable excerpts
Centre align text and use nav styles on helpful links.
Puns FTW
Add helpful links and minor alignment tweak.
Create error template that has no main nav or footer.
Use more generic wording.
sitemap: false so that the error page is not indexed
Initial 404 page
With gem-based themes being bundled in the new site via the `Gemfile`, we
should ask folks to use Bundler wherever possible. This should lead to more
successful installations and getting the base site setup properly.
The only trouble this introduces is it puts a dependency on Bundler. That
said, I'm totally fine with requiring everyone use Bundler for this site.
How could we best install bundler in these instructions?
/cc @jekyll/documentation
Presently, on a Windows machine, you get an ArgumentError on Windows:
Generating...
C:/Ruby23-x64/lib/ruby/2.3.0/pathname.rb:520:in `relative_path_from':
different prefix: "/" and "C:/Ruby23-x64/lib/ruby/gems/2.3.0/gems/minima-1.0.1" (ArgumentError)
from C:/Ruby23-x64/lib/ruby/gems/2.3.0/gems/jekyll-3.2.0/lib/jekyll/layout.rb:61:in `relative_path'
from C:/Ruby23-x64/lib/ruby/gems/2.3.0/gems/jekyll-3.2.0/lib/jekyll/renderer.rb:161:in `place_in_layouts'
from C:/Ruby23-x64/lib/ruby/gems/2.3.0/gems/jekyll-3.2.0/lib/jekyll/renderer.rb:71:in `run'
This doesn't affect filesystems which do not use drive names.
Instead of matching the the value provided to `post_url` against
the basename, test against the relative path.
Updated the regexp to match both
* _posts/category
* category/_posts
This makes sure that overrides for Jekyll.configuration
all have string keys before their first use, particularly
also the "config" and "skip_config_files" options.
Formingo (https://www.formingo.co) is a new service I'm working on that handles form processing for static websites, such as those generated through Jekyll. Adding it to the list of form services because I believe it'd be a helpful resource and alternative to some of the other listed services.
* master: (41 commits)
Fix rubocop offenses on master.
script/fmt: print Rubocop version
Update history to reflect merge of #5030 [ci skip]
rubocop: separate deprecator error messages
Update history to reflect merge of #5031 [ci skip]
Update history to reflect merge of #5032 [ci skip]
rubocop: fix code style
rubocop: fix code style
rubocop: fix code style
Update history to reflect merge of #5024 [ci skip]
Update history to reflect merge of #5025 [ci skip]
utils: check that the object is a hash when merging default_proc
Update history to reflect merge of #5026 [ci skip]
rubocop: refactor modified? method
Add a benchmark for capture vs. assign in Liquid. [ci skip]
Update history to reflect merge of #5027 [ci skip]
Add generator-jekyllized to third party plugins
rubocop: fix code style
rubocop: fix code style
rubocop: fix code style
...
* master: (22 commits)
Update history to reflect merge of #4980 [ci skip]
werdz
Use jekyll-mentions and restructure
Add post about GSoC project.
Update history to reflect merge of #4976 [ci skip]
Amend WEBrick default headers documentation
Update history to reflect merge of #4966 [ci skip]
.rubocop.yml - remove lib/jekyll.rb
lib/jekyll.rb - fix offenses reported by rubocop method set_timezone is ignored using rubocop:disable Style/AccessorMethodName
Update history to reflect merge of #4977 [ci skip]
Update history to reflect merge of #4962 [ci skip]
Update history to reflect merge of #4959 [ci skip]
Fixed typo
Changed github-gem to github-pages
Included installation instructions
Installation instructions for github-pages gem
Added link to windows doc page
Fix inaccurate HTTP response header field name
Minor tweak to fix missing apostrophne
Feedback for flubbed regex and prefer File's directory check
...
* pathawks-readers:
I will chain blocks if I want to chain blocks.
Rubocop: Readers
Rubocop: lib/jekyll/readers/static_file_reader.rb
Rubocop: lib/jekyll/readers/post_reader.rb
Rubocop: lib/jekyll/readers/page_reader.rb
Rubocop: lib/jekyll/readers/layout_reader.rb
Rubocop: lib/jekyll/reader.rb
* pathawks-rubocop/misc:
Fix Page#relative_path so that it consistently does NOT have the prepending slash (previously inconsistent)
Rubocop cleanup for lib/jekyll/layout.rb
Rubocop cleanup for lib/jekyll/plugin_manager.rb
Rubocop cleanup for lib/jekyll/page.rb
* master: (38 commits)
Mention where it came from. [ci skip]
Update history to reflect merge of #4944 [ci skip]
Update history to reflect merge of #4943 [ci skip]
Mention where it came from. [ci skip]
Update history to reflect merge of #4942 [ci skip]
Update history to reflect merge of #4941
External: remove &block arg, use block_given?
Update history to reflect merge of #4936 [ci skip]
lib/jekyll.rb: require document_drop to ease our pain
Sort the results of the require_all glob.
Rubocop fixes
Reset {{ layout }} between each render & merge layout data properly
Add failing test for layout data inheritance bug (#4433)
Add failing test for layout bug (#4897)
Fix tests for plugins in configuration.
Define Drop#each so we can use the new frozen/duping behavior
Don't default 'include' and 'exclude' to an empty array
Fix some minor things in the tests
Freeze configuration defaults & duplicate in deep_merge_hashes if need be.
Remove merge conflicts I forgot to fix.
...
* pathawks-fp/ExcerptDrop:
Rubocop fixes
excerpt drop should give access to document's layout
look up the content methods for drops in a smarter way
Use require_relative
Add ExcerptDrop and remove excerpt's ability to refer to itself in Liquid
Previously you could do, e.g. {{ site | jsonify }}, but with the introduction of Liquid Drops, this didn't work anymore.
This PR adds the ability to render drops as JSON. You can safely run drop.to_json and it should Do the Right Thing.
Filesystems behave differently when performing glob listings.
In my environment, they are listed alphabetically. On my Mac, when asking for a list of files in a directory, those files are returned as a nicely sorted list. Alphabetized, like you'd want them to be. Like you'd expect them to be.
In some environments, quite different from my own, the return of a similar operation is quite random. Perhaps q comes before a, or e before d; the filesystem will choose its order of the day and you, the fare user, tired and weary from work, must bare the brunt of this.
And so, with this commit, I do hereby request that the noble makers of Dir[] provide for us, the downtrodden and ravaged users, some consistency. As a user of Ruby, I shouldn't have to know or consider the behaviour of an individual filesystem here; it should function the same for all filesystems.
Truly yours,
Parker
This process streamlines the creation of new configurations. Creating a new
site will choke if not all the correct options are given.
Configuration.from will ensure the overrides have all string keys and
ensures all the common issues & defaults are in place so a Site can be
created.
A common use:
config = Configuration.from({ 'permalink' => '/:title/' }) # etc
site = Jekyll::Site.new(config)
This commit cleans up rubocop violations for the following files:
test/test_ansi.rb
test/test_cleaner.rb
test/test_coffeescript.rb
test/test_collections.rb
test/test_command.rb
test/test_commands_serve.rb
* Allow users to filter directories by ending their path with "/"
* Allow users to filter with a Regexp, some scenariors can really require it.
* Use Pathutil#in_path? for Symlink verification, it real/expand.
This also requires some downstream work in "jekyll-watch" which at this time is
not very robust, it doesn't recognize the difference either, and should probably
start doing so (what I mean is detecting "/" and using the full path.)
Jade has been moved to Pug https://github.com/pugjs/pug
This was forked from the previous Jade plugin and merged the pug update to maintain the newer version and avoid deprecation usage.
When it comes to bundler it's smart enough to know what to require, and in casees it's not, it's smart enough to accept :require. In most cases when bundler has a LoadError (or otherwise) it's because there is a problem inside of the Gem itself and when this happens, Jekyll will happily let that error slip when it shouldn't, resulting in a badly placed error that is actually wrong. This corrects that so errors can surface properly.
* Link to jekyllrb.com as @parkr suggested.
* Add a few more directions and hints for Github Pages users who have errors.
* Add words that were missing and made stuff make no sense.
This makes the issue template more robust, making check boxes so users can submit and check or check as they go. It also starts using HTML comments so that directions for the users aren't always displayed to us (gotta love Markdown.) And provides the users with more hints on what we would like from them when filing a ticket.
Previously we relied on the Git version of Rubocop so that we could get 2.3+ and TargetVersion support in our .rubocop.yml, they have since updated stable and made this available to the general public.
* master: (58 commits)
Update history to reflect merge of #4792 [ci skip]
Update history to reflect merge of #4793 [ci skip]
Update history to reflect merge of #4804 [ci skip]
Update history to reflect merge of #4754 [ci skip]
Update history to reflect merge of #4813 [ci skip]
Added missing single quote on rsync client side command
Add v3.0.4 and v3.1.3 to the history.
Fixed typo
Add jekyll-autoprefixer plugin
Explicitly require Filters rather than implicitly.
Update history to reflect merge of #4786 [ci skip]
Update history to reflect merge of #4789 [ci skip]
updates example domain in config template
Globalize Jekyll's Filters.
Update JRuby to 9.0.5.0; Drop the double digit test.
Update Rack-Jekyll Heroku deployment blog post url
convertible: use Document::YAML_FRONT_MATTER_REGEXP to parse transformable files
Update history to reflect merge of #4734 [ci skip]
Update history to reflect merge of #4478 [ci skip]
Fix rubocop warning.
...
As it stands Jekyll does not globalize it's filters. So anybody wishing to go
into Jekyll's context to process their own Liquid (say in a plugin) may be taken
aback when they find out that Jekyll's filters are not available.
See: jekyll/jekyll-assets#252.
This commit introduces a where_exp filter, which can be used as follows:
`{{ array | where_exp: "item", "item == 10" }}`
`{{ array | where_exp: "item", "item.field > 10" }}`
`{{ site.posts | where_exp: "post", "post contains 'field'" }}`
`{{ site.posts | where_exp: "post", "post.array contains 'giraffes'" }}`
This permits a variety of use cases, such as reported in: jekyll#4467,
jekyll#4385, jekyll#2787.
It seems that Travis has made available 2.1.10 which is for double digit testing but skipped 2.1.10 (for some reason.) This reverts us back to 2.1.8 so that we can maintain a working build since we are triggering no known bugs in 2.1 at this time.
Update Rake and disable verbosity when running the specs because we have some
deprecated usage (for now -- however, see: jekyll/jekyll#4719) and because
Rouge, and Liquid throw out thousands (probably hyperbolic) of warnigns when the
specs are being ran. We need upstream to fix their problems while we fix ours
or we'll all have a bad day, not that we aren't already.
As it was we assumed that any system that wasn't Windows or OS X must be Linux
but the reality of that can be very unlikely. BSD is popular in some places and
it's not Linux and this would cause an error there. If we do not know the
launcher for a platform we should ship an error and have the user file
a bug if they feel it necessary and skip the launch otherwise.
* origin/master: (65 commits)
Update history to reflect merge of #4703 [ci skip]
Update history to reflect merge of #4712 [ci skip]
Highlight the test code
Update history to reflect merge of #4640 [ci skip]
readded "env=prod"-condition
Update history to reflect merge of #3849 [ci skip]
Update history to reflect merge of #4624 [ci skip]
Update history to reflect merge of #4704 [ci skip]
Update history to reflect merge of #4706 [ci skip]
Checks for link file extension in tests
Updating assets documentation
Fix test teardown for cleaner.
Update history to reflect merge of #4542 [ci skip]
Add explanation of site variables in the example _config.yml
Use double quotes in the gemfile
Add test for creation of Gemfile by 'jekyll new'
Add comment about github-pages
Update history to reflect merge of #4533 [ci skip]
Ensure Rouge closes its div/figure properly after highlighting ends.
Add Site#config= which can be used to set the config
...
This removes the following warnings:
- /lib/jekyll/configuration.rb:151: warning: instance variable @default_config_file not initialized
- /lib/jekyll/converter.rb:12: warning: instance variable @highlighter_prefix not initialized
- /lib/jekyll/converter.rb:24: warning: instance variable @highlighter_suffix not initialized
- /lib/jekyll/converters/markdown.rb:9: warning: instance variable @setup not initialized
- /lib/jekyll/converters/markdown/kramdown_parser.rb:60: warning: instance variable @highlighter not initialized
- /lib/jekyll/frontmatter_defaults.rb:97: warning: shadowing outer local variable - path
- /lib/jekyll/plugin.rb:66: warning: instance variable @safe not initialized
- /lib/jekyll/regenerator.rb:147: warning: instance variable @disabled not initialized
- /test/test_convertible.rb:40: warning: ambiguous first argument; put parentheses or a space even after `/' operator
- /test/test_filters.rb:154: warning: ambiguous first argument; put parentheses or a space even after `/' operator
- /test/test_new_command.rb:84: warning: ambiguous first argument; put parentheses or a space even after `/' operator
- /test/test_site.rb:234: warning: assigned but unused variable - site
- /test/test_site.rb:240: warning: assigned but unused variable - site
- /test/test_site.rb:522: warning: assigned but unused variable - source
- /test/test_tags.rb:153: warning: ambiguous first argument; put parentheses or a space even after `/' operator
- /test/test_tags.rb:425: warning: ambiguous first argument; put parentheses or a space even after `/' operator
- /test/test_tags.rb:449: warning: ambiguous first argument; put parentheses or a space even after `/' operator
- /test/test_tags.rb:496: warning: ambiguous first argument; put parentheses or a space even after `/' operator
- /test/test_tags.rb:496: warning: instance variable @result not initialized
- /test/test_tags.rb:511: warning: ambiguous first argument; put parentheses or a space even after `/' operator
- /test/test_tags.rb:773: warning: ambiguous first argument; put parentheses or a space even after `/' operator
- /test/test_tags.rb:773: warning: instance variable @result not initialized
- /test/test_tags.rb:788: warning: ambiguous first argument; put parentheses or a space even after `/' operator
- /test/test_url.rb:66: warning: shadowing outer local variable - doc
- /lib/jekyll/url.rb:119:in `escape_path': warning: URI.escape is obsolete
Just because developer are lazy and tools like this is for move forward faster, normally we don't read (it's a fact) and because of that I missed this super important sentence. At least this should help.
After running:
sudo dnf install ruby ruby-devel rubygems nodejs
sudo dnf group install "C Development and Tools"
I was unable to install Jekyll via `gem` due to an error:
The compiler failed to generate an executable file. (RuntimeError) You have to install development tools first.
Taken from the [fedoraproject.org](https://developer.fedoraproject.org/tech/languages/ruby/gems-installation.html) Gem page:
>If you installed all the above, but the extensions would still not compile, you are probably running a Fedora image that misses `redhat-rpm-config` >package. In that case gcc compiler would complain about one of the following:
gcc: error: conftest.c: No such file or directory
gcc: error: /usr/lib/rpm/redhat/redhat-hardened-cc1: No such file or directory
>To solve this, simply run sudo dnf install `redhat-rpm-config`.
After doing so it downloaded, compiled and installed without a problem.
I followed the troubleshooting and came up with `sudo gem install jekyll` unable to generate the binary file because the development libraries were not installed on my system. Per [fedoraproject.org -- Gems](https://developer.fedoraproject.org/tech/languages/ruby/gems-installation.html) this is necessary to install this. The instructions mirror what is listed on that page, but using `yum` instead of `dnf` - which is understandable because RH and CentOS still use `yum`.
PR #2895 merged this in, but there isn't any documentation anywhere for this as far as I can find. All the Stack Overflow answers I could find said it was impossible to push and pop elements from a Liquid array, although that's probably because they were using Shopify's Liquid.
Fixes https://github.com/jekyll/jekyll/pull/4384
Prior to this change, the related posts for the most recently rendered post
stayed set on the `site` object. This could result in pages that showed related
posts even when the page represented an entire collection of posts, such as on
an index page. This change restores the functionality from Jekyll V2.
"Upgrading Documentation" reads to me like "upgrading the documentation" rather than "documentation for upgrading".
There's a link in the site navigation to documentation, but seems worth a mention here, even though the Google option will often bring one to it. 😄
Previously `titleize` used `capitalize!` which has the side effect of
returning `nil` for anything already starting with a capital letter. This
commit changes it to just `capitalize`.
Example, before:
A file "2016-01-01-This-is-a-title-with-Capitals.markdown" would return "Is A
Title With" for `post.title`
Example, after:
A file "2016-01-01-This-is-a-title-with-Capitals.markdown" will return "This Is A
Title With Capitals" for `post.title`
Tests added for `titleize_slug` in test_utils.rb
Fix problem introduced in 67f842546e
References #4525
The Contributor Code of Conduct is now at version 1.3.0 and has several
changes. Many of these are simply wording changes, but an important note
is added that project maintainers must maintain confidentiality when
dealing with any code of conduct violations. Additionally, a note is
added that states violations will be investigated and dealt with in a
way that is deemed necessary and appropriate based on the circumstances.
Signed-off-by: David Celis <me@davidcel.is>
Previously, even if the document permalink was a folder, it would look for
an extension on that. For example, if I have:
permalink: "/new-version-jekyll-v3.0.0/"
the output_ext would be ".0". Now, the output_ext honors the trailing
slash and will report based on the converters instead.
* 'master' of github.com:jekyll/jekyll:
Make our .travis.yml a little easier to maintain.
Update History.markdown to reflect the merger of #4394
Minor spelling error
This reverts a bit of the work @willnorris had made to support
extensionless permalinks. Using the ‘permalink’ front matter will no
longer work as it must allow non-html extensions to be written.
Nearly every day, when I get the report of visitors to jekyllrb.com, I see jmcglone's excellent guide. Reading through it today makes me think it is one of the finest if not _the_ finest guide to getting started with Git, GitHub, and Jekyll in order to publish successfully and happily on GitHub Pages.
@jmcglone, mind if I add this to our GitHub Pages doc page?
The problem last time was that we removed Pry and Pry brings in CodeRay, we were
testing legacy stuff and didn't have CodeRay in our dependencies, which resulted
in those tests failing.
This also quietly announces the intention to move to RSpec by moving the old
test dependencies to ":test_legacy" and is slightly less agressive in it's
organization than before.
* Move step_definitions/jekyll.rb to just step_definitions.rb
* Rename the formatter to Jekyll::Cucumber::Formatter, it's Jekyll's.
* Add some flair; switch to checks!
* Rename env.rb to helpers.rb
* Remove invoked dynamic, it slows down Ruby.
* Remove ObjectSpace which slows down JRuby, we use inheritance now.
* Remove the compat version 9K is Ruby2 by default.
* Removes posix-spawn in favor of Open3#popen3
* Encapsulates all the paths into a single easy class.
* Moves to %r{} to avoid ambiguious warnings per-Cucumber suggestion.
* Starts passing around Pathname to make some actions faster.
* Clean's up some methods to make them easier to read.
* AUTOMATIC: Add "#" between each method.
Occasionally, extra spaces at the end of the YAML front matter prologue are
saved to a file and it goes missing without telling the user why. This
should simply accept those changes without any detriment to the user,
allowing anyone to add as many spaces as they like to the end of their
front matter prologues.
- Trailing whitespace detected
Rubocop: Style/EmptyLines
- Extra blank line detected
Rubocop: Style/EmptyLinesAroundBlockBody
- Extra empty line detected at block body beginning
- Pass &:to_sym as an argument to map instead of a block
- Pass &:capitalize as an argument to select instead of a block
- Pass &:to_s as an argument to map instead of a block
We should handle extend self and module_function on a case-by-case basis because there
are times when extend self is useful, especially when you wish a module to be included but also
available on itself. `module_function` does not allow this.
Move require "jekyll/drops/drop" to "jekyll.rb"
Linux does not read files in alphanumeric order, this can lead to
Jekyll drops not working on Linux because the assumption here is that
the collection drop will be required first.
Linux does not read files in alphanumeric order, this can lead to
Jekyll drops not working on Linux because the assumption here is that
the collection drop will be required first.
* fixup-custom-markdown:
markdown: minor style fixes
Add support for underscores.
Refactor: lib/jekyll/convertor/markdown.rb - tests: no additions/breaks.
The properties of Liquid::Drops are only evaluated when they're asked for
and therefore save computation time. This prevents a lot of GC time cleaning
up objects that are not needed, because they're not created unless requested.
Additionally, this saves time for actual computation of those values because
they can be computed only if needed.
It's funny how much it helps when you only do what is needed. Far less overhead.
* akoeplinger-doctor-permalink-same-case-warning:
Added tests for new jekyll doctor warning
Incorporate code review feedback
Incorporate code review feedback
Add a Jekyll doctor warning for URLs that only differ by case
https://github.com/jekyll/jekyll/pull/4243 updated this link to a jekyll-specific page. This commit adds utm params to the link so we can tell that users came to us from the Jekyll documentation. Among other things, this will help us provide better support to Jekyll users who sign up, since we'll know what site generator they're using.
Add a default charset to content-type on webrick, using Jekyll's
default encoding (or user set encoding) and cleanup servlet removing
unecessary logic that really served no purpose at the end of the
day, we don't need to strictly match Nginx, only be "like it."
This also cleans up the way we set headers and merges that logic
into a cleaner to understand interface that is slightly speedier.
* Add support for SSL through command line switches.
* Add suppport for file/index.html > file.html > directory.
* Add support for custom-headers through configuration.
* Modernize and split up the serve.
* Add a few basic tests.
I have written a liquid filter to make email protection for static websites easy. This plugin contains the `protect_email` filter which encodes email addresses similar to the way GitHub does for the user profiles.
which works the same way as Dir.glob but seperating the input
into two parts ('dir' + '/' + 'pattern') to make sure
the first part('dir') does not act as a pattern.
I have created a Jekyll 3.0-compatible plugin for multilingual websites which is capable of creating multiple translations for one page or post. Beware that this plugin extends the `PageReader` and `PostReader` as well as `Page` and `Document` classes.
- add site post_render hook, which was documented but wasn't being
called
- define documents post_init hook, which was documented but caused an
error when called (fixes#4102)
- add docs for site post_read hook, which was being called but wasn't
documented
- fix container name in example: s/post/posts/
Disable the feature as it's still not 100% working 100% of the time. Feature
can be re-enabled by specifying `full_rebuild: false` in the configuration
Fix the code coverage reporting when using `.bundle` to store my gems in
by having SimpleCov ignore that directory. Use of `.bundle` to store my
gems consolidates things since since that directory also holds the
bundler config file. It also keeps a `vendor` directory out of the
project tree for non-Rails projects. Simplecov was not ignoring that
directory though, which meant that the code coverage numbers I were
seeing locally were wrong (and very frightening). With this change, all
is right with the world once again. 😃
A raw regular expression isn't very expressive, IMHO. Rather than having
people who read this code parse the regular expression to figure out
what it's for, let's give a name. This way, it becomes more obvious what
exactly it is we're doing here.
Following what the documentation specify above for the pretty permalink format (`/:categories/:year/:month/:day/:title/`), it should result for the example to `/2009/04/29/slap-chop/` and not `/2009/04/29/slap-chop/index.html`. Well, at least if I've understood correctly ;-)
When a post does not contain an excerpt_separator, meaning the excerpt
includes the entire post, the excerpt should contain exactly the post
content.
This is desirable both from a correctness standpoint, that the excerpt
should not introduce any new content, and more practically to allow fast
and easy detection of whole-post excerpts in Liquid templates using
`post.excerpt == post.content`. A common use-case is deciding whether
to render "Read More" links on a page containing post excerpts.
This commit does exactly that. It avoids adding additional newlines to
the excerpt content when the excerpt includes the whole post and adds
tests to ensure that this behavior is correct and preserved going
forward.
Signed-off-by: Kevin Locke <kevin@kevinlocke.name>
The first thing new users to Jekyll do is open _config.yml, so this
change adds a simple welcome message to the top of it. Additionally,
it informs the user that the file is not automatically reloaded when
changed, which is a point of confusion for new users.
Related issue: https://github.com/jekyll/jekyll/issues/2302
Non-string input was being missed as a result of poor comparison.
Converting inputs to strings ensure numerical and boolean values are
properly compared.
Fixes#3911.
Add in references to _data format and extension options of .csv, .json,
etc., consistent with _docs/datafiles.md
Signed-off-by: Parker Moore <parkrmoore@gmail.com>
A week ago, I asked @parkr via email if he could add my site here (mostly because I thought it's too cheeky to just propose a file-change). But now he told me that it's better to just do it here:
I'm asking because I spend a huge amount of time and effort on making it great and usefully structured for people who're just getting started with Jekyll. Therefore it's also great as a forked starting-point, if you ask me.
Besides keeping the code clean, I also spend much time on making the site as fast as possible. There's not much CSS in use, the HTML output is minified and images are directly served from the repo (and therefore GitHub's CDN) instead of from third-party services. There's also a lot of "include"-thinking happening for things like embedded Tweets, images or iFrames - which most people just inline in each post.
When making a significant change, I also always make sure to write a few paragraphs about why I exactly did it as a commit message. And when it comes to really big updates, I write entire posts too (explaining all improvements and their benefits to the site's performance/look). Here's an recent example: http://leo.github.io/notes/v2/
I'm definitely sure that many people could get something out of it. Don't you think so too?
Extended documentation on rsync-approach. It also mentions rrsync wrapper script which restricts access for rsync to the server. Based on my blog post here: http://vrepin.org/vr/JekyllDeploy/
Restored previous version of 'Rsync' section and renamed it to 'scp' to reflect the content
Misspelling corrected: authorized_keys, not auhorized_key
Even though JRuby 9K on Travis still apparently points to pre1 we are updating so that when it finally points to stable release we can get those builds, once jruby-head diverges enough again we will re-add it to the list and start testing the next build and move JRuby 9K. Remember though, JRuby support is still experimental.
This enables files such as images and PDFs to show up in the same relative
output directory as other HTML and Markdown documents in the same collection.
It also enables static files to be hidden using defaults from _config.yml in
the same way that other documents in the same collection and directories may
be hidden using `published: false`.
However, because JRuby stable does not support 2.0/21 mode on Travis (reliably as far as I'm aware) we only test on JRuby-head right now because we have dropped support for any EOL Ruby and master contains some code that might or might not fail out on 1.9.
- hooks are registered to symbol owners rather than classes directly
- during registration, add the ability to specify owner as an array to
register the same hook to multiple owners
- add optional priority during registration as a symbol (:low, :normal,
:high)
- implement hooks for collections as they are in octopress-hooks, aside
from post_init
* jaybe-jekyll-patch-1:
Reformat note in pagination docs to use proper HTML. Ref #3467
Clarify pagination file index.html may reside in subdirectory
Update pagination.md - Clarify only index.html
Clarify pagination works from within HTML files
*Note*: Please release a new gem version of jekyll after merging this.
More information at:
http://osvdb.org/show/osvdb/120415
`redcarpet Gem for Ruby contains a flaw that allows a cross-site scripting (XSS) attack. This flaw exists because the parse_inline() function in markdown.c does not validate input before returning it to users. This may allow a remote attacker to create a specially crafted request that would execute arbitrary script code in a user's browser session within the trust relationship between their browser and the server.`
9fc00d08148e707ebb94http://social.schiessle.org/display/b38b1460c2b201329b1f4860008dbc6chttps://gemnasium.com/gems/redcarpet/versions/3.2.3
/cc @parkr @envygeeks
* davidsilvasmith-origin/patch-3:
docs: remove extraneous period from datafiles example.
updated lsi docs
changed the codefile name
forgot a tick around a codefile name
proofed changes
removed personal link
How to access a specific item in the data folder
when the default_proc was being assigned, it failed if it wasn't a Hash. We
expect data to be a Hash everywhere, so let's freak out if it isn't after
reading and applying the fallback.
Fixes#3643.
* chrisfinazzo-upgrading-docs:
Add further fixes to upgrade doc. #3607
Use the new commands
Fix a typo, wrap lines
Remove reference to the watch command
Start working on an upgrade guide for Jekyll 3
When looking for related posts, Jekyll was indexing `Jekyll::Post`
objects, but finding related posts based on `Jekyll::Post#content`. This
caused two problems:
1. Ruby 2.2 will warn on == if <=> throws an exception (and future Ruby
versions will surface that exception). Because `String`s can't be
compared with `Jekyll::Post`s, this warning was appearing all the time
while searching for related posts.
2. LSI won't return a post itself when searching for related posts. But
LSI could never tell that we were searching on a post, since Jekyll
passed post content, not a post object. With this fix, we can remove the
`- [post]` from `Jekyll::RelatedPosts#find_related`.
This is a more accurate fix for #3484.
Clean up the destination modified check in `source_modified_or_dest_missing?` to be easier to read. Note that it can now return `nil` instead of `false` for an unmodified `source_path` and a `nil` `dest_path`, but in a discussion on 706007ead9 we decided that was okay.
When adding a dependency, also add the dependency to the metadata hash.
Addresses part 1 of #3591. Prior to this fix, the regnerator only paid attention the mtime of the first dependency it checked, so for posts/pages with N multiple dependencies (i.e., every layout file used to render them), it continues to regenerate the post/page approximately N times, at which point it's seen all of the dependencies.
Two tests for the regenerator cache clearing changes:
1. Intrusively test that the regnerator.clear_cache actually clears the cache ( in test/test_regenerator.rb )
2. Test that incremental building regenerates files that have changed that previously were unchanged ( in test/test_site.rb )
- Replaced occurrences of #array += with concat
operations.(performance)
- Corrected alignment.
- Removed rebase artifact.
Signed-off-by: Martin Rogalla <martin@martinrogalla.com>
To address part of #3591, clear the regenerator's cache every time the
site is processed. This ensures that the regenerator doesn't incorrectly
believe a file hasn't changed based on stale information.
The documentation has been updated to demonstrate variable parameters for an include.
{% include footer.html param="value" variable-param=page.variable %}
The documentation has been updated to demonstrate variable parameters for an include.
{% include footer.html param="value" variable-param=page.variable %}
This adds docs for two new permalink features coming in Jekyll 3:
- improved default permalinks for pages and collections (#3538)
- support for extensionless URLs (#3490)
Organized the draft, post and layout reader into the *readers* classes.
Fixed all references and ran tests.
Signed-off-by: Martin Jorn Rogalla <martin@martinrogalla.com>
* 'master' of github.com:jekyll/jekyll:
Update history to reflect merge of #3520 [ci skip]
Corrected error message as suggested by @parkr.
Improved clarity of sort nil input error message.
Added test to check on nil input for sort filter.
Sort will now raise error on nil object array input.
After carefully looking at these two methods, as of right now they do not
belong in the reader, as they should also be used by the writer. Thus the
decision was made to move them back into the class containing the source
and dest fields, site.rb.
Signed-off-by: Martin Jorn Rogalla <martin@martinrogalla.com>
Extracted `in_source_dir` from site.rb into reader.rb.
Updated all the references and tests.
Signed-off-by: Martin Jorn Rogalla <martin@martinrogalla.com>
This updates the default permalink style for pages and collections to
match the site-wide 'permalink' setting. If the permalink setting
contains a trailing slash, either explicitly or by being set to
':pretty', then pages and collections permalinks will contain trailing
slashes by default as well. Similarly, if the permalink setting
contains a trailing ':output_ext', so will pages and collections. If
the permalink setting contains neither a trailing slash or extension,
neither will pages or collections.
This impacts only the default permalink structure for pages and
collections. Permalinks set in the frontmatter of an individual page
take precedence, as does the permalink setting for a specific
collection.
Fixes#2691
- Single Quotes
- Fixed Typo's in variable names.
- Removed Redundant Escaping in Regular Expressions.
Signed-off-by: Martin Jorn Rogalla <martin@martinrogalla.com>
This ensures that destination files for HTML posts, pages and
collections always include the proper file extension (as defined by
output_ext) regardless of permalink structure. This allows for URLs
that contain no extension or trailing slash to still result in proper
destination files with .html extensions.
Because this change relies so heavily on output_ext accurately
identifying the extension of the destination file, this change also
removes the feature test that tested support for permalinks with a .htm
extension. In order to support alternate file extensions, a future
patch or plugin will need to modify the output_ext value, at which point
everything else should work as expected.
- Added a test to check if the sort filter will raise the correct
exception on given nil input.
- Improved error message and used "nil" consistently.
Signed-off-by: Martin Jorn Rogalla <martin@martinrogalla.com>
* fabianrbz-remove_adapters_deprecation_warning:
Add minitest/profile to profile 10 slowest tests
Move simplecov_custom_profile to test/ & gate with TRAVIS env
Remove unused groups from simplecov's profile
Removes the following deprecation warning: 'method adapters is deprecated. use profiles instead'
Textile support was removed from jekyll core in #3319, and most of the
tests switched to markdown at that time. This changes the remaining
tests to use markdown as well. The vast majority of the test cases were
testing things in the file name or front matter, so it doesn't really
matter what markup format they use. The one test that was claiming to
test that textile was transformed had actually been moved to markdown as
well, just not renamed.
Fixes#3507
'method adapters is deprecated. use profiles instead'
This warning was showing up because the project was using
the gem 'simplecov-gem-adapter' which uses the old syntax.
* Remove the gem dependency
* Add a profile with the same setup that the gem has
Sort will now throw an error when a nil object array is given as input.
See issue #3491 for more information.
Signed-off-by: Martin Jorn Rogalla <martin@martinrogalla.com>
* delftswa2014-improve-this-page:
Make the .improve callout a light grey.
Put the pencil icon in front of the improve link.
Removed unnecessary margin and simplified padding.
Implemented the "Improve this page" feature. #3495
Created an "Improve this page" link for all the documentation headers. The
feature uses the fa-pencil icon of font awesome. Improvement over #3504(closed).
See issue #3495 for more information.
Signed-off-by: Martin Jorn Rogalla <martin@martinrogalla.com>
Added to the plugin list: jekyll-auto-image. A generator that makes available the first image of a post.
By installing the plugin you will be able to access the first image with {{ @page.image }}. This plugin is useful to Include an image on your list of posts or to set a twitter card for each post/page.
If this '/' is not present, then the second pagination code snippet
under the "Render the paginated Posts" section will have a bug.
Let's say my page 1 is located at host:port/blog/index.html and my
paginate_path setting in _config.yml is "blog/page:num/". The
observation if the paginate_path does not start with a '/' is that the href generated for the page numbers will have 2 'blogs', i.e. for page 2 the href will
incorrectly appear as 'host:port/blog/blog/page2' instead of just
'host:port/blog/page2'.
For a full rebuild, we certainly don't want to *read* from
.jeykll-metadata, but we should still write it. Otherwise, a subsequent
incremental build would have to do a full rebuild again since there is
no metadata file to start from.
Found by @EdMcBane in https://github.com/jekyll/jekyll/pull/3435
The strange regexp we were doing to replace the <pre><code></pre></code>
bits in the Pygments output were wreaking havoc on Rouge output
because Rouge uses <pre>'s to wrap line numbers.
To be consistent, the output from render_* should *not* include
the wrapping <div> and <pre> tags. It should just be what was
inside. We can then wrap it in our own custom tags without using
any regular expressions, as God intended. Death to regular
expressions and HTML manipulation!
This shows people how to kill Jekyll without knowing the PID using `pkill` (you could also do `kill -9 $(pgrep -f jekyll)` but that is just the long way around doing `pkill -f` so it shouldn't be shown in the Jekyll logger but can be documented here for people.
* nitoyon-slugify-new-param:
Remove superfluous Sass declarations.
Move the slugify options out to their own section so as to fix the formatting.
Document the mode parameter of slugify Liquid filter
Add tests for mode parameters of slugify Liquid filter
Add mode parameter to slugify Liquid filter
Conflicts:
lib/jekyll/utils.rb
---> Hadn't added UTF-8 support in nitoyon's PR.
* davidized-collection_yaml_dots:
Move YAML Front Matter regexp into a constant.
Add support for collections documents to have YAML front matter ending in dots.
Conflicts:
test/test_collections.rb
* majioa-devel:
Ensure Post#excerpt_separator always returns a string.
get procedure for default excerpt separator for both cases site and page was moved to the post's specific method :excerpt_separator.
Added per post excerpt_separator functionality, so you are able to specify :excerpt_separator (as well as just :excerpt) key direct inside the post YAML, to make an excerpt based on the value in the post. Tests were also added.
Clarifying what happens if no YAML front matter exists. The current explanation says that Jekyll will generate a file without Front Matter, but it appears this isn't the case.
I'm still not sure if this is the intended behaviour, but this clarifies how it currently works.
specify :excerpt_separator (as well as just :excerpt) key direct inside
the post YAML, to make an excerpt based on the value in the post. Tests
were also added.
Hi there! Interested in contributing to Jekyll? We'd love your help. Jekyll is an open source project, built one contribution at a time by users like you.
## Where to get help or report a problem
See [the support guidelines](https://jekyllrb.com/docs/support/)
## Ways to contribute
Whether you're a developer, a designer, or just a Jekyll devotee, there are lots of ways to contribute. Here's a few ideas:
* [Install Jekyll on your computer](https://jekyllrb.com/docs/installation/) and kick the tires. Does it work? Does it do what you'd expect? If not, [open an issue](https://github.com/jekyll/jekyll/issues/new) and let us know.
* Comment on some of the project's [open issues](https://github.com/jekyll/jekyll/issues). Have you experienced the same problem? Know a work around? Do you have a suggestion for how the feature could be better?
* Read through [the documentation](https://jekyllrb.com/docs/home/), and click the "improve this page" button, any time you see something confusing, or have a suggestion for something that could be improved.
* Browse through [the Jekyll discussion forum](https://talk.jekyllrb.com/), and lend a hand answering questions. There's a good chance you've already experienced what another user is experiencing.
* Find [an open issue](https://github.com/jekyll/jekyll/issues) (especially [those labeled `help-wanted`](https://github.com/jekyll/jekyll/issues?q=is%3Aopen+is%3Aissue+label%3Ahelp-wanted)), and submit a proposed fix. If it's your first pull request, we promise we won't bite, and are glad to answer any questions.
* Help evaluate [open pull requests](https://github.com/jekyll/jekyll/pulls), by testing the changes locally and reviewing what's proposed.
## Submitting a pull request
### Pull requests generally
* The smaller the proposed change, the better. If you'd like to propose two unrelated changes, submit two pull requests.
* The more information, the better. Make judicious use of the pull request body. Describe what changes were made, why you made them, and what impact they will have for users.
* Pull requests are easy and fun. If this is your first pull request, it may help to [understand GitHub Flow](https://guides.github.com/introduction/flow/).
* If you're submitting a code contribution, be sure to read the [code contributions](#code-contributions) section below.
### Submitting a pull request via github.com
Many small changes can be made entirely through the github.com web interface.
1. Navigate to the file within [`jekyll/jekyll`](https://github.com/jekyll/jekyll) that you'd like to edit.
2. Click the pencil icon in the top right corner to edit the file
3. Make your proposed changes
4. Click "Propose file change"
5. Click "Create pull request"
6. Add a descriptive title and detailed description for your proposed change. The more information the better.
7. Click "Create pull request"
That's it! You'll be automatically subscribed to receive updates as others review your proposed change and provide feedback.
### Submitting a pull request via Git command line
1. Fork the project by clicking "Fork" in the top right corner of [`jekyll/jekyll`](https://github.com/jekyll/jekyll).
2. Clone the repository locally `git clone https://github.com/<you-username>/jekyll`.
3. Create a new, descriptively named branch to contain your change ( `git checkout -b my-awesome-feature` ).
4. Hack away, add tests. Not necessarily in that order.
5. Make sure everything still passes by running `script/cibuild` (see [the tests section](#running-tests-locally) below)
6. Push the branch up ( `git push origin my-awesome-feature` ).
7. Create a pull request by visiting `https://github.com/<your-username>/jekyll` and following the instructions at the top of the screen.
## Proposing updates to the documentation
We want the Jekyll documentation to be the best it can be. We've open-sourced our docs and we welcome any pull requests if you find it lacking.
### How to submit changes
You can find the documentation for jekyllrb.com in the [docs](https://github.com/jekyll/jekyll/tree/master/docs) directory. See the section above, [submitting a pull request](#submitting-a-pull-request) for information on how to propose a change.
One gotcha, all pull requests should be directed at the `master` branch (the default branch).
### Updating FontAwesome iconset for jekyllrb.com
We use a custom version of FontAwesome which contains just the icons we use.
If you ever need to update our documentation with an icon that is not already available in our custom iconset, you'll have to regenerate the iconset using Icomoon's Generator:
1. Go to <https://icomoon.io/app/>.
2. Click `Import Icons` on the top-horizontal-bar and upload the existing `<jekyll>/docs/icomoon-selection.json`.
3. Click `Add Icons from Library..` further down on the page, and add 'Font Awesome'.
4. Select the required icon(s) from the Library (make sure its the 'FontAwesome' library instead of 'IcoMoon-Free' library).
5. Click `Generate Font` on the bottom-horizontal-bar.
6. Inspect the included icons and proceed by clicking `Download`.
7. Extract the font files and adapt the CSS to the paths we use in Jekyll:
- Copy the entire `fonts` directory over and overwrite existing ones at `<jekyll>/docs/`.
- Copy the contents of `selection.json` and overwrite existing content inside `<jekyll>/docs/icomoon-selection.json`.
- Copy the entire `@font-face {}` declaration and only the **new-icon(s)' css declarations** further below, to update the
- Fix paths in the `@font-face {}` declaration by adding `../` before `fonts/FontAwesome.*` like so:
`('../fonts/Fontawesome.woff?9h6hxj')`.
### Adding plugins
If you want to add your plugin to the [list of plugins](https://jekyllrb.com/docs/plugins/#available-plugins), please submit a pull request modifying the [plugins page source file](https://github.com/jekyll/jekyll/blob/master/docs/_docs/plugins.md) by adding a link to your plugin under the proper subheading depending upon its type.
## Code Contributions
Interesting in submitting a pull request? Awesome. Read on. There's a few common gotchas that we'd love to help you avoid.
### Tests and documentation
Any time you propose a code change, you should also include updates to the documentation and tests within the same pull request.
#### Documentation
If your contribution changes any Jekyll behavior, make sure to update the documentation. Documentation lives in the `docs/_docs` folder (spoiler alert: it's a Jekyll site!). If the docs are missing information, please feel free to add it in. Great docs make a great project. Include changes to the documentation within your pull request, and once merged, `jekyllrb.com` will be updated.
#### Tests
* If you're creating a small fix or patch to an existing feature, a simple test is more than enough. You can usually copy/paste from an existing example in the `tests` folder, but if you need you can find out about our tests suites [Shoulda](https://github.com/thoughtbot/shoulda/tree/master) and [RSpec-Mocks](https://github.com/rspec/rspec-mocks).
* If it's a brand new feature, create a new [Cucumber](https://github.com/cucumber/cucumber/) feature, reusing existing steps where appropriate.
### Code contributions generally
* Jekyll uses the [Rubocop](https://github.com/bbatsov/rubocop) static analyzer to ensure that contributions follow the [GitHub Ruby Styleguide](https://github.com/styleguide/ruby). Please check your code using `script/fmt` and resolve any errors before pushing your branch.
* Don't bump the Gem version in your pull request (if you don't know what that means, you probably didn't).
* You can use the command `script/console` to start a REPL to explore the result of
Jekyll's methods. It also provides you with helpful methods to quickly create a
site or configuration. [Feel free to check it out!](https://github.com/jekyll/jekyll/blob/master/script/console)
## Running tests locally
### Test Dependencies
To run the test suite and build the gem you'll need to install Jekyll's dependencies by running the following command:
```sh
script/bootstrap
```
Before you make any changes, run the tests and make sure that they pass (to confirm your environment is configured properly):
```sh
script/cibuild
```
If you are only updating a file in `test/`, you can use the command:
```sh
script/test test/blah_test.rb
```
If you are only updating a `.feature` file, you can use the command:
```sh
script/cucumber features/blah.feature
```
Both `script/test` and `script/cucumber` can be run without arguments to
run its entire respective suite.
## A thank you
Thanks! Hacking on Jekyll should be fun. If you find any of this hard to figure out, let us know so we can improve our process or documentation!
* If you have a question about using Jekyll, start a discussion on [Jekyll Forum](https://talk.jekyllrb.com/) or [StackOverflow](https://stackoverflow.com/questions/tagged/jekyll)
* Chat with Jekyllers — Join [our Gitter channel](https://gitter.im/jekyll/jekyll) or [our IRC channel on Freenode](irc:irc.freenode.net/jekyll)
There are a bunch of helpful community members on these services that should be willing to point you in the right direction.
## Report a bug
* If you think you've found a bug within a Jekyll plugin, open an issue in that plugin's repository — First [look for the plugin on rubygems](https://rubygems.org/) then click on the `Homepage` link to access the plugin repository.
* If you think you've found a bug within Jekyll itself, [open an issue](https://github.com/jekyll/jekyll/issues/new).
This issue is reserved for people who never contributed to Open Source before. We know that the process of creating a pull request is the biggest barrier for new contributors. This issue is for you 💝
[About First Timers Only](http://www.firsttimersonly.com/).
### 🤔 What you will need to know.
Nothing. This issue is meant to welcome you to Open Source :) We are happy to walk you through the process.
### 📋 Step by Step
- [ ] 👌 **Join the team**: Add yourself to a Jekyll affinity team.
Go to [teams.jekyllrb.com](https://teams.jekyllrb.com/) and join a team that best fits your interests. Once you click the link to join a team, you will soon receive an email inviting you to join the Jekyll organization.
- [ ] 🙋 **Claim this issue**: Comment below.
Leave a comment that you have claimed this issue.
- [ ] 📝 **Update** the file [$FILENAME]($BRANCH_URL) in the `$REPO` repository (press the little pen Icon) and edit the line as shown below.
```diff
$DIFF
```
- [ ] 💾 **Commit** your changes
- [ ] 🔀 **Start a Pull Request**. There are two ways how you can start a pull request:
1. If you are familiar with the terminal or would like to learn it, [here is a great tutorial](https://egghead.io/series/how-to-contribute-to-an-open-source-project-on-github) on how to send a pull request using the terminal.
2. You can [edit files directly in your browser](https://help.github.com/articles/editing-files-in-your-repository/)
- [ ] 🏁 **Done** Ask in comments for a review :)
### 🤔❓ Questions
Leave a comment below!
This issue was created by [First-Timers-Bot](https://github.com/hoodiehq/first-timers-bot).
In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, nationality, personal appearance, race, religion, or sexual identity and orientation.
## Our Standards
Examples of behavior that contributes to creating a positive environment include:
* Using welcoming and inclusive language
* Being respectful of differing viewpoints and experiences
* Gracefully accepting constructive criticism
* Focusing on what is best for the community
* Showing empathy towards other community members
Examples of unacceptable behavior by participants include:
* The use of sexualized language or imagery and unwelcome sexual attention or advances
* Trolling, insulting/derogatory comments, and personal or political attacks
* Public or private harassment
* Publishing others' private information, such as a physical or electronic address, without explicit permission
* Other conduct which could reasonably be considered inappropriate in a professional setting
## Our Responsibilities
Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior.
Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful.
## Scope
This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers.
## Enforcement
Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by opening an issue or contacting a project maintainer. The project team will review and investigate all complaints, and will respond in a way that it deems appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately.
Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership.
## Attribution
This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4, available at [https://www.contributor-covenant.org/version/1/4/code-of-conduct.html][version]
Jekyll is a simple, blog-aware, static site generator perfect for personal, project, or organization sites. Think of it like a file-based CMS, without all the complexity. Jekyll takes your content, renders Markdown and Liquid templates, and spits out a complete, static website ready to be served by Apache, Nginx or another web server. Jekyll is the engine behind [GitHub Pages](http://pages.github.com), which you can use to host sites right from your GitHub repositories.
Jekyll is a simple, blog-aware, static site generator perfect for personal, project, or organization sites. Think of it like a file-based CMS, without all the complexity. Jekyll takes your content, renders Markdown and Liquid templates, and spits out a complete, static website ready to be served by Apache, Nginx or another web server. Jekyll is the engine behind [GitHub Pages](https://pages.github.com), which you can use to host sites right from your GitHub repositories.
## Philosophy
Jekyll does what you tell it to do— no more, no less. It doesn't try to outsmart users by making bold assumptions, nor does it burden them with needless complexity and configuration. Put simply, Jekyll gets out of your way and allows you to concentrate on what truly matters: your content.
See: https://jekyllrb.com/philosophy
## Having trouble?
See: https://jekyllrb.com/docs/troubleshooting/
## Getting Started
* [Install](http://jekyllrb.com/docs/installation/) the gem
* Read up about its [Usage](http://jekyllrb.com/docs/usage/) and [Configuration](http://jekyllrb.com/docs/configuration/)
* [Install](https://jekyllrb.com/docs/installation/) the gem
* Read up about its [Usage](https://jekyllrb.com/docs/usage/) and [Configuration](https://jekyllrb.com/docs/configuration/)
* Take a gander at some existing [Sites](https://wiki.github.com/jekyll/jekyll/sites)
* Fork and [Contribute](http://jekyllrb.com/docs/contributing/) your own modifications
* Have questions? Check out [`#jekyll` on irc.freenode.net](https://botbot.me/freenode/jekyll/).
*[Fork](https://github.com/jekyll/jekyll/fork) and [Contribute](https://jekyllrb.com/docs/contributing/) your own modifications
* Have questions? Check out our official forum community [Jekyll Talk](https://talk.jekyllrb.com/) or [`#jekyll` on irc.freenode.net](https://botbot.me/freenode/jekyll/)
## Code of Conduct
In order to have a more open and welcoming community, Jekyll adheres to a
[code of conduct](CODE_OF_CONDUCT.markdown) adapted from the Ruby on Rails code of
conduct.
Please adhere to this code of conduct in any interactions you have in the
Jekyll community. It is strictly enforced on all official Jekyll
repositories, websites, and resources. If you encounter someone violating
these terms, please let one of our [core team members](https://jekyllrb.com/team/#core-team) know and we will address it as soon as possible.
## Diving In
* [Migrate](http://import.jekyllrb.com/docs/home/) from your previous system
* Learn how the [YAML Front Matter](http://jekyllrb.com/docs/frontmatter/) works
* Put information on your site with [Variables](http://jekyllrb.com/docs/variables/)
* Customize the [Permalinks](http://jekyllrb.com/docs/permalinks/) your posts are generated with
* Use the built-in [Liquid Extensions](http://jekyllrb.com/docs/templates/) to make your life easier
* Use custom [Plugins](http://jekyllrb.com/docs/plugins/) to generate content specific to your site
* Learn how the [YAML Front Matter](https://jekyllrb.com/docs/frontmatter/) works
* Put information on your site with [Variables](https://jekyllrb.com/docs/variables/)
* Customize the [Permalinks](https://jekyllrb.com/docs/permalinks/) your posts are generated with
* Use the built-in [Liquid Extensions](https://jekyllrb.com/docs/templates/) to make your life easier
* Use custom [Plugins](https://jekyllrb.com/docs/plugins/) to generate content specific to your site
## License
See [LICENSE](https://github.com/jekyll/jekyll/blob/master/LICENSE).
See the [LICENSE](https://github.com/jekyll/jekyll/blob/master/LICENSE) file.
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.
## Using Collections
To start using collections, follow these 3 steps:
* [Step 1: Tell Jekyll to read in your collection](#step1)
* [Step 2: Add your content](#step2)
* [Step 3: Optionally render your collection's documents into independent files](#step3)
### Step 1: Tell Jekyll to read in your collection {#step1}
Add the following to your site's `_config.yml` file, replacing `my_collection`
with the name of your collection:
```yaml
collections:
- my_collection
```
You can optionally specify metadata for your collection in the configuration:
```yaml
collections:
my_collection:
foo:bar
```
Default attributes can also be set for a collection:
```yaml
defaults:
- scope:
path:""
type:my_collection
values:
layout:page
```
<div class="note">
<h5>Gather your collections {%- include docs_version_badge.html version="3.7.0" -%}</h5>
<p>You can optionally specify a directory to store all your collections in the same place with <code>collections_dir: my_collections</code>.</p>
<p>Then Jekyll will look in <code>my_collections/_books</code> for the <code>books</code> collection, and
in <code>my_collections/_recipes</code> for the <code>recipes</code> collection.</p>
</div>
<div class="note warning">
<h5>Be sure to move drafts and posts into custom collections directory</h5>
<p>If you specify a directory to store all your collections in the same place with <code>collections_dir: my_collections</code>, then you will need to move your <code>_drafts</code> and <code>_posts</code> directory to <code>my_collections/_drafts</code> and <code>my_collections/_posts</code>. Note that, the name of your collections directory cannot start with an underscore (`_`).</p>
</div>
### Step 2: Add your content {#step2}
Create a corresponding folder (e.g. `<source>/_my_collection`) and add
documents. YAML front matter is processed if the front matter exists, and everything
after the front matter is pushed into the document's `content` attribute. If no YAML front
matter is provided, Jekyll will not generate the file in your collection.
<div class="note info">
<h5>Be sure to name your directories correctly</h5>
<p>
The folder must be named identically to the collection you defined in
your <code>_config.yml</code> file, with the addition of the preceding <code>_</code> character.
</p>
</div>
### Step 3: Optionally render your collection's documents into independent files {#step3}
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`:
```yaml
collections:
my_collection:
output:true
```
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`.
If you wish a specific page to be shown when accessing `/my_collection/`,
simply add `permalink: /my_collection/index.html` to a page.
To list items from the collection, on that page or any other, you can use:
variable value if any is present in the document; if none is
defined then <code>:title</code> will be equivalent to
<code>:name</code>, aka the slug generated from the filename.
</p>
</td>
</tr>
<tr>
<td>
<p><code>:output_ext</code></p>
</td>
<td>
<p>Extension of the output file. (Included by default and usually unnecessary.)</p>
</td>
</tr>
</tbody>
</table>
</div>
## Liquid Attributes
### Collections
Each collection is accessible as a field on the `site` 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 the table 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:
<div class="mobile-side-scroller">
<table>
<thead>
<tr>
<th>Variable</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr>
<td>
<p><code>label</code></p>
</td>
<td>
<p>
The name of your collection, e.g. <code>my_collection</code>.
</p>
</td>
</tr>
<tr>
<td>
<p><code>docs</code></p>
</td>
<td>
<p>
An array of <a href="#documents">documents</a>.
</p>
</td>
</tr>
<tr>
<td>
<p><code>files</code></p>
</td>
<td>
<p>
An array of static files in the collection.
</p>
</td>
</tr>
<tr>
<td>
<p><code>relative_directory</code></p>
</td>
<td>
<p>
The path to the collection's source directory, relative to the site
source.
</p>
</td>
</tr>
<tr>
<td>
<p><code>directory</code></p>
</td>
<td>
<p>
The full path to the collections's source directory.
</p>
</td>
</tr>
<tr>
<td>
<p><code>output</code></p>
</td>
<td>
<p>
Whether the collection's documents will be output as individual
files.
</p>
</td>
</tr>
</tbody>
</table>
</div>
<div class="note info">
<h5>A Hard-Coded Collection</h5>
<p>In addition to any collections you create yourself, the
<code>posts</code> collection is hard-coded into Jekyll. It exists whether
you have a <code>_posts</code> directory or not. This is something to note
when iterating through <code>site.collections</code> as you may need to
filter it out.</p>
<p>You may wish to use filters to find your collection:
<code>{% raw %}{{ site.collections | where: "label", "myCollection" | first }}{% endraw %}</code></p>
</div>
<div class="note info">
<h5>Collections and Time</h5>
<p>Except for documents in hard-coded default collection <code>posts</code>, all documents in collections
you create, are accessible via Liquid irrespective of their assigned date, if any, and therefore renderable.
</p>
<p>However documents are attempted to be written to disk only if the concerned collection
metadata has <code>output: true</code>. Additionally, future-dated documents are only written if
<code>site.future</code> <em>is also true</em>.
</p>
<p>More fine-grained control over documents being written to disk can be exercised by setting
<code>published: false</code> (<em><code>true</code> by default</em>) in the document's front matter.
</p>
</div>
### Documents
In addition to any YAML Front Matter provided in the document's corresponding
file, each document has the following attributes:
<div class="mobile-side-scroller">
<table>
<thead>
<tr>
<th>Variable</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr>
<td>
<p><code>content</code></p>
</td>
<td>
<p>
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.
</p>
</td>
</tr>
<tr>
<td>
<p><code>output</code></p>
</td>
<td>
<p>
The rendered output of the document, based on the
<code>content</code>.
</p>
</td>
</tr>
<tr>
<td>
<p><code>path</code></p>
</td>
<td>
<p>
The full path to the document's source file.
</p>
</td>
</tr>
<tr>
<td>
<p><code>relative_path</code></p>
</td>
<td>
<p>
The path to the document's source file relative to the site source.
</p>
</td>
</tr>
<tr>
<td>
<p><code>url</code></p>
</td>
<td>
<p>
The URL of the rendered collection. The file is only written to the destination when the collection to which it belongs has <code>output: true</code> in the site's configuration.
</p>
</td>
</tr>
<tr>
<td>
<p><code>collection</code></p>
</td>
<td>
<p>
The name of the document's collection.
</p>
</td>
</tr>
<tr>
<td>
<p><code>date</code></p>
</td>
<td>
<p>
The date of the document's collection.
</p>
</td>
</tr>
</tbody>
</table>
</div>
## Accessing Collection Attributes
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`,
you 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):
```yaml
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:
```liquid
{% raw %}
{% for album in site.albums %}
<h2>{{ album.title }}</h2>
<p>Performed by {{ album.artist }}{% if album.director %}, directed by {{ album.director }}{% endif %}</p>
@@ -108,10 +105,10 @@ class="flag">flags</code> (specified on the command-line) that control them.
Set the time zone for site generation. This sets the <code>TZ</code>
environment variable, which Ruby uses to handle time and date
creation and manipulation. Any entry from the
<a href="http://en.wikipedia.org/wiki/Tz_database">IANA Time Zone
<a href="https://en.wikipedia.org/wiki/Tz_database">IANA Time Zone
Database</a> is valid, e.g. <code>America/New_York</code>. A list of all
available values can be found <a href="http://en.wikipedia.org/wiki/List_of_tz_database_time_zones">
here</a>. The default is the local time zone, as set by your operating system.
available values can be found <a href="https://en.wikipedia.org/wiki/List_of_tz_database_time_zones">
here</a>. When serving on a local machine, the default time zone is set by your operating system. But when served on a remote host/server, the default time zone depends on the server's setting or location.
</p>
</td>
<td class="align-center">
@@ -122,7 +119,7 @@ class="flag">flags</code> (specified on the command-line) that control them.
<td>
<p class="name"><strong>Encoding</strong></p>
<p class="description">
Set the encoding of files by name. Only available for Ruby
Set the encoding of files by name (only available for Ruby
1.9 or later).
The default value is <code>utf-8</code> starting in 2.0.0,
and <code>nil</code> before 2.0.0, which will yield the Ruby
@@ -155,9 +152,12 @@ class="flag">flags</code> (specified on the command-line) that control them.
<h5>Destination folders are cleaned on site builds</h5>
<p>
The contents of <code><destination></code> are automatically
cleaned when the site is built. Files or folders that are not
created by your site will be removed. Do not use an important
location for <code><destination></code>; instead, use it as
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 <code><keep_files></code> configuration directive.
</p>
<p>
Do not use an important location for <code><destination></code>; instead, use it as
a staging area and copy files from there to your web server.
</p>
</div>
@@ -179,7 +179,7 @@ class="flag">flags</code> (specified on the command-line) that control them.
<p class="description">Enable auto-regeneration of the site when files are modified.</p>
</td>
<td class="align-center">
<p><code class="flag">-w, --watch</code></p>
<p><code class="flag">-w, --[no-]watch</code></p>
</td>
</tr>
<tr class="setting">
@@ -197,23 +197,43 @@ class="flag">flags</code> (specified on the command-line) that control them.
<p class="description">Process and render draft posts.</p>
<p class="description">SSL Public certificate.</p>
</td>
<td class="align-center">
<p><code class="flag">--ssl-cert</code></p>
</td>
</tr>
</tbody>
</table>
</div>
@@ -338,30 +416,89 @@ before your site is served.
</p>
</div>
## Custom WEBrick Headers
You can provide custom headers for your site by adding them to `_config.yml`
```yaml
# File: _config.yml
webrick:
headers:
My-Header: My-Value
My-Other-Header: My-Other-Value
```
### Defaults
We provide by default `Content-Type` and `Cache-Control` response headers: one
dynamic in order to specify the nature of the data being served, the other
static in order to disable caching so that you don't have to fight with Chrome's
aggressive caching when you are in development mode.
## Specifying a Jekyll environment at build time
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:
```liquid
{% raw %}
{% if jekyll.environment == "production" %}
{% include disqus.html %}
{% endif %}
{% endraw %}
```
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:
```sh
JEKYLL_ENV=production jekyll build
```
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 `{% raw %}{% if jekyll.environment == "development" %}{% endraw %}` 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.
## Front Matter defaults
Using [YAML Front Matter](../frontmatter/) 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.
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 project's 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:
{% highlight yaml %}
```yaml
defaults:
-
scope:
path: "" # an empty string here means all files in the project
values:
layout: "default"
{% endhighlight %}
```
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.
<div class="note info">
<h5>Please stop and rerun `jekyll serve` command.</h5>
<p>
The <code>_config.yml</code> master configuration file contains global configurations
and variable definitions that are read once at execution time. Changes made to <code>_config.yml</code>
during automatic regeneration are not loaded until the next execution.
</p>
<p>
Note <a href="../datafiles">Data Files</a> are included and reloaded during automatic regeneration.
</p>
</div>
{% highlight yaml %}
Here, we are scoping the `values` to any file that exists in the path `scope`. 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.
```yaml
defaults:
-
scope:
@@ -369,35 +506,35 @@ defaults:
type: "posts" # previously `post` in Jekyll 2.2.
values:
layout: "default"
{% endhighlight %}
```
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](../variables/) set to `Mr. Hyde` as well as have the category for the page set to `project`.
With these defaults, all pages 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](../variables/) set to `Mr. Hyde`.
{% highlight yaml %}
```yaml
collections:
- my_collection:
my_collection:
output: true
defaults:
@@ -407,19 +544,48 @@ defaults:
type: "my_collection" # a collection in your site, in plural form
values:
layout: "default"
{% endhighlight %}
```
In this example, the `layout` is set to `default` inside the
[collection](../collections/) with the name `my_collection`.
### Glob patterns in Front Matter defaults
It is also possible to use glob patterns (currently limited to patterns that contain `*`) when matching defaults. For example, it is possible to set specific layout for each `special-page.html` in any subfolder of `section` folder. {%- include docs_version_badge.html version="3.7.0" -%}
```yaml
collections:
my_collection:
output: true
defaults:
-
scope:
path: "section/*/special-page.html"
values:
layout: "specific-layout"
```
<div class="note warning">
<h5>Globbing and Performance</h5>
<p>
Please note that globbing a path is known to have a negative effect on
performance and is currently not optimized, especially on Windows.
Globbing a path will increase your build times in proportion to the size
of the associated collection directory.
</p>
</div>
In this example the `layout` is set to `default` inside the [collection](../collections) with the name `my_collection`.
### Precedence
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 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.
You can see that in the second to last example above. First, we set the default page layout to `my-site`. Then, using a more specific path, we set the default layout for pages 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:
{% highlight yaml %}
```yaml
# In _config.yml
...
defaults:
@@ -432,76 +598,81 @@ defaults:
author: "Mr. Hyde"
category: "project"
...
{% endhighlight %}
```
{% highlight yaml %}
```yaml
# In projects/foo_project.md
---
author: "John Smith"
layout: "foobar"
---
The post text goes here...
{% endhighlight %}
```
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.
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.
## Default Configuration
Jekyll runs with the following configuration options by default. Unless
alternative settings for these options are explicitly specified in the
configuration file or on the command-line, Jekyll will run using these options.
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.
<div class="note warning">
<h5>There are two unsupported kramdown options</h5>
<p>
Please note that both <code>remove_block_html_tags</code> and
<code>remove_span_html_tags</code> are currently unsupported in Jekyll due to the
fact that they are not included within the kramdown HTML converter.
<code>remove_span_html_tags</code> are currently unsupported in Jekyll due
to the fact that they are not included within the kramdown HTML converter.
Liquid's response to errors can be configured by setting `error_mode`. The
options are
- `lax` --- Ignore all errors.
- `warn` --- Output a warning on the console for each error.
- `strict` --- Output an error message and stop the build.
You can also configure Liquid's renderer to catch non-assigned variables and
non-existing filters by setting `strict_variables` and / or `strict_filters`
to `true` respectively. {% include docs_version_badge.html version="3.8.0" %}
Do note that while `error_mode` configures Liquid's parser, the `strict_variables`
and `strict_filters` options configure Liquid's renderer and are consequently,
mutually exclusive.
## Markdown Options
The various Markdown renderers supported by Jekyll sometimes have extra options available.
The various Markdown renderers supported by Jekyll sometimes have extra options
available.
### Redcarpet
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`.
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.
- `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:
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.
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.
- `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.][redcarpet_extensions] Make sure you're looking at the README for the right version of Redcarpet: Jekyll currently uses v2.2.x, and extensions like `footnotes` and `highlight` weren't added until after version 3.0.0. The most commonly used extensions are:
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.][redcarpet_extensions]
Make sure you're looking at the README for the right version of
Redcarpet: Jekyll currently uses v3.2.x. The most commonly used
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".
[Buddy][buddy-homepage] is a [Docker][docker-homepage]-based CI server that you can set up in 15-20 minutes to build, test, and deploy your Jekyll websites. It supports [GitHub][github-homepage], [Bitbucket][bitbucket-homepage], and [GitLab][gitlab-homepage] repositories, and can be installed on-premises or used in cloud. The following guide will show you how to set up a free environment to build and test your Jekyll project.
[buddy-homepage]: https://buddy.works
[docker-homepage]: https://www.docker.com/
[github-homepage]: https://github.com
[bitbucket-homepage]: https://bitbucket.org/
[gitlab-homepage]: https://gitlab.com
## 1. Getting started
1. Log in at [https://buddy.works][buddy-homepage] with your GitHub/Bitbucket account or email
2. Choose your Git provider and select or push your Jekyll Project
3. Create a new pipeline and set the trigger mode to 'On every push'
4. Add and configure the Jekyll action and save the pipeline
## 2. How it works
Whenever you make a push to the selected branch, the Jekyll action runs `jekyll build` in an isolated [Jekyll Docker image][jekyll-docker-image]. The output is generated to the `/filesystem` directory, and can be further deployed to FTP/SFTP and IaaS services. You can add your own commands, install additional packages, attach services, and run Selenium tests, as well as add other actions down the pipeline, eg. a Slack notification or an SSH script that will restart your server.
If you prefer configuration as code over GUI, you can generate a `buddy.yml` that will create a pipeline with the Jekyll action once you push it to the target branch:
```yaml
- pipeline:"Build and Deploy Jekyll site"
trigger_mode:"ON_EVERY_PUSH"
ref_name:"master"
actions:
- action:"Execute: jekyll build"
type:"BUILD"
docker_image_name:"jekyll/jekyll"
docker_image_tag:"latest"
execute_commands:
- "chown jekyll:jekyll $WORKING_DIR"
- "jekyll build"
```
## 4. Setting up on-premises server
The self-hosted version of Buddy can be installed on any type of server supporting Docker, including [Linux][bw-linux], [Mac][bw-mac], [AWS EC2][bw-aws-ec2], [DigitalOcean][bw-digitalocean], and [Microsoft Azure][bw-azure].
This entire guide is open-source. Go ahead and [edit it][jekyll-docs-ci-buddy] if you want to expand it or have a fix or [ask for help][jekyll-help] if you run into trouble and need assistance. Buddy also has an [online community][buddy-forum] for help.
Building, testing, and deploying your Jekyll-generated website can quickly be done with [CircleCI][0], a continuous integration & delivery tool. CircleCI supports [GitHub][1] and [Bitbucket][2], and you can get started for free using an open-source or private repository.
[0]: https://circleci.com/
[1]: https://github.com/
[2]: https://bitbucket.org/
## 1. Follow Your Project on CircleCI
To start building your project on CircleCI, all you need to do is 'follow' your project from CircleCI's website:
1. Visit the 'Add Projects' page: <https://circleci.com/add-projects>
1. From the GitHub or Bitbucket tab on the left, choose a user or organization.
1. Find your project in the list and click 'Build project' on the right.
1. The first build will start on its own. You can start telling CircleCI how to build your project by creating a [circle.yml][3] file in the root of your repository.
[3]: https://circleci.com/docs/configuration/
## 2. Dependencies
The easiest way to manage dependencies for a Jekyll project (with or without CircleCI) is via a [Gemfile][4]. You'd want to have Jekyll, any Jekyll plugins, [HTML Proofer](#html-proofer), and any other gems that you are using in the `Gemfile`. Don't forget to version `Gemfile.lock` as well. Here's an example `Gemfile`:
[4]: http://bundler.io/gemfile.html
```ruby
source'https://rubygems.org'
ruby'2.4.0'
gem'jekyll'
gem'html-proofer'
```
CircleCI detects when `Gemfile` is present is will automatically run `bundle install` for you in the `dependencies` phase.
## 3. Testing
The most basic test that can be run is simply seeing if `jekyll build` actually works. This is a blocker, a dependency if you will, for other tests you might run on the generate site. So we'll run Jekyll, via Bundler, in the `dependencies` phase.
```yaml
dependencies:
post:
- bundle exec jekyll build
```
### HTML Proofer
With your site built, it's useful to run tests to check for valid HTML, broken links, etc. There's a few tools out there but [HTML Proofer][5] is popular amongst Jekyll users. We'll run it in the `test` phase with a few preferred flags. Check out the `html-proofer` [README][6] for all available flags, or run `htmlproofer --help` locally.
for CircleCI v2, a Docker-based system which new projects will follow, set the `S3_BUCKET_NAME` environment variable (an example of the required config file is shown below).
```yaml
defaults:&defaults
working_directory:~/repo
version:2
jobs:
build:
<<:*defaults
docker:
- image:circleci/ruby:2.5
environment:
BUNDLE_PATH:~/repo/vendor/bundle
steps:
- checkout
- restore_cache:
keys:
- rubygems-v1-{% raw %}{{ checksum "Gemfile.lock" }}{% endraw %}
- rubygems-v1-fallback
- run:
name:Bundle Install
command:bundle check || bundle install
- run:
name:HTMLProofer tests
command:|
bundle exec htmlproofer ./_site \
--allow-hash-href \
--check-favicon \
--check-html \
--disable-external
- save_cache:
key:rubygems-v1-{% raw %}{{ checksum "Gemfile.lock" }}{% endraw %}
This entire guide is open-source. Go ahead and [edit it][7] if you have a fix or [ask for help][8] if you run into trouble and need some help. CircleCI also has an [online community][9] for help.
Continuous Integration (CI) enables you to publish your Jekyll generated website with confidence by automating the quality assurance and deployment processes. You can quickly get started using CI with one of the providers below:
This file is used to configure your Travis builds. Because Jekyll is built
with Ruby and requires RubyGems to install, we use the Ruby language build
environment. Below is a sample `.travis.yml` file, followed by
an explanation of each line.
**Note:** You will need a Gemfile as well, [Travis will automatically install](https://docs.travis-ci.com/user/languages/ruby/#Dependency-Management) the dependencies based on the referenced gems. Here is an example `Gemfile` with two referenced gems, "jekyll" and "html-proofer":
```ruby
source"https://rubygems.org"
gem"jekyll"
gem"html-proofer"
```
Your `.travis.yml` file should look like this:
```yaml
language:ruby
rvm:
- 2.4.1
before_script:
- chmod +x ./script/cibuild# or do this locally and commit
# Assume bundler is being used, therefore
# the `install` step will run `bundle install` by default.
script:./script/cibuild
# branch whitelist, only for GitHub Pages
branches:
only:
- gh-pages # test the gh-pages branch
- /pages-(.*)/# test every branch which starts with "pages-"
env:
global:
- NOKOGIRI_USE_SYSTEM_LIBRARIES=true# speeds up installation of html-proofer
sudo:false# route your build to the container-based infrastructure for a faster build
cache:bundler# caching bundler gem packages will speed up build
# Optional: disable email notifications about the outcome of your builds
notifications:
email:false
```
Ok, now for an explanation of each line:
```yaml
language:ruby
```
This line tells Travis to use a Ruby build container. It gives your script
access to Bundler, RubyGems, and a Ruby runtime.
```yaml
rvm:
- 2.4.1
```
RVM is a popular Ruby Version Manager (like rbenv, chruby, etc). This
directive tells Travis the Ruby version to use when running your test
script. Use a [version which is pre-installed on the Travis build docker][5]
image to speed up the build.
```yaml
before_script:
- chmod +x ./script/cibuild
```
The build script file needs to have the *executable* attribute set or
Travis will fail with a permission denied error. You can also run this
locally and commit the permissions directly, thus rendering this step
irrelevant.
```yaml
script:./script/cibuild
```
Travis allows you to run any arbitrary shell script to test your site. One
convention is to put all scripts for your project in the `script`
directory, and to call your test script `cibuild`. This line is completely
customizable. If your script won't change much, you can write your test
incantation here directly:
```yaml
install:gem install jekyll html-proofer
script:jekyll build && htmlproofer ./_site
```
The `script` directive can be absolutely any valid shell command.
```yaml
# branch whitelist, only for GitHub Pages
branches:
only:
- gh-pages # test the gh-pages branch
- /pages-(.*)/# test every branch which starts with "pages-"
```
You want to ensure the Travis builds for your site are being run only on
the branch or branches which contain your site. One means of ensuring this
isolation is including a branch whitelist in your Travis configuration
file. By specifying the `gh-pages` branch, you will ensure the associated
test script (discussed above) is only executed on site branches. If you use
a pull request flow for proposing changes, you may wish to enforce a
convention for your builds such that all branches containing edits are
prefixed, exemplified above with the `/pages-(.*)/` regular expression.
The `branches` directive is completely optional. Travis will build from every
push to any branch of your repo if leave it out.
```yaml
env:
global:
- NOKOGIRI_USE_SYSTEM_LIBRARIES=true# speeds up installation of html-proofer
```
Using `html-proofer`? You'll want this environment variable. Nokogiri, used
to parse HTML files in your compiled site, comes bundled with libraries
which it must compile each time it is installed. Luckily, you can
dramatically decrease the install time of Nokogiri by setting the
environment variable `NOKOGIRI_USE_SYSTEM_LIBRARIES` to `true`.
<div class="note warning">
<h5>Be sure to exclude <code>vendor</code> from your
<code>_config.yml</code></h5>
<p>Travis bundles all gems in the <code>vendor</code> directory on its build
servers, which Jekyll will mistakenly read and explode on.</p>
</div>
```yaml
exclude:[vendor]
```
By default you should supply the `sudo: false` command to Travis. This command
explicitly tells Travis to run your build on Travis's [container-based
infrastructure](https://docs.travis-ci.com/user/workers/container-based-infrastructure/#Routing-your-build-to-container-based-infrastructure). Running on the container-based infrastructure can often times
speed up your build. If you have any trouble with your build, or if your build
does need `sudo` access, modify the line to `sudo: required`.
```yaml
sudo:false
```
To speed up the build, you should cache the gem packages created by `bundler`.
Travis has a pre-defined [cache strategy for this tool][6] which should have
all the default configs to do exactly that.
```yaml
cache:bundler
```
Optionally, if you are not interested in the build email notifications you
can disable them with this configuration. Travis supports a wide array of
notification services, you may find [another one more useful (e.g. slack)][7].
```yaml
notifications:
email:false
```
### Troubleshooting
**Travis error:** *"You are trying to install in deployment mode after changing
your Gemfile. Run bundle install elsewhere and add the updated Gemfile.lock
to version control."*
**Workaround:** Either run `bundle install` locally and commit your changes to
`Gemfile.lock`, or remove the `Gemfile.lock` file from your repository and add
an entry in the `.gitignore` file to avoid it from being checked in again.
### Questions?
This entire guide is open-source. Go ahead and [edit it][3] if you have a
fix or [ask for help][4] if you run into trouble and need some help.
note: This file is autogenerated. Edit /.github/CONTRIBUTING.markdown instead.
---
Hi there! Interested in contributing to Jekyll? We'd love your help. Jekyll is an open source project, built one contribution at a time by users like you.
## Where to get help or report a problem
See [the support guidelines](https://jekyllrb.com/docs/support/)
## Ways to contribute
Whether you're a developer, a designer, or just a Jekyll devotee, there are lots of ways to contribute. Here's a few ideas:
* [Install Jekyll on your computer](https://jekyllrb.com/docs/installation/) and kick the tires. Does it work? Does it do what you'd expect? If not, [open an issue](https://github.com/jekyll/jekyll/issues/new) and let us know.
* Comment on some of the project's [open issues](https://github.com/jekyll/jekyll/issues). Have you experienced the same problem? Know a work around? Do you have a suggestion for how the feature could be better?
* Read through [the documentation](https://jekyllrb.com/docs/home/), and click the "improve this page" button, any time you see something confusing, or have a suggestion on how to improve something.
* Browse through [the Jekyll discussion forum](https://talk.jekyllrb.com/), and lend a hand answering questions. There's a good chance you've already experienced what another user is experiencing.
* Find [an open issue](https://github.com/jekyll/jekyll/issues) (especially [those labeled `help-wanted`](https://github.com/jekyll/jekyll/issues?q=is%3Aopen+is%3Aissue+label%3Ahelp-wanted)), and submit a proposed fix. If it's your first pull request, we promise we won't bite, and are glad to answer any questions.
* Help evaluate [open pull requests](https://github.com/jekyll/jekyll/pulls), by testing the changes locally and reviewing what's proposed.
## Submitting a pull request
### Pull requests generally
* The smaller the proposed change, the better. If you'd like to propose two unrelated changes, submit two pull requests.
* The more information, the better. Make judicious use of the pull request body. Describe what changes were made, why you made them, and what impact they will have for users.
* Pull requests are easy and fun. If this is your first pull request, it may help to [understand GitHub Flow](https://guides.github.com/introduction/flow/).
* If you're submitting a code contribution, be sure to read the [code contributions](#code-contributions) section below.
### Submitting a pull request via github.com
Many small changes can be made entirely through the github.com web interface.
1. Navigate to the file within [`jekyll/jekyll`](https://github.com/jekyll/jekyll) that you'd like to edit.
2. Click the pencil icon in the top right corner to edit the file
3. Make your proposed changes
4. Click "Propose file change"
5. Click "Create pull request"
6. Add a descriptive title and detailed description for your proposed change. The more information the better.
7. Click "Create pull request"
That's it! You'll be automatically subscribed to receive updates as others review your proposed change and provide feedback.
### Submitting a pull request via Git command line
1. Fork the project by clicking "Fork" in the top right corner of [`jekyll/jekyll`](https://github.com/jekyll/jekyll).
2. Clone the repository locally `git clone https://github.com/<you-username>/jekyll`.
3. Create a new, descriptively named branch to contain your change ( `git checkout -b my-awesome-feature` ).
4. Hack away, add tests. Not necessarily in that order.
5. Make sure everything still passes by running `script/cibuild` (see [the tests section](#running-tests-locally) below)
6. Push the branch up ( `git push origin my-awesome-feature` ).
7. Create a pull request by visiting `https://github.com/<your-username>/jekyll` and following the instructions at the top of the screen.
## Proposing updates to the documentation
We want the Jekyll documentation to be the best it can be. We've open-sourced our docs and we welcome any pull requests if you find it lacking.
### How to submit changes
You can find the documentation for jekyllrb.com in the [docs](https://github.com/jekyll/jekyll/tree/master/docs) directory. See the section above, [submitting a pull request](#submitting-a-pull-request) for information on how to propose a change.
One gotcha, all pull requests should be directed at the `master` branch (the default branch).
### Updating FontAwesome iconset for jekyllrb.com
We use a custom version of FontAwesome which contains just the icons we use.
If you ever need to update our documentation with an icon that is not already available in our custom iconset, you'll have to regenerate the iconset using Icomoon's Generator:
1. Go to <https://icomoon.io/app/>.
2. Click `Import Icons` on the top-horizontal-bar and upload the existing `<jekyll>/docs/icomoon-selection.json`.
3. Click `Add Icons from Library..` further down on the page, and add 'Font Awesome'.
4. Select the required icon(s) from the Library (make sure its the 'FontAwesome' library instead of 'IcoMoon-Free' library).
5. Click `Generate Font` on the bottom-horizontal-bar.
6. Inspect the included icons and proceed by clicking `Download`.
7. Extract the font files and adapt the CSS to the paths we use in Jekyll:
- Copy the entire `fonts` directory over and overwrite existing ones at `<jekyll>/docs/`.
- Copy the contents of `selection.json` and overwrite existing content inside `<jekyll>/docs/icomoon-selection.json`.
- Copy the entire `@font-face {}` declaration and only the **new-icon(s)' css declarations** further below, to update the
- Fix paths in the `@font-face {}` declaration by adding `../` before `fonts/FontAwesome.*` like so:
`('../fonts/Fontawesome.woff?9h6hxj')`.
### Adding plugins
If you want to add your plugin to the [list of plugins](https://jekyllrb.com/docs/plugins/#available-plugins), please submit a pull request modifying the [plugins page source file](https://github.com/jekyll/jekyll/blob/master/docs/_docs/plugins.md) by adding a link to your plugin under the proper subheading depending upon its type.
## Code Contributions
Interesting in submitting a pull request? Awesome. Read on. There's a few common gotchas that we'd love to help you avoid.
### Tests and documentation
Any time you propose a code change, you should also include updates to the documentation and tests within the same pull request.
#### Documentation
If your contribution changes any Jekyll behavior, make sure to update the documentation. Documentation lives in the `docs/_docs` folder (spoiler alert: it's a Jekyll site!). If the docs are missing information, please feel free to add it in. Great docs make a great project. Include changes to the documentation within your pull request, and once merged, `jekyllrb.com` will be updated.
#### Tests
* If you're creating a small fix or patch to an existing feature, a simple test is more than enough. You can usually copy/paste from an existing example in the `tests` folder, but if you need you can find out about our tests suites [Shoulda](https://github.com/thoughtbot/shoulda/tree/master) and [RSpec-Mocks](https://github.com/rspec/rspec-mocks).
* If it's a brand new feature, create a new [Cucumber](https://github.com/cucumber/cucumber/) feature, reusing existing steps where appropriate.
### Code contributions generally
* Jekyll uses the [Rubocop](https://github.com/bbatsov/rubocop) static analyzer to ensure that contributions follow the [GitHub Ruby Styleguide](https://github.com/styleguide/ruby). Please check your code using `script/fmt` and resolve any errors before pushing your branch.
* Don't bump the Gem version in your pull request (if you don't know what that means, you probably didn't).
* You can use the command `script/console` to start a REPL to explore the result of
Jekyll's methods. It also provides you with helpful methods to quickly create a
site or configuration. [Feel free to check it out!](https://github.com/jekyll/jekyll/blob/master/script/console)
## Running tests locally
### Test Dependencies
To run the test suite and build the gem you'll need to install Jekyll's dependencies by running the following command:
```sh
script/bootstrap
```
Before you make any changes, run the tests and make sure that they pass (to confirm your environment is configured properly):
```sh
script/cibuild
```
If you are only updating a file in `test/`, you can use the command:
```sh
script/test test/blah_test.rb
```
If you are only updating a `.feature` file, you can use the command:
```sh
script/cucumber features/blah.feature
```
Both `script/test` and `script/cucumber` can be run without arguments to
run its entire respective suite.
## A thank you
Thanks! Hacking on Jekyll should be fun. If you find any of this hard to figure out, let us know so we can improve our process or documentation!
@@ -23,43 +20,44 @@ Plugins/themes can also leverage Data Files to set configuration variables.
As explained on the [directory structure](../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`.
your site. These files must be YAML, JSON, or CSV files (using either
the `.yml`, `.yaml`, `.json`or `.csv` extension), and they will be
accessible via `site.data`.
## Example: List of members
Here is a basic example of using Data Files to avoid copy-pasting large chunks of
code in your Jekyll templates:
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`:
{% highlight yaml %}
- name: Tom Preston-Werner
github: mojombo
```yaml
- name: Eric Mill
github: konklone
- name: Parker Moore
github: parkr
- name: Liu Fengyun
github: liufengyun
{% endhighlight %}
```
Or `_data/members.csv`:
{% highlight text %}
```text
name,github
Tom Preston-Werner,mojombo
Eric Mill,konklone
Parker Moore,parkr
Liu Fengyun,liufengyun
{% endhighlight %}
```
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:
{% highlight html %}
{% raw %}
```liquid
<ul>
{% for member in site.data.members %}
<li>
@@ -69,16 +67,22 @@ You can now render the list of members in a template:
</li>
{% endfor %}
</ul>
```
{% endraw %}
{% endhighlight %}
{: .note .info }
If your Jekyll site has a lot of pages, such as with documentation websites, see the detailed examples in [how to build robust navigation for your site]({% link _tutorials/navigation.md %}).
## Example: Organizations
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:
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`:
{% highlight yaml %}
```yaml
username: jekyll
name: Jekyll
members:
@@ -87,22 +91,23 @@ members:
- name: Parker Moore
github: parkr
{% endhighlight %}
```
In `_data/orgs/doeorg.yml`:
{% highlight yaml %}
```yaml
username: doeorg
name: Doe Org
members:
- name: John Doe
github: jdoe
{% endhighlight %}
```
The organizations can then be accessed via `site.data.orgs`, followed by the file name:
The organizations can then be accessed via `site.data.orgs`, followed by the
file name:
{% highlight html %}
{% raw %}
```liquid
<ul>
{% for org_hash in site.data.orgs %}
{% assign org = org_hash[1] %}
@@ -114,5 +119,37 @@ The organizations can then be accessed via `site.data.orgs`, followed by the fil
</li>
{% endfor %}
</ul>
```
{% endraw %}
{% endhighlight %}
## Example: Accessing a specific author
Pages and posts can also access a specific data item. The example below shows how to access a specific item:
`_data/people.yml`:
```yaml
dave:
name: David Smith
twitter: DavidSilvaSmith
```
The author can then be specified as a page variable in a post's frontmatter:
For information on how to build robust navigation for your site (especially if you have a documentation website or another type of Jekyll site with a lot of pages to organize), see [Navigation](/tutorials/navigation).
Sites built using Jekyll can be deployed in a large number of ways due to the static nature of the generated output. A few of the most common deployment techniques are described below.
<div class="note">
<h5>ProTip™: Use GitHub Pages for zero-hassle Jekyll hosting</h5>
<p>GitHub Pages are powered by Jekyll behind the scenes, so if you’re looking for a zero-hassle, zero-cost solution, GitHub Pages are a great way to <a href="../github-pages/">host your Jekyll-powered website for free</a>.</p>
</div>
## Netlify
Netlify provides Global CDN, Continuous Deployment, one click HTTPS and [much more](https://www.netlify.com/features/), providing developers the most robust toolset available for modern web projects, without added complexity. Netlify supports custom plugins for Jekyll and has a free plan for open source projects.
Read this [Jekyll step-by-step guide](https://www.netlify.com/blog/2015/10/28/a-step-by-step-guide-jekyll-3.0-on-netlify/) to setup your Jekyll site on Netlify.
## Aerobatic
[Aerobatic](https://www.aerobatic.com) has custom domains, global CDN distribution, basic auth, CORS proxying, and a growing list of plugins all included.
Automating the deployment of a Jekyll site is simple. See their [Jekyll docs](https://www.aerobatic.com/docs/static-site-generators/#jekyll) for more details. Your built `_site` folder is deployed to their highly-available, globally distributed hosting service.
## Kickster
Use [Kickster](http://kickster.nielsenramon.com/) for easy (automated) deploys to GitHub Pages when using unsupported plugins on GitHub Pages.
Kickster provides a basic Jekyll project setup packed with web best practises and useful optimization tools increasing your overall project quality. Kickster ships with automated and worry-free deployment scripts for GitHub Pages.
Setting up Kickster is very easy, just install the gem and you are good to go. More documentation can here found [here](https://github.com/nielsenramon/kickster#kickster). If you do not want to use the gem or start a new project you can just copy paste the deployment scripts for [Travis CI](https://github.com/nielsenramon/kickster/tree/master/snippets/travis) or [Circle CI](https://github.com/nielsenramon/kickster#automated-deployment-with-circle-ci).
## Web hosting providers (FTP)
Just about any traditional web hosting provider will let you upload files to their servers over FTP. To upload a Jekyll site to a web host using FTP, simply run the `jekyll build` command and copy the contents of the generated `_site` folder to the root folder of your hosting account. This is most likely to be the `httpdocs` or `public_html` folder on most hosting providers.
## Self-managed web server
If you have direct access to the deployment web server, the process is essentially the same, except you might have other methods available to you (such as `scp`, or even direct filesystem access) for transferring the files. Just remember to make sure the contents of the generated `_site` folder get placed in the appropriate web root directory for your web server.
## Automated methods
There are also a number of ways to easily automate the deployment of a Jekyll site. If you’ve got another method that isn’t listed below, we’d love it if you [contributed](../contributing/) so that everyone else can benefit too.
### Git post-update hook
If you store your Jekyll site in [Git](https://git-scm.com/) (you are using
version control, right?), it’s pretty easy to automate the
deployment process by setting up a post-update hook in your Git
To have a remote server handle the deploy for you every time you push changes using Git, you can create a user account which has all the public keys that are authorized to deploy in its `authorized_keys` file. With that in place, setting up the post-receive hook is done as follows:
Deploying is now as easy as telling nginx or Apache to look at
`/var/www/myrepo` and running the following:
```sh
laptops$ git push deploy master
```
### Static Publisher
[Static Publisher](https://github.com/static-publisher/static-publisher) is another automated deployment option with a server listening for webhook posts, though it's not tied to GitHub specifically. It has a one-click deploy to Heroku, it can watch multiple projects from one server, it has an easy to user admin interface and can publish to either S3 or to a git repository (e.g. gh-pages).
### Rake
Another way to deploy your Jekyll site is to use [Rake](https://github.com/ruby/rake), [HighLine](https://github.com/JEG2/highline), and
[Net::SSH](https://github.com/net-ssh/net-ssh). A more complex example of deploying Jekyll with Rake that deals with multiple branches can be found in [Git Ready](https://github.com/gitready/gitready/blob/cdfbc4ec5321ff8d18c3ce936e9c749dbbc4f190/Rakefile).
### scp
Once you’ve generated the `_site` directory, you can easily scp its content using a
`tasks/deploy` shell script similar to [this deploy script][]. You’d obviously
need to change the values to reflect your site’s details. There is even [a
matching TextMate command][] that will help you run this script.
Once you’ve generated the `_site` directory, you can easily rsync its content using a `tasks/deploy` shell script similar to [this deploy script here](https://github.com/vitalyrepin/vrepinblog/blob/master/transfer.sh). You’d obviously need to change the values to reflect your site’s details.
Certificate-based authorization is another way to simplify the publishing
process. It makes sense to restrict rsync access only to the directory which it is supposed to sync. This can be done using rrsync.
#### Step 1: Install rrsync to your home folder (server-side)
If it is not already installed by your host, you can do it yourself:
#### Step 4 (Optional): Exclude the transfer script from being copied to the output folder.
This step is recommended if you use these instructions to deploy your site. If
you put the `deploy` script in the root folder of your project, Jekyll will
copy it to the output folder. This behavior can be changed in `_config.yml`.
Just add the following line:
```yaml
# Do not copy these files to the output directory
exclude:["deploy"]
```
Alternatively, you can use an `rsync-exclude.txt` file to control which files will be transferred to your server.
#### Done!
Now it's possible to publish your website simply by running the `deploy`
script. If your SSH certificate is [passphrase-protected](https://martin.kleppmann.com/2013/05/24/improving-security-of-ssh-private-keys.html), you will be asked to enter it when the
script executes.
## Rack-Jekyll
[Rack-Jekyll](https://github.com/adaoraul/rack-jekyll/) is an easy way to deploy your site on any Rack server such as Amazon EC2, Slicehost, Heroku, and so forth. It also can run with [shotgun](https://github.com/rtomayko/shotgun/), [rackup](https://github.com/rack/rack), [mongrel](https://github.com/mongrel/mongrel), [unicorn](https://github.com/defunkt/unicorn/), and [others](https://github.com/adaoraul/rack-jekyll#readme).
Read [this post](http://andycroll.com/ruby/serving-a-jekyll-blog-using-heroku/) on how to deploy to Heroku using Rack-Jekyll.
## Jekyll-Admin for Rails
If you want to maintain Jekyll inside your existing Rails app, [Jekyll-Admin](https://github.com/zkarpinski/Jekyll-Admin) contains drop in code to make this possible. See Jekyll-Admin’s [README](https://github.com/zkarpinski/Jekyll-Admin/blob/master/README) for more details.
## Amazon S3
If you want to host your site in Amazon S3, you can do so by
using the [s3_website](https://github.com/laurilehmijoki/s3_website)
application. It will push your site to Amazon S3 where it can be served like
any web server,
dynamically scaling to almost unlimited traffic. This approach has the
benefit of being about the cheapest hosting option available for
low-volume blogs as you only pay for what you use.
## OpenShift
If you'd like to deploy your site to an OpenShift gear, there's [a cartridge
for that](https://github.com/openshift-quickstart/jekyll-openshift).
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.
## Web Highlights and Commenting
Register your site with [txtpen](https://txtpen.com). Then append
```html
<script src="https://txtpen.com/embed.js?site=<your site name>"></script>
```
to your template files in `/_layout` folder.
## Math Support
Kramdown comes with optional support for LaTeX to PNG rendering via [MathJax](http://www.mathjax.org/) within math blocks. See the Kramdown documentation on [math blocks](http://kramdown.gettalong.org/syntax.html#math-blocks) and [math support](http://kramdown.gettalong.org/converter/html.html#math-support) for more details.
Kramdown comes with optional support for LaTeX to PNG rendering via [MathJax](https://www.mathjax.org) within math blocks. See the Kramdown documentation on [math blocks](http://kramdown.gettalong.org/syntax.html#math-blocks) and [math support](http://kramdown.gettalong.org/converter/html.html#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](http://gastonsanchez.com/visually-enforced/opinion/2014/02/16/Mathjax-with-jekyll/).
The `include` tag allows you to include the content from another file stored in the `_includes` folder:
{% raw %}
```liquid
{% include footer.html %}
```
{% endraw %}
Jekyll will look for the referenced file (in this case, `footer.html`) in the `_includes` directory at the root of your source directory and insert its contents.
### Including files relative to another file
You can choose to include file fragments relative to the current file by using the `include_relative` tag:
{% raw %}
```liquid
{% include_relative somedir/footer.html %}
```
{% endraw %}
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.
Note that you cannot use the `../` syntax to specify an include location that refers to a higher-level directory.
All the other capabilities of the `include` tag are available to the `include_relative` tag,
such as variables.
### Using variables names for the include file
The name of the file you want to embed can be specified as a variable instead of an actual file name. For example, suppose you defined a variable in your page's front matter like this:
```yaml
---
title:My page
my_variable:footer_company_a.html
---
```
You could then reference that variable in your include:
{% raw %}
```liquid
{% include {{ page.my_variable }} %}
```
{% endraw %}
In this example, the include would insert the file `footer_company_a.html` from the `_includes/footer_company_a.html` directory.
### Passing parameters to includes
You can also pass parameters to an include. For example, suppose you have a file called `note.html` in your `_includes` folder that contains this formatting:
The `{% raw %}{{ include.content }}{% endraw %}` is a parameter that gets populated when you call the include and specify a value for that parameter, like this:
{% raw %}
```liquid
{% include note.html content="This is my sample note." %}
```
{% endraw %}
The value of `content` (which is `This is my sample note`) will be inserted into the {% raw %}`{{ include.content }}`{% endraw %} parameter.
Passing parameters to includes is especially helpful when you want to hide away complex formatting from your Markdown content.
For example, suppose you have a special image syntax with complex formatting, and you don't want your authors to remember the complex formatting. As a result, you decide to simplify the formatting by using an include with parameters. Here's an example of the special image syntax you might want to populate with an include:
```html
<figure>
<ahref="http://jekyllrb.com">
<imgsrc="logo.png"style="max-width: 200px;"
alt="Jekyll logo"/>
<figcaption>This is the Jekyll logo</figcaption>
</figure>
```
You could templatize this content in your include and make each value available as a parameter, like this:
The result is the original HTML code shown earlier.
To safeguard situations where users don't supply a value for the parameter, you can use [Liquid's default filter](https://shopify.github.io/liquid/filters/default/).
Overall, you can create includes that act as templates for a variety of uses — inserting audio or video clips, alerts, special formatting, and more. However, note that you should avoid using too many includes, as this will slow down the build time of your site. For example, don't use includes every time you insert an image. (The above technique shows a use case for special images.)
### Passing parameter variables to includes
Suppose the parameter you want to pass to the include is a variable rather than a string. For example, you might be using {% raw %}`{{ site.product_name }}`{% endraw %} to refer to every instance of your product rather than the actual hard-coded name. (In this case, your `_config.yml` file would have a key called `product_name` with a value of your product's name.)
The string you pass to your include parameter can't contain curly braces. For example, you can't pass a parameter that contains this: {% raw %}`"The latest version of {{ site.product_name }} is now available."`{% endraw %}
If you want to include this variable in your parameter that you pass to an include, you need to store the entire parameter as a variable before passing it to the include. You can use `capture` tags to create the variable:
{% raw %}
```liquid
{% capture download_note %}
The latest version of {{ site.product_name }} is now available.
{% endcapture %}
```
{% endraw %}
Then pass this captured variable into the parameter for the include. Omit the quotation marks around the parameter content because it's no longer a string (it's a variable):
{% raw %}
```liquid
{% include note.html content=download_note %}
```
{% endraw %}
### Passing references to YAML files as parameter values
Instead of passing string variables to the include, you can pass a reference to a YAML data file stored in the `_data` folder.
Here's an example. In the `_data` folder, suppose you have a YAML file called `profiles.yml`. Its content looks like this:
```yaml
- name:John Doe
login_age:old
image:johndoe.jpg
- name:Jane Doe
login_age:new
image:janedoe.jpg
```
In the `_includes` folder, assume you have a file called `spotlight.html` with this code:
{% raw %}
```liquid
{% for person in include.participants %}
{% if person.login_age == "new" %}
{{ person.name }}
{% endif %}
{% endfor %}
```
{% endraw %}
Now when you insert the `spotlight.html` include file, you can submit the YAML file as a parameter:
{% raw %}
```liquid
{% include spotlight.html participants=site.data.profiles %}
```
{% endraw %}
In this instance, `site.data.profiles` gets inserted in place of {% raw %}`include.participants`{% endraw %} in the include file, and the Liquid logic processes. The result will be `Jane Doe`.
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 content, customizing your build, and deploying.
## What is Jekyll, exactly?
Jekyll is a simple, blog-aware, static site generator.
You create your content as text files ([Markdown](https://daringfireball.net/projects/markdown/)), and organize them into folders. Then, you build the shell of your site using [Liquid](https://shopify.github.io/liquid/)-enhanced HTML templates. Jekyll automatically stitches the content and templates together, generating a website made entirely of static assets, suitable for uploading to any server.
Jekyll happens to be the engine behind [GitHub Pages](https://pages.github.com), so you can host your project’s Jekyll page/blog/website on GitHub’s servers **for free**.
## Navigating the Guide
Throughout this guide, you'll see these special sections that help you get the most out of Jekyll:
<div class="note">
<h5>ProTips™</h5>
<p>Tips and tricks that'll make you a Jekyll wizard!</p>
</div>
<div class="note info">
<h5>Notes</h5>
<p>Extra tidbits that are sometimes necessary to understand Jekyll.</p>
</div>
<div class="note warning">
<h5>Warnings</h5>
<p>Common pitfalls to avoid.</p>
</div>
<div class="note unreleased">
<h5>Unreleased</h5>
<p>Features planned for future versions of Jekyll, but not available yet.</p>
</div>
If you find anything we haven’t covered, or would like to share a tip that others might find handy, please [file an issue]({{ site.repository }}/issues/new) and we’ll see about adding it to the guide.
description: Official guide to install Jekyll on macOS, GNU/Linux or Windows.
permalink: /docs/installation/
---
Jekyll is a [Ruby Gem](http://guides.rubygems.org/rubygems-basics/), and can be
installed on most systems.
- [Requirements](#requirements)
- [Install Jekyll on macOS](#macOS)
- [Install Jekyll on Ubuntu Linux](#ubuntu)
- [Install Jekyll on Windows](../windows/)
- [Upgrade Jekyll](#upgrade-jekyll)
## Requirements
Before you start, make sure your system has the following:
- [Ruby](https://www.ruby-lang.org/en/downloads/) version 2.2.5 or above, including all development headers (ruby installation can be checked by running `ruby -v`)
- [RubyGems](https://rubygems.org/pages/download) (which you can check by running `gem -v`)
- [GCC](https://gcc.gnu.org/install/) and [Make](https://www.gnu.org/software/make/) (in case your system doesn't have them installed, which you can check by running `gcc -v`,`g++ -v` and `make -v` in your system's command line interface)
## Install on macOS {#macOS}
We only cover macOS High Sierra 10.13 here, which comes with Ruby 2.3.3, older systems will need to [install a more recent Ruby version via Homebrew](#homebrew).
First, you need to install the command-line tools to be able to compile native extensions, open a terminal and run:
```sh
xcode-select --install
```
### Set up Ruby included with the OS
Check your Ruby version meet our requirements:
```sh
ruby -v
2.3.3
```
Great, let's install Jekyll. We also need [Bundler](https://bundler.io/) to help us handle [plugins](../plugins) and [themes](../themes):
```sh
gem install bundler jekyll
```
That's it, you're ready to go, either by installing our [default minimal blog theme](https://github.com/jekyll/minima) with `jekyll new jekyll-website` or by starting from scratch:
```sh
mkdir jekyll-website
cd jekyll-website
# Create a Gemfile
bundle init
# Add Jekyll
bundle add jekyll
# Install gems
bundle install
```
Great, from there you can now either use a [theme](../themes/) or [create your own layouts](../templates/).
### Install a newer Ruby version via Homebrew {#homebrew}
If you wish to install the latest version of Ruby and get faster builds, we recommend to do it via [Homebrew](https://brew.sh) a handy package manager for macOS.
### Install multiple Ruby versions with rbenv {#rbenv}
Developers often use [rbenv](https://github.com/rbenv/rbenv) to manage multiple Ruby versions. This can be useful if you want to run the same Ruby version used by [GitHub Pages](https://pages.github.com/versions/) or [Netlify](https://www.netlify.com/docs/#ruby) for instance.
That's it! Head over [rbenv command references](https://github.com/rbenv/rbenv#command-reference) to learn how to use different versions of Ruby in your projects.
<div class="note info" markdown="1">
##### Problems installing Jekyll?
Check out the [troubleshooting](../troubleshooting/) page or
[ask for help on our forum](https://talk.jekyllrb.com).
</div>
## Install on Ubuntu Linux {#ubuntu}
Before we install Jekyll, we need to make sure we have all the required
Before you start developing with Jekyll, you may want to check that you're up to date with the latest version. To find the currently installed version of Jekyll, run one of these commands:
```sh
jekyll --version
gem list jekyll
```
You can use RubyGems to find [the current version of Jekyll](https://rubygems.org/gems/jekyll). Another way to check if you have the latest version is to run the command `gem outdated`. This will provide a list of all the gems on your system that need to be updated. If you aren't running the latest version, run this command:
```sh
bundle update jekyll
```
Alternatively, if you don't have Bundler installed run:
```sh
gem update jekyll
```
To upgrade to latest Rubygems, run:
```
gem update --system
```
Refer to our [upgrading section](../upgrading/) to upgrade from Jekyll 2.x or 1.x.
## Pre-releases
In order to install a pre-release, make sure you have all the requirements
installed properly and run:
```sh
gem install jekyll --pre
```
This will install the latest pre-release. If you want a particular pre-release,
use the `-v` switch to indicate the version you'd like to install:
```sh
gem install jekyll -v '2.0.0.alpha.1'
```
If you'd like to install a development version of Jekyll, the process is a bit
more involved. This gives you the advantage of having the latest and greatest,
but may be unstable.
```sh
git clone git://github.com/jekyll/jekyll.git
cd jekyll
script/bootstrap
bundle exec rake build
ls pkg/*.gem | head -n 1| xargs gem install -l
```
Now that you’ve got everything up-to-date and installed, let’s get to work!
**This guide is for affinity team captains.** These special people are **team maintainers** of one of our [affinity teams][] and help triage and evaluate the issues and contributions of others. You may find what is written here interesting, but it’s definitely not for everyone.
{: .note .info }
## Affinity teams & their captains
The Jekyll project uses [affinity teams][] to help break up the work of incoming issues and pull requests from community members. We receive a sizeable number of issues and pull requests each week; the use of affinity teams helps distribute this load across a number of specialized groups instead of pushing it all onto @jekyll/core.
## Responsibilities of Team Captains
Each affinity team has a few captains who manage the issues and pull requests for that team. When an issue or PR is opened with a `/cc` for a given affinity team, @jekyllbot automatically assigns a random affinity team captain to the issue to triage it. They have access to add labels, reassign the issue, give LGTM's, and so forth. While they do not merge PR's today, they are still asked to review PR's for parts of the codebase under their purview.
## How do I become a team captain?
Just ask! Feel free to open an issue on `jekyll/jekyll` and add `/cc @jekyll/core`. We can add you. :smile:
Alternatively, you can email or otherwise reach out to [@parkr](https://github.com/parkr) directly if you prefer the more private route.
## Ugh, I'm tired and don't have time to be a captain anymore. What now?
No sweat at all! Email [@parkr](https://github.com/parkr) and ask to be removed. Alternatively, you should be able to go to your team's page on GitHub.com (go to https://github.com/jekyll, click "Teams", click the link to your team) and change your status to either "member" or leave the team.
We realize that being a captain is no easy feat so we want to make it a great experience. As always, communicate as much as you can with us about what is working, and what isn't. Thanks for dedicating some time to Jekyll! :sparkles:
**This guide is for maintainers.** These special people have **write access** to one or more of Jekyll's repositories and help merge the contributions of others. You may find what is written here interesting, but it’s definitely not for everyone.
{: .note .info }
# 1. Use Jekyll
Maintainers of Jekyll should be using it regularly. This is partly because you won't be a good maintainer unless you can put yourself in the shoes of our users, but also because you may at some point decide to stop using Jekyll, and at that point you should also decide to stop being a maintainer and find other things to work on.
# 2. No Guilt About Leaving
All maintainers can stop working on Jekyll at any time without any guilt or explanation (like at a job). We may still ask for your help with questions after you leave but you are under no obligation to answer them. If you create a big mess and then leave you still have no obligations but we may think less of you (or, realistically, probably just revert the problematic work). Also, you should probably take a break from Jekyll at least a few times a year.
This also means contributors should be consumers. If a maintainer finds they are not using a project in the real-world, they should reconsider their involvement with the project.
# 3. Prioritise Maintainers Over Users
It's important to be user-focused but ultimately, as long as you follow #1 above, Jekyll's minimum number of users will be the number of maintainers. However, if Jekyll has no maintainers it will quickly become useless to all users and the project will die. As a result, no user complaint, behaviour or need takes priority over the burnout of maintainers. If users do not like the direction of the project, the easiest way to influence it is to make significant, high-quality code contributions and become a maintainer.
# 4. Learn To Say No
Jekyll gets a lot of feature requests, non-reproducible bug reports, usage questions and PRs we won't accept. These should be closed out as soon as we realise that they aren't going to be resolved or merged. This is kinder than deciding this after a long period of review. Our issue tracker should reflect work to be done.
---
Thanks to https://gist.github.com/ryanflorence/124070e7c4b3839d4573 which influenced this document.
Thanks to [Homebrew's "Avoiding Burnout" document](https://github.com/Homebrew/brew/blob/master/docs/Maintainers-Avoiding-Burnout.md) for providing a perfect base for this document.
**This guide is for contributors.** These special people have contributed to one or more of Jekyll's repositories, but do not yet have write access to any. You may find what is written here interesting, but it’s definitely not for everyone.
{: .note .info }
So you want to become a maintainer of a Jekyll project? We'd love to have you! Here are some things we like to see from community members before we promote them to maintainers.
## 1. Use Jekyll
You want to maintain Jekyll? Use it often. Do weird things with it. Do normal things with it. Does it work? Does it have any weaknesses? Is there a gap in the product that you think should be filled?
## 2. Help Triage Issues
Watch the repository you're interested in. Join [an Affinity Team](https://teams.jekyllrb.com) and receive mentions regarding a particular interest area of the project. When you receive a notification for an issue that has not been triaged by a maintainer, dive in. Can you reproduce the issue? Can you determine the fix? [More tips on Triaging an Issue in our maintainer guide](../triaging-an-issue). Every maintainer loves an issue that is resolved before they get to it. :smiley:
## 3. Write Documentation
Good documentation means less confusion for our users and fewer issues to triage. Documentation is always in need of fixes and updates as we change the code. Read through the documentation during your normal usage of the product and submit changes as you feel they are necessary.
## 4. Write Code
As a maintainer, you will be reviewing pull requests which update code. You should feel comfortable with the Jekyll codebase enough to confidently review any pull request put forward. In order to become more comfortable, write some code of your own and send a pull request. A great place to start is with any issue labeled "bug" in the issue tracker. Write a test which replicates the problem and fails, then work on fixing the code such that the test passes.
## 5. Review Pull Requests
Start by reviewing one pull request a week. Leave detailed comments and [follow our guide for reviewing pull requests](../reviewing-a-pull-request).
## 6. Ask!
Open an issue describing your contributions to the project and why you wish to be a maintainer. Issues are nice because you can easily reference where you have demonstrated that you help triage issues, write code & documentation, and review pull requests. You may also email any maintainer privately if you do not feel comfortable asking in the open.
We would love to expand the team and look forward to many more community members becoming maintainers!
# Helping Out Elsewhere
In addition to maintainers of our core and plugin code, the Jekyll team is comprised of moderators for our forums. These helpful community members take a look at the topics posted to [https://talk.jekyllrb.com](https://talk.jekyllrb.com) and ensure they are properly categorized and are acceptable under our Code of Conduct. If you would like to be a moderator, email one of the maintainers with links to where you have answered questions and a request to be added as a moderator. More help is always welcome.
**This guide is for Jekyll contributors and maintainers.** These special people contribute to one or more of Jekyll's repositories or help merge the contributions of others. You may find what is written here interesting, but it’s definitely not for everyone.
{: .note .info }
Hello! This is where we document various processes for maintaining Jekyll. Being a maintainer for any Jekyll project is a big responsibility, so we put together some helpful documentation for various tasks you might do as a maintainer.
- [Affinity teams & their captains](affinity-team-captain/)
- [Triaging an issue](triaging-an-issue/)
- [Reviewing a pull request](reviewing-a-pull-request/)
- [Merging a pull request](merging-a-pull-request/)
- [Avoiding burnout](avoiding-burnout/)
- [Special Labels](special-labels/)
- [Releasing a new version](releasing-a-new-version/)
Interested in becoming a maintainer? Here is some documentation for **contributors**:
**This guide is for maintainers.** These special people have **write access** to one or more of Jekyll's repositories and help merge the contributions of others. You may find what is written here interesting, but it’s definitely not for everyone.
{: .note .info }
## Code Review
All pull requests should be subject to code review. Code review is a [foundational value](https://blog.fullstory.com/what-we-learned-from-google-code-reviews-arent-just-for-catching-bugs-b125a13aa292) of good engineering teams. Besides providing validation of correctness, it promotes a sense of community and gives other maintainers understanding of all parts of the code base. In short, code review is crucial to a healthy open source project.
**Read our guide for [Reviewing a pull request](../reviewing-a-pull-request) before merging.** Notably, the change must have tests if for code, and at least two maintainers must give it an OK.
## Merging
We have [a helpful little bot](https://github.com/jekyllbot) which we use to merge pull requests. We don't use the GitHub.com interface for two reasons:
1. You can't modify anything on mobile (e.g. titles, labels)
2. We like to provide a consistent paper trail in the `History.markdown` file for each release
To merge a pull request, leave a comment thanking the contributor, then add the special merge request:
```text
Thank you very much for your contribution. Folks like you make this project and community strong. :heart:
@jekyllbot: merge +dev
```
The merge request is made up of three things:
1.`@jekyllbot:`– this is the prefix our bot looks for when processing commands
2.`merge`– the command
3.`+dev`– the category to which the changes belong.
The categories match the headings in the `History.markdown` file, and they are:
1. Major Enhancements (`+major`) – major updates or breaking changes to the code which necessitate a major version bump (v3 ~> v4)
2. Minor Enhancements (`+minor`) – minor updates (with the labels `feature` or `enhancement`) which necessitate a minor version bump (v3.1 ~> v3.2)
3. Bug Fixes (`+bug`) – corrections to code which do not change or add functionality, which necessitate a patch version bump (v3.1.0 ~> v3.1.1)
4. Documentation (`+doc`) - changes to the documentation found in `docs/_docs/`
5. Site Enhancements (`+site`) – changes to the source of [https://jekyllrb.com](https://jekyllrb.com) found in `docs/`
6. Development Fixes (`+dev`) – changes which do not affect user-facing functionality or documentation, such as test fixes or bumping internal dependencies
7. Forward Ports (`+port`) — bug fixes applied to a previous version of Jekyll pulled onto `master`, e.g. cherry-picked commits from `3-1-stable` to `master`
Once @jekyllbot has merged the pull request, you should see three things:
1. A successful merge
2. Addition of labels for the necessary category if they aren't already applied
3. A commit to the `History.markdown` file which adds a note about the change
If you forget the category, that's just fine. You can always go back and move the line to the proper category header later. The category is always necessary for `jekyll/jekyll`, but many plugins have too few changes to necessitate changelog categories.
## Rejoice
You did it! Thanks for being a maintainer for one of our official Jekyll projects. Your work means the world to our thousands of users who rely on Jekyll daily. :heart:
**This guide is for maintainers.** These special people have **write access** to one or more of Jekyll's repositories and help merge the contributions of others. You may find what is written here interesting, but it’s definitely not for everyone.
{: .note .info }
The most important thing to understand before making a release is that there's no need to feel nervous. Most things are revertable, and even if you do publish an incomplete gem version, we can always skip that one. Don't hestitate to contact the other maintainers if you feel unsure or don't know what to do next.
### Bump the version
The only important place you need to manually bump the version is in `lib/jekyll/version.rb`. Adjust that, and everything else should work fine.
### Update the history document
Replace the first header of the history document with a version milestone. This looks like the following:
```diff
-## HEAD
+## 3.7.1 / 2018-01-25
```
Adjust the version number and the date. The `## HEAD` heading will be regenerated next time a pull request is merged.
Once you've done this, update the website by running the following command:
```sh
bundle exec rake site:generate
```
This updates the website's changelog, and pushes the versions in various other places.
It's recommended that you go over the `History.markdown` file manually one more time, in case there are any spelling errors or such. Feel free to fix those manually, and after you're done generating the website changelog, commit your changes.
## Write a release post
In case this isn't done already, you can generate a new release post using the included `rake` command:
```sh
bundle exec rake site:releases:new[3.8.0]
```
where `3.8.0` should be replaced with the new version. Then, write the post. Be sure to thank all of the collaborators and maintainers who have contributed since the last release. You can generate a log of their names using the following command:
```sh
git shortlog -sn master...v3.7.2
```
where, again `v3.7.2` is the last release. Be sure to open a pull request for your release post.
### Push the version
Before you do this step, make sure the following things are done:
- You have permission to push a new gem version to RubyGems
- You're logged into RubyGems on your command line
- A release post has been prepared, and is ideally already live
- All of the prior steps are done, committed, and pushed to `master`
Really the only thing left to do is to run this command:
```sh
bundle exec rake release
```
This will automatically build the new gem, make a release commit and tag and then push the new gem to RubyGems. Don't worry about creating a GitHub release, @jekyllbot should take care of that.
And then, you're done! :tada: Feel free to celebrate!
If you have access to the [@jekyllrb](https://twitter.com/jekyllrb) Twitter account, you should tweet the release post from there. If not, just ask another maintainer to do it or to give you access.
### Build the docs
We package our documentation as a :gem: Gem for offline use.
**This guide is for maintainers.** These special people have **write access** to one or more of Jekyll's repositories and help merge the contributions of others. You may find what is written here interesting, but it’s definitely not for everyone.
{: .note .info }
## Respond Kindly
Above all else, please review a pull request kindly. Our community can only be strong if we make it a welcoming and inclusive environment. To further promote this, the Jekyll community is governed by a [Code of Conduct](/docs/conduct/) by which all community members must abide.
Use emoji liberally :heart: :tada: :sparkles: :confetti_ball: and feel free to be emotive!! Contributions keep this project moving forward and we're always happy to receive them, even if the pull request isn't ultimately merged.
Mike McQuaid's post on the GitHub blog entitled ["Kindly Closing Pull Requests"](https://github.com/blog/2124-kindly-closing-pull-requests) is a great place to start. It describes various scenarios in which it would be acceptable to close a pull request for reasons other than lack of technical integrity or accuracy. Part of being kind is responding to and resolving pull requests quickly.
## Respond Quickly
We should be able to review all pull requests within one week. The only time initial review should take longer is if all the maintainers mysteriously took vacation during the same week. Promptness encourages frequent, high-quality contributions from community members and other maintainers.
If your response requires a response on the part of the author, please add the `pending-feedback` tag. @jekyllbot will automatically remove the tag once the author of the pull request responds.
## Resolve Quickly
Similarly, we should aim to resolve pull requests quickly. If a pull request introduces a feature which does not fit into the core purpose or goal of the project, close it promptly with a kind explanation of why it is not acceptable.
Leave detailed comments wherever possible. Provide the contributor with context around why the change you are requesting is necessary, or why the question you are asking is important to resolve. The more context we can clearly communicate to the contributor, the better able the contributor is to provide high-quality patches.
You may close a pull request if more than 30 days pass without a response from the author.
In some cases, review will involve many weeks of back-and-forth. As long as communication continues, this is fine. Ideally, any PR would be capable of resolution within 30 days of it being opened.
## Look for Tests
If this is a code change, are there tests for the updated or added behaviour? Shipping a version with bugs is inevitable, but ensuring changes are tested helps keep bugs and regressions to a minimum.
## CI Must Pass
It is fine to ask a contributor to investigate failures on Travis and patch them up before you begin your review. It is helpful to leave a message for the contributor indicating that the tests have failed and that no review will occur before the tests pass. If they ask for help, take a look and assist if you can.
## Rule of Two
A pull request may be merged once two maintainers have reviewed the pull request and indicated that it is acceptable to them. There is no need to wait for a third unless one of the two reviewers wishes for another set of eyes.
## Think Security
We owe it to our users to ensure that using a theme from the community or building someone else's site doesn't come with built-in security vulnerabilities. Things like where files may be read from and written to are important to keep secure. Jekyll is also the basis for hosted services such as [GitHub Pages](https://pages.github.com), which cannot upgrade when security issues are introduced.
**This guide is for maintainers.** These special people have **write access** to one or more of Jekyll's repositories and help merge the contributions of others. You may find what is written here interesting, but it’s definitely not for everyone.
{: .note .info }
We use a series of "special labels" on GitHub.com to automate handling of some parts of the pull request and issue process. @jekyllbot may automatically apply or remove certain labels based on actions taken by users or maintainers. Below are the labels and how they work:
## `pending-feedback`
This label is used to indicate that we need more information from the issue/PR author in order to continue. It may be that you need more info before you can properly triage a bug report, or that you have some unanswered questions about a PR that need to be resolved before moving forward. You can safely ignore any issue with this label, as it is waiting for feedback.
## `needs-work` & `pending-rebase`
These labels are used to indicate that the Git state of a pull request must change. Both are removed once a push is registered (a "synchronize" event for the pull request) and the pull request becomes mergable. Add `needs-work` to a PR if, after your review, it requires code changes. Add `pending-rebase` to a PR if the code is fine but the branch is not automatically mergable with the target branch (e.g. `master`).
## `stale`
This label is automatically added and removed by @jekyllbot based on activity on an issue or pull request. The rules for this label are laid out in [Triaging an Issue: Staleness and automatic closure](../triaging-an-issue/#staleness-and-automatic-closure).
## `pinned`
This label is for @jekyllbot to ignore the age of the issue, which means that the `stale` label won't be automatically added, and the issue won't be closed after a while. This needs to be set manually, and should be set with care. (The `has-pull-request` label does the same thing, but shouldn't be used to _only_ keep an issue open)
**This guide is for maintainers.** These special people have **write access** to one or more of Jekyll's repositories and help merge the contributions of others. You may find what is written here interesting, but it’s definitely not for everyone.
{: .note .info }
Before evaluating an issue, it is important to identify if it is a feature
request or a bug. For the Jekyll project the following definitions are used
to identify a feature or a bug:
**Feature** - A feature is defined as a request that adds functionality to
Jekyll outside of its current capabilities.
**Bug** - A bug is defined as an issue that identifies an error that a user
(or users) encounter when using current Jekyll functionalities.
## Feature?
If the issue describes a feature request, ask:
1. Is this a setting? [Settings are a crutch](http://ben.balter.com/2016/03/08/optimizing-for-power-users-and-edge-cases/#settings-are-a-crutch) for doing "the right thing". Settings usually point to a bad default or an edge case that could be solved easily with a plugin. Keep the :christmas_tree: of settings as small as possible so as not to reduce the usability of the product. We like the philosophy "decisions not options."
2. Would at least 80% of users find it useful? If even a quarter of our users won't use it, it's very likely that the request doesn't fit our product's core goal.
3. Is there another way to accomplish the end goal of the request? Most feature requests are due to bad documentation for or understanding of a pre-existing feature. See if you can clarify the end goal of the request. What is the user trying to do? Could they accomplish that goal through another feature we already support?
4. Even if 80% of our users will use it, does it fit the core goal of our project? We are writing a tool for making static websites, not a swiss army knife for publishing more generally.
Feel free to get others' opinions and ask questions of the issue author, but depending upon the answers to the questions above, it may be out of scope for our project.
If the request is within scope, prioritize it on the product roadmap with the other maintainers. Apply the appropriate tags and ensure the right people have weighed in to define the feature's scope and implementation. If you want to be the _best ever_, submit a PR yourself which adds the feature.
## Bug?
### Reproducibility
If the bug has clear reproduction steps, take a minute to try them. If it helps, write a test in our test suite for the scenario which replicates the problem. Can you reliably replicate the issue?
If you can't replicate the issue, post your replication steps which didn't work and ask for clarification from the issue author.
### Supported Platform
Is the author using a supported platform? We support the latest versions of macOS, Ubuntu, Debian, CentOS, Fedora, and Arch Linux.
You may close the issue immediately if the author cannot reproduce the issue on a supported platform. For Windows-related problems, leave a comment letting the user know that Windows is not officially supported, but that they may absolutely continue using the issue to communicate with folks from `@jekyll/windows` to further investigate. Additionally, you can point them to Jekyll Talk (https://talk.jekyllrb.com) as a means of getting support from the community.
If the user is experiencing issues with GitHub Pages or another hosted platform that we cannot reproduce, please direct them to the platform's support channel and close the issue.
### What they wanted vs. what they got
An issue without a clear explanation of what the user got and what they were expecting to get is not an issue we can accurately respond to. If the user doesn't provide this information, please ask for clarification and apply the `pending-feedback` label. This information helps us build test cases such that we do not break the behaviour again in the future. The `pending-feedback` label will be removed automatically once the issue author posts a reply.
Is what they wanted to get something we want to happen? Sometimes a bug report is actually masquerading as a feature request. See the guidance above for handling feature requests.
### Staleness and automatic closure
@jekyllbot will automatically mark issues as `stale` if no activity occurs for at least one month. @jekyllbot leaves a comment asking for information about reproducibility in current versions. If no one responds after another month, the issue is automatically closed. This behaviour can be suppressed by setting the [`pinned` label](../maintaining/special-labels.md/#pinned).
In addition to [writing posts](../posts/), you might also want to add static pages (content that isn't date-based) to your Jekyll site. By taking advantage of the way Jekyll copies files and directories, this is easy to do.
## Homepage
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.
<div class="note">
<h5>ProTip™: Use layouts on your homepage</h5>
<p>
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.
</p>
</div>
## Where additional pages live
Where you put HTML or [Markdown](https://daringfireball.net/projects/markdown/)
files for pages depends on how you want the pages to work. There are two main ways of creating pages:
- Place named HTML or [Markdown](https://daringfireball.net/projects/markdown/)
files for each page in your site's root folder.
- Place pages inside folders and subfolders named whatever you want.
Both methods work fine (and can be used in conjunction with each other),
with the only real difference being the resulting URLs. By default, pages retain the same folder structure in `_site` as they do in the source directory.
### Named HTML files
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
If you have a lot of pages, you can organize those pages into subfolders. The same subfolders that are used to group your pages in our project's source will exist in the `_site` folder when your site builds.
## Flattening pages from subfolders into the root directory
If you have pages organized into subfolders in your source folder and want to flatten them in the root folder on build, you must add the [permalink]({% link _docs/permalinks.md %}) property directly in your page's front matter like this:
```yaml
---
title:My page
permalink:mypageurl.html
---
```
### Named folders containing index HTML files
If you don't want file extensions (`.html`) to appear in your page URLs (file extensions are the default), you can choose a [permalink style](../permalinks/#builtinpermalinkstyles) that has a trailing slash instead of a file extension.
Note if you want to view your site offline *without the Jekyll preview server*, your browser will need the file extension to display the page, and all assets will need to be relative links that function without the server baseurl.
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 has
pagination built-in, so you can automatically generate the appropriate files and
folders you need for paginated listings.
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 `plugins`. For Jekyll 2, this is standard.
<div class="note info">
<h5>Pagination only works within HTML files</h5>
<p>
Pagination does not work with Markdown or Textile files in your Jekyll site.
It will only work when used within HTML files. Since you’ll likely be using
this for the list of Posts, this shouldn’t be an issue.
Pagination does not work from within Markdown files from
your Jekyll site. Pagination works when called from within the HTML
file, named <code>index.html</code>, which optionally may reside in and
produce pagination from within a subdirectory, via the
<code>paginate_path</code> configuration value.
</p>
</div>
## Enable pagination
To enable pagination for your blog, add a line to the `_config.yml` file that
To enable pagination for posts on your blog, add a line to the `_config.yml` file that
specifies how many items should be displayed per page:
{% highlight yaml %}
```yaml
paginate: 5
{% endhighlight %}
```
The number should be the maximum number of Posts you’d like to be displayed per-
page in the generated site.
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:
{% highlight yaml %}
paginate_path: "blog/page:num/"
{% endhighlight %}
```yaml
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.
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.
<div class="note warning">
<h5>Don't set a permalink</h5>
<p>
Setting a permalink in the front matter of your blog page will cause
pagination to break. Just omit the permalink.
</p>
</div>
<div class="note info">
<h5>Pagination for categories, tags and collections</h5>
<p>
The more recent <a href="https://github.com/sverrirs/jekyll-paginate-v2">jekyll-paginate-v2</a> plugin supports more features. See the <a href="https://github.com/sverrirs/jekyll-paginate-v2/tree/master/examples">pagination examples</a> in the repository.
<strong>This plugin is not supported by GitHub Pages</strong>.
</p>
</div>
## Liquid Attributes Available
@@ -121,8 +140,8 @@ attributes:
<div class="note info">
<h5>Pagination does not support tags or categories</h5>
<p>Pagination pages through every post in the <code>posts</code>
variable regardless of variables defined in the YAML Front Matter of
each. It does not currently allow paging over groups of posts linked
variable unless a post has <code>hidden: true</code> in its YAML Front Matter.
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.</p>
</div>
@@ -130,12 +149,12 @@ attributes:
## Render the paginated 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:
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:
{% highlight html %}
{% raw %}
```liquid
---
layout: default
title: My Blog
@@ -166,8 +185,8 @@ title: My Blog
<span class="next ">Next</span>
{% endif %}
</div>
```
{% endraw %}
{% endhighlight %}
<div class="note warning">
<h5>Beware the page one edge-case</h5>
@@ -181,8 +200,8 @@ title: My Blog
The following HTML snippet should handle page one, and render a list of each
page with links to all but the current page.
{% highlight html %}
{% raw %}
```liquid
{% if paginator.total_pages > 1 %}
<div class="pagination">
{% if paginator.previous_page %}
@@ -195,7 +214,7 @@ page with links to all but the current page.
Permalinks refer to the URLs (excluding the domain name or directory folder) for your pages, posts, or collections.
Jekyll supports a flexible way to build permalinks, allowing you to leverage various template variables or choose built-in permalink styles (such as `date`) that automatically use a template-variable pattern.
You construct permalinks by creating a template URL where dynamic elements are represented by colon-prefixed keywords. The default template permalink is `/:categories/:year/:month/:day/:title:output_ext`. Each of the colon-prefixed keywords is a template variable.
## Where to configure permalinks
You can configure your site's permalinks through the [Configuration]({% link _docs/configuration.md %}) file or in the [Front Matter]({% link _docs/frontmatter.md %}) for each post, page, or collection.
Setting permalink styles in your configuration file applies the setting globally in your project. You configure permalinks in your `_config.yml` file like this:
If you don't specify any permalink setting, Jekyll uses the above pattern as the default.
The permalink can also be set using a built-in permalink style:
```yaml
permalink:date
```
`date` is the same as `:categories/:year/:month/:day/:title:output_ext`, the default. See [Built-in Permalink Styles](#builtinpermalinkstyles) below for more options.
Setting the permalink in your post, page, or collection's front matter overrides any global settings. Here's an example:
```yaml
---
title:My page title
permalink:/mypageurl/
---
```
Even if your configuration file specifies the `date` style, the URL for this page would be `http://somedomain.com/mypageurl/`.
When you use permalinks that omit the `.html` file extension (called "pretty URLs") Jekyll builds the file as index.html placed inside a folder with the page's name. For example:
```
├── mypageurl
│ └── index.html
```
With a URL such as `/mypageurl/`, servers automatically load the index.html file inside the folder, so users can simply navigate to `http://somedomain.com/mypageurl/` to get to `mypageurl/index.html`.
## Template variables for permalinks {#template-variables}
The following table lists the template variables available for permalinks. You can use these variables in the `permalink` property in your config file.
<div class="mobile-side-scroller">
<table>
<thead>
<tr>
<th>Variable</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr>
<td>
<p><code>year</code></p>
</td>
<td>
<p>
Year from the post's filename. May be overridden via the document’s
<code>date</code> YAML front matter
</p>
</td>
</tr>
<tr>
<td>
<p><code>month</code></p>
</td>
<td>
<p>
Month from the post's filename. May be overridden via the document’s
<code>date</code> YAML front matter
</p>
</td>
</tr>
<tr>
<td>
<p><code>i_month</code></p>
</td>
<td>
<p>
Month without leading zeros from the post's filename. May be
overridden via the document’s <code>date</code> YAML front matter
</p>
</td>
</tr>
<tr>
<td>
<p><code>day</code></p>
</td>
<td>
<p>
Day from the post's filename. May be overridden via the document’s
<code>date</code> YAML front matter
</p>
</td>
</tr>
<tr>
<td>
<p><code>i_day</code></p>
</td>
<td>
<p>
Day without leading zeros from the post's filename. May be overridden
via the document’s <code>date</code> YAML front matter
</p>
</td>
</tr>
<tr>
<td>
<p><code>y_day</code></p>
</td>_
<td>
<p>Day of the year from the post's filename, with leading zeros.</p>
</td>
</tr>
<tr>
<td>
<p><code>short_year</code></p>
</td>
<td>
<p>
Year without the century from the post's filename. May be overridden
via the document’s <code>date</code> YAML front matter
</p>
</td>
</tr>
<tr>
<td>
<p><code>hour</code></p>
</td>
<td>
<p>
Hour of the day, 24-hour clock, zero-padded from the post's
<code>date</code> front matter. (00..23)
</p>
</td>
</tr>
<tr>
<td>
<p><code>minute</code></p>
</td>
<td>
<p>
Minute of the hour from the post's <code>date</code> front matter. (00..59)
</p>
</td>
</tr>
<tr>
<td>
<p><code>second</code></p>
</td>
<td>
<p>
Second of the minute from the post's <code>date</code> front matter. (00..59)
</p>
</td>
</tr>
<tr>
<td>
<p><code>title</code></p>
</td>
<td>
<p>
Title from the document’s filename. May be overridden via
the document’s <code>slug</code> YAML front matter.
</p>
</td>
</tr>
<tr>
<td>
<p><code>slug</code></p>
</td>
<td>
<p>
Slugified title from the document’s filename (any character
except numbers and letters is replaced as hyphen). May be
overridden via the document’s <code>slug</code> YAML front matter.
</p>
</td>
</tr>
<tr>
<td>
<p><code>categories</code></p>
</td>
<td>
<p>
The specified categories for this post. If a post has multiple
categories, Jekyll will create a hierarchy (e.g. <code>/category1/category2</code>).
Also Jekyll automatically parses out double slashes in the URLs,
so if no categories are present, it will ignore this.
</p>
</td>
</tr>
</tbody>
</table>
</div>
Note that all template variables relating to time or categories are available to posts only.
Although you can specify a custom permalink pattern using [template variables](#template-variables), Jekyll also provides the following built-in styles for convenience.
<p>See <a href="#extensionless-permalinks">Extensionless permalinks with no trailing slashes</a> for details.</p>
</td>
<td>
<p><code>/2009/04/slap-chop</code></p>
</td>
</tr>
</tbody>
</table>
</div>
## Permalink settings for pages and collections {#pages-and-collections}
The permalink setting in your configuration file specifies the permalink style used for posts, pages, and collections. However, because pages and collections don't have time or categories, these aspects of the permalink style are ignored with pages and collections.
For example:
* A permalink style of `/:categories/:year/:month/:day/:title:output_ext` for posts becomes `/:title.html` for pages and collections.
* A permalink style of `pretty` (or `/:categories/:year/:month/:day/:title/`), which omits the file extension and contains a trailing slash, will update page and collection permalinks to also omit the file extension and contain a trailing slash: `/:title/`.
* A permalink style of `date`, which contains a trailing file extension, will update page permalinks to also contain a trailing file extension: `/:title.html`. But no time or category information will be included.
## Permalinks and default paths
The path to the post or page in the built site differs for posts, pages, and collections:
### Posts
The subfolders into which you may have organized your posts inside the `_posts` directory will not be part of the permalink.
If you use a permalink style that omits the `.html` file extension, each post is rendered as an `index.html` file inside a folder with the post's name (for example, `categoryname/2016/12/01/mypostname/index.html`).
### Pages
Unlike posts, pages by default mimic the source directory structure exactly. (The only exception is if your page has a `permalink` declared its front matter — in that case, the structure honors the permalink setting instead of the source folder structure.)
As with posts, if you use a permalink style that omits the `.html` file extension, each page is rendered as an `index.html` file inserted inside a folder with the page's name (for example, `mypage/index.html`).
### Collections
By default, collections follow a similar structure in the `_site` folder as pages, except that the path is prefaced by the collection name. For example: `collectionname/mypage.html`. For permalink settings that omit the file extension, the path would be `collection_name/mypage/index.html`.
Collections have their own way of setting permalinks. Additionally, collections have unique template variables available (such as `path` and `output_ext`). See the [Configuring permalinks for collections](../collections/#permalinks) in Collections for more information.
## Flattening pages in \_site on build
If you want to flatten your pages (pull them out of subfolders) in the `_site` directory when your site builds (similar to posts), add the `permalink` property to the front matter of each page, with no path specified:
```yaml
---
title:My page
permalink:mypageurl.html
---
```
## Extensionless permalinks with no trailing slashes {#extensionless-permalinks}
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 these types of 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](../github-pages/) and the Jekyll's built-in WEBrick server handle these requests properly without any additional work.
### Apache
The Apache web server has extensive support for content negotiation and can handle extensionless URLs by setting the [multiviews](https://httpd.apache.org/docs/current/content-negotiation.html#multiviews) option in your `httpd.conf` or `.htaccess` file:
{% highlight apache %}
Options +MultiViews
{% endhighlight %}
### Nginx
The [try_files](http://nginx.org/en/docs/http/ngx_http_core_module.html#try_files) directive allows you to specify a list of files to search for to process a request. The following configuration will instruct nginx to search for a file with an `.html` extension if an exact match for the requested URI is not found.
{% highlight nginx %}
try_files $uri $uri.html $uri/ =404;
{% endhighlight %}
## Linking without regard to permalink styles
You can create links in your topics to other posts, pages, or collection items in a way that is valid no matter what permalink configuration you choose. By using the `link` tag, if you change your permalinks, your links won't break. See [Linking to pages](../templates#link) in Templates for more details.
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.
<div class="note info">
<h5>Plugins on GitHub Pages</h5>
<p>
<a href="https://pages.github.com/">GitHub Pages</a> is powered by Jekyll.
However, all Pages sites are generated using the <code>--safe</code> option
to disable custom plugins for security reasons. Unfortunately, this means
your plugins won’t work if you’re deploying to GitHub Pages.<br><br>
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.
</p>
</div>
## Installing a plugin
You have 3 options for installing plugins:
1. In your site source root, make a `_plugins` directory. Place your plugins
here. Any file ending in `*.rb` inside this directory will be loaded before
Jekyll generates your site.
2. In your `_config.yml` file, add a new array with the key `plugins` (or `gems` for Jekyll < `3.5.0`) and the
values of the gem names of the plugins you'd like to use. An example:
```yaml
# This will require each of these plugins automatically.
plugins:
- jekyll-gist
- jekyll-coffeescript
- jekyll-assets
- another-jekyll-plugin
```
Then install your plugins using `gem install jekyll-gist jekyll-coffeescript jekyll-assets another-jekyll-plugin`
3. Add the relevant plugins to a Bundler group in your `Gemfile`. An
example:
```ruby
group :jekyll_plugins do
gem "jekyll-gist"
gem "jekyll-coffeescript"
gem "jekyll-assets"
gem "another-jekyll-plugin"
end
```
Now you need to install all plugins from your Bundler group by running single command `bundle install`.
<div class="note info">
<h5>
<code>_plugins</code>, <code>_config.yml</code> and <code>Gemfile</code>
can be used simultaneously
</h5>
<p>
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.
</p>
</div>
### The jekyll_plugins group
Jekyll gives this particular group of gems in your `Gemfile` a different
treatment. Any gem included in this group is loaded before Jekyll starts
processing the rest of your source directory.
A gem included here will be activated even if its not explicitly listed under
the `plugins:` key in your site's config file.
<div class="note warning">
<p>
Gems included in the <code>:jekyll-plugins</code> group are activated
regardless of the <code>--safe</code> mode setting. Be aware of what
gems are included under this group!
</p>
</div>
In general, plugins you make will fall broadly into one of five categories:
1. [Generators](#generators)
2. [Converters](#converters)
3. [Commands](#commands)
4. [Tags](#tags)
5. [Hooks](#hooks)
See the bottom of the page for a [list of available plugins](#available-plugins).
For further information on how to develop your own plugins, check out the [Liquid documentation](https://github.com/Shopify/liquid/wiki/Liquid-for-Programmers) as well.
If you never developed a Jekyll plugin [check this useful wrap-up](https://ayastreb.me/writing-a-jekyll-plugin/) by @ayastreb to get started.
## Generators
You can create a generator when you need Jekyll to create additional content
based on your own rules.
A generator is a subclass of `Jekyll::Generator` that defines a `generate`
method, which receives an instance of
[`Jekyll::Site`]({{ site.repository }}/blob/master/lib/jekyll/site.rb). The
return value of `generate` is ignored.
Generators run after Jekyll has made an inventory of the existing content, and
before the site is generated. Pages with YAML Front Matters are stored as
<code>:high</code>, and <code>:highest</code>. Highest priority
matches are applied first, lowest priority are applied last.
</p>
</td>
</tr>
</tbody>
</table>
</div>
To use one of the example plugins above as an illustration, here is how you’d
specify these two flags:
```ruby
module Jekyll
class UpcaseConverter < Converter
safe true
priority :low
...
end
end
```
## Hooks
Using hooks, your plugin can exercise fine-grained control over various aspects
of the build process. If your plugin defines any hooks, Jekyll will call them
at pre-defined points.
Hooks are registered to a container and an event name. To register one, you
call Jekyll::Hooks.register, and pass the container, event name, and code to
call whenever the hook is triggered. For example, if you want to execute some
custom functionality every time Jekyll renders a post, you could register a
hook like this:
```ruby
Jekyll::Hooks.register :posts, :post_render do |post|
# code to call after Jekyll renders a post
end
```
Jekyll provides hooks for <code>:site</code>, <code>:pages</code>,
<code>:posts</code>, and <code>:documents</code>. In all cases, Jekyll calls
your hooks with the container object as the first callback parameter. However,
all `:pre_render` hooks and the`:site, :post_render` hook will also provide a
payload hash as a second parameter. In the case of `:pre_render`, the payload
gives you full control over the variables that are available while rendering.
In the case of `:site, :post_render`, the payload contains final values after
rendering all the site (useful for sitemaps, feeds, etc).
The complete list of available hooks is below:
<div class="mobile-side-scroller">
<table>
<thead>
<tr>
<th>Container</th>
<th>Event</th>
<th>Called</th>
</tr>
</thead>
<tbody>
<tr>
<td>
<p><code>:site</code></p>
</td>
<td>
<p><code>:after_init</code></p>
</td>
<td>
<p>Just after the site initializes, but before setup & render. Good
for modifying the configuration of the site.</p>
</td>
</tr>
<tr>
<td>
<p><code>:site</code></p>
</td>
<td>
<p><code>:after_reset</code></p>
</td>
<td>
<p>Just after site reset</p>
</td>
</tr>
<tr>
<td>
<p><code>:site</code></p>
</td>
<td>
<p><code>:post_read</code></p>
</td>
<td>
<p>After site data has been read and loaded from disk</p>
</td>
</tr>
<tr>
<td>
<p><code>:site</code></p>
</td>
<td>
<p><code>:pre_render</code></p>
</td>
<td>
<p>Just before rendering the whole site</p>
</td>
</tr>
<tr>
<td>
<p><code>:site</code></p>
</td>
<td>
<p><code>:post_render</code></p>
</td>
<td>
<p>After rendering the whole site, but before writing any files</p>
</td>
</tr>
<tr>
<td>
<p><code>:site</code></p>
</td>
<td>
<p><code>:post_write</code></p>
</td>
<td>
<p>After writing the whole site to disk</p>
</td>
</tr>
<tr>
<td>
<p><code>:pages</code></p>
</td>
<td>
<p><code>:post_init</code></p>
</td>
<td>
<p>Whenever a page is initialized</p>
</td>
</tr>
<tr>
<td>
<p><code>:pages</code></p>
</td>
<td>
<p><code>:pre_render</code></p>
</td>
<td>
<p>Just before rendering a page</p>
</td>
</tr>
<tr>
<td>
<p><code>:pages</code></p>
</td>
<td>
<p><code>:post_render</code></p>
</td>
<td>
<p>After rendering a page, but before writing it to disk</p>
</td>
</tr>
<tr>
<td>
<p><code>:pages</code></p>
</td>
<td>
<p><code>:post_write</code></p>
</td>
<td>
<p>After writing a page to disk</p>
</td>
</tr>
<tr>
<td>
<p><code>:posts</code></p>
</td>
<td>
<p><code>:post_init</code></p>
</td>
<td>
<p>Whenever a post is initialized</p>
</td>
</tr>
<tr>
<td>
<p><code>:posts</code></p>
</td>
<td>
<p><code>:pre_render</code></p>
</td>
<td>
<p>Just before rendering a post</p>
</td>
</tr>
<tr>
<td>
<p><code>:posts</code></p>
</td>
<td>
<p><code>:post_render</code></p>
</td>
<td>
<p>After rendering a post, but before writing it to disk</p>
</td>
</tr>
<tr>
<td>
<p><code>:posts</code></p>
</td>
<td>
<p><code>:post_write</code></p>
</td>
<td>
<p>After writing a post to disk</p>
</td>
</tr>
<tr>
<td>
<p><code>:documents</code></p>
</td>
<td>
<p><code>:post_init</code></p>
</td>
<td>
<p>Whenever a document is initialized</p>
</td>
</tr>
<tr>
<td>
<p><code>:documents</code></p>
</td>
<td>
<p><code>:pre_render</code></p>
</td>
<td>
<p>Just before rendering a document</p>
</td>
</tr>
<tr>
<td>
<p><code>:documents</code></p>
</td>
<td>
<p><code>:post_render</code></p>
</td>
<td>
<p>After rendering a document, but before writing it to disk</p>
</td>
</tr>
<tr>
<td>
<p><code>:documents</code></p>
</td>
<td>
<p><code>:post_write</code></p>
</td>
<td>
<p>After writing a document to disk</p>
</td>
</tr>
</tbody>
</table>
</div>
## Available Plugins
You can find a few useful plugins at the following locations:
#### Generators
- [Sitemap.xml Generator by Michael Levin](https://github.com/kinnetica/jekyll-plugins): Generates a sitemap.xml file by traversing all of the available posts and pages.
- [Full-text search by Pascal Widdershoven](https://github.com/PascalW/jekyll_indextank): Adds full-text search to your Jekyll site with a plugin and a bit of JavaScript.
- [AliasGenerator by Thomas Mango](https://github.com/tsmango/jekyll_alias_generator): Generates redirect pages for posts when an alias is specified in the YAML Front Matter.
- [Pageless Redirect Generator by Nick Quinlan](https://github.com/nquinlan/jekyll-pageless-redirects): Generates redirects based on files in the Jekyll root, with support for htaccess style redirects.
- [RssGenerator by Assaf Gelber](https://github.com/agelber/jekyll-rss): Automatically creates an RSS 2.0 feed from your posts.
- [Monthly archive generator by Shigeya Suzuki](https://github.com/shigeya/jekyll-monthly-archive-plugin): Generator and template which renders monthly archive like MovableType style, based on the work by Ilkka Laukkanen and others above.
- [Category archive generator by Shigeya Suzuki](https://github.com/shigeya/jekyll-category-archive-plugin): Generator and template which renders category archive like MovableType style, based on Monthly archive generator.
- [Emoji for Jekyll](https://github.com/yihangho/emoji-for-jekyll): Seamlessly enable emoji for all posts and pages.
- [Compass integration for Jekyll](https://github.com/mscharley/jekyll-compass): Easily integrate Compass and Sass with your Jekyll website.
- [Pages Directory by Ben Baker-Smith](https://github.com/bbakersmith/jekyll-pages-directory): Defines a `_pages` directory for page files which routes its output relative to the project root.
- [Page Collections by Jeff Kolesky](https://github.com/jeffkole/jekyll-page-collections): Generates collections of pages with functionality that resembles posts.
- [Windows 8.1 Live Tile Generation by Matt Sheehan](https://github.com/sheehamj13/jekyll-live-tiles): Generates Internet Explorer 11 config.xml file and Tile Templates for pinning your site to Windows 8.1.
- [Typescript Generator by Matt Sheehan](https://github.com/sheehamj13/jekyll_ts): Generate Javascript on build from your Typescript.
- [Jekyll::AutolinkEmail by Ivan Tse](https://github.com/ivantsepp/jekyll-autolink_email): Autolink your emails.
- [Jekyll::GitMetadata by Ivan Tse](https://github.com/ivantsepp/jekyll-git_metadata): Expose Git metadata for your templates.
- [Jekyll Auto Image by Merlos](https://github.com/merlos/jekyll-auto-image): Gets the first image of a post. Useful to list your posts with images or to add [twitter cards](https://dev.twitter.com/cards/overview) to your site.
- [Jekyll Portfolio Generator by Shannon Babincsak](https://github.com/codeinpink/jekyll-portfolio-generator): Generates project pages and computes related projects out of project data files.
- [Jekyll-Umlauts by Arne Gockeln](https://github.com/webchef/jekyll-umlauts): This generator replaces all german umlauts (äöüß) case sensitive with html.
- [Jekyll Flickr Plugin](https://github.com/lawmurray/indii-jekyll-flickr) by [Lawrence Murray](http://www.indii.org): Generates posts for photos uploaded to a Flickr photostream.
- [Jekyll::Paginate::Category](https://github.com/midnightSuyama/jekyll-paginate-category): Pagination Generator for Jekyll Category.
- [AMP-Jekyll by Juuso Mikkonen](https://github.com/juusaw/amp-jekyll): Generate [Accelerated Mobile Pages](https://www.ampproject.org) of Jekyll posts.
- [Jekyll Art Gallery plugin](https://github.com/alexivkin/Jekyll-Art-Gallery-Plugin): An advanced art/photo gallery generation plugin for creating galleries from a set of image folders. Supports image tagging, thumbnails, sorting, image rotation, post-processing (remove EXIF, add watermark), multiple collections and much more.
- [jekyll-ga](https://github.com/developmentseed/jekyll-ga): A Jekyll plugin that downloads Google Analytics data and adds it to posts. Useful for making a site that lists "most popular" content. [Read the introduction](https://developmentseed.org/blog/google-analytics-jekyll-plugin/) post on the developmentSEED blog.
- [jekyll-multi-paginate](https://github.com/fadhilnapis/jekyll-multi-paginate): Simple Jekyll paginator for multiple page. Ease you to make pagination on multiple page especially like multiple language.
- [jekyll-category-pages](https://github.com/field-theory/jekyll-category-pages): Easy-to-use category index pages with and without pagination. Supports non-URL-safe category keywords and has extensive documentation and test coverage.
- [Tweetsert](https://github.com/ibrado/jekyll-tweetsert): Imports tweets (Twitter statuses) as new posts. Features multiple timeline support, hashtag import, filtering, automatic category and/or tags, optional retweets and replies.
- [Stickyposts](https://github.com/ibrado/jekyll-stickyposts): Moves or copies (pins) posts marked `sticky: true` to the top of the list. Perfect for keeping important announcements on the home page, or giving collections a descriptive entry. Paginator friendly.
- [Jekyll::Paginate::Content](https://github.com/ibrado/jekyll-paginate-content): Content paginator in the style of jekyll-paginator-v2 that splits pages, posts, and collection entries into several pages. Specify a separator or use HTML <h1> etc. headers. Automatic splitting, single-page view, pager/trail, self-adjusting links, multipage TOC, SEO support.
- [Premonition](https://github.com/amedia/premonition): Adds block-styled side content to your page. For example summary, notes, hints or warning boxes.
- [jekyll-fontello](https://github.com/ericcornelissen/jekyll-fontello): A Jekyll plugin that automatically downloads your webfont from Fontello.
- [Target Blank](https://github.com/keithmifsud/jekyll-target-blank): A Jekyll plugin to automatically open external links in a new browser tab or window.
- [jekyll-info](https://github.com/swestmoreland/jekyll-info): A plugin to provide information about your Jekyll site’s configuration.
#### Converters
- [Pug plugin by Doug Beney](http://jekyll-pug.dougie.io): Use the popular Pug (previously Jade) templating language in Jekyll. Complete with caching, includes support, and much more.
- [Textile converter](https://github.com/jekyll/jekyll-textile-converter): Convert `.textile` files into HTML. Also includes the `textilize` Liquid filter.
- [Slim plugin](https://github.com/slim-template/jekyll-slim): Slim converter and includes for Jekyll with support for Liquid tags.
- [Markdown References by Olov Lassus](https://github.com/olov/jekyll-references): Keep all your markdown reference-style link definitions in one \_references.md file.
- [ReStructuredText Converter](https://github.com/xdissent/jekyll-rst): Converts ReST documents to HTML with Pygments syntax highlighting.
- [Jekyll-pandoc-multiple-formats](https://github.com/fauno/jekyll-pandoc-multiple-formats) by [edsl](https://github.com/edsl): Use pandoc to generate your site in multiple formats. Supports pandoc’s markdown extensions.
- [jekyll-commonmark](https://github.com/pathawks/jekyll-commonmark): Markdown converter that uses [libcmark](https://github.com/jgm/CommonMark), the reference parser for CommonMark.
#### Filters
- [Truncate HTML](https://github.com/MattHall/truncatehtml) by [Matt Hall](https://codebeef.com/): A Jekyll filter that truncates HTML while preserving markup structure.
- [Domain Name Filter by Lawrence Woodman](https://github.com/LawrenceWoodman/domain_name-liquid_filter): Filters the input text so that just the domain name is left.
- [Smilify](https://github.com/SaswatPadhi/jekyll_smilify) by [SaswatPadhi](https://github.com/SaswatPadhi): Convert text emoticons in your content to themeable smiley pics.
- [Jekyll-timeago](https://github.com/markets/jekyll-timeago): Converts a time value to the time ago in words.
- [pluralize](https://github.com/bdesham/pluralize): Easily combine a number and a word into a grammatically-correct amount like “1 minute” or “2 minute**s**”.
- [reading_time](https://github.com/bdesham/reading_time): Count words and estimate reading time for a piece of text, ignoring HTML elements that are unlikely to contain running text.
- [Table of Content Generator](https://github.com/dafi/jekyll-toc-generator): Generate the HTML code containing a table of content (TOC), the TOC can be customized in many way, for example you can decide which pages can be without TOC.
- [jekyll-toc](https://github.com/toshimaru/jekyll-toc): A liquid filter plugin for Jekyll which generates a table of contents.
- [jekyll-humanize](https://github.com/23maverick23/jekyll-humanize): This is a port of the Django app humanize which adds a "human touch" to data. Each method represents a Fluid type filter that can be used in your Jekyll site templates. Given that Jekyll produces static sites, some of the original methods do not make logical sense to port (e.g. naturaltime).
- [Jekyll-Ordinal](https://github.com/PatrickC8t/Jekyll-Ordinal): Jekyll liquid filter to output a date ordinal such as "st", "nd", "rd", or "th".
- [Deprecated articles keeper](https://github.com/kzykbys/JekyllPlugins) by [Kazuya Kobayashi](http://blog.kazuya.co/): A simple Jekyll filter which monitor how old an article is.
- [Jekyll-jalali](https://github.com/mehdisadeghi/jekyll-jalali) by [Mehdi Sadeghi](http://mehdix.ir): A simple Gregorian to Jalali date converter filter.
- [Jekyll Thumbnail Filter](https://github.com/matallo/jekyll-thumbnail-filter): Related posts thumbnail filter.
- [liquid-md5](https://github.com/pathawks/liquid-md5): Returns an MD5 hash. Helpful for generating Gravatars in templates.
- [jekyll-roman](https://github.com/paulrobertlloyd/jekyll-roman): A liquid filter for Jekyll that converts numbers into Roman numerals.
- [jekyll-typogrify](https://github.com/myles/jekyll-typogrify): A Jekyll plugin that brings the functions of [typogruby](http://avdgaag.github.io/typogruby/).
- [Jekyll Email Protect](https://github.com/vwochnik/jekyll-email-protect): Email protection liquid filter for Jekyll
- [Jekyll Uglify Filter](https://github.com/mattg/jekyll-uglify-filter): A Liquid filter that runs your JavaScript through UglifyJS.
- [match_regex](https://github.com/sparanoid/match_regex): A Liquid filter to perform regex match.
- [replace_regex](https://github.com/sparanoid/replace_regex): A Liquid filter to perform regex replace.
- [Jekyll Money](https://rubygems.org/gems/jekyll-money): A Jekyll plugin for dealing with money. Because we all have to at some point.
- [jekyll-random](https://github.com/codecalm/jekyll-random) by [codecalm](https://nodecalm.net): A Jekyll plugin that generates pseudo-random data. Very useful when you want to generate a large amount of random data.
- [jekyll-firstimage](https://github.com/nhoizey/jekyll-firstimage) adds a Liquid filter finding the first image in a HTML content string, including responsive images srcset.
#### Tags
You can find a few useful plugins at the following locations:
- [Jekyll-gist](https://github.com/jekyll/jekyll-gist): Use the `gist` tag to easily embed a GitHub Gist onto your site. This works with public or secret gists.
- [Asset Path Tag](https://github.com/samrayner/jekyll-asset-path-plugin) by [Sam Rayner](http://www.samrayner.com/): Allows organisation of assets into subdirectories by outputting a path for a given file relative to the current post or page.
- [Delicious Plugin by Christian Hellsten](https://github.com/christianhellsten/jekyll-plugins): Fetches and renders bookmarks from delicious.com.
- [Embed.ly client by Robert Böhnke](https://github.com/robb/jekyll-embedly-client): Autogenerate embeds from URLs using oEmbed.
- [FlickrSetTag by Thomas Mango](https://github.com/tsmango/jekyll_flickr_set_tag): Generates image galleries from Flickr sets.
- [Tweet Tag by Scott W. Bradley](https://github.com/scottwb/jekyll-tweet-tag): Liquid tag for [Embedded Tweets](https://dev.twitter.com/docs/embedded-tweets) using Twitter’s shortcodes.
- [Jekyll Twitter Plugin](https://github.com/rob-murray/jekyll-twitter-plugin): A Liquid tag plugin that renders Tweets from Twitter API. Currently supports the [oEmbed](https://dev.twitter.com/rest/reference/get/statuses/oembed) API.
- [Jekyll-contentblocks](https://github.com/rustygeldmacher/jekyll-contentblocks): Lets you use Rails-like content_for tags in your templates, for passing content from your posts up to your layouts.
- [Jekyll-beastiepress](https://github.com/okeeblow/jekyll-beastiepress): FreeBSD utility tags for Jekyll sites.
- [Bibjekyll](https://github.com/pablooliveira/bibjekyll): Render BibTeX-formatted bibliographies/citations included in posts and pages using bibtex2html.
- [Jekyll-citation](https://github.com/archome/jekyll-citation): Render BibTeX-formatted bibliographies/citations included in posts and pages (pure Ruby).
- [Jekyll Dribbble Set Tag](https://github.com/ericdfields/Jekyll-Dribbble-Set-Tag): Builds Dribbble image galleries from any user.
- [JekyllGalleryTag](https://github.com/redwallhp/JekyllGalleryTag) by [redwallhp](https://github.com/redwallhp): Generates thumbnails from a directory of images and displays them in a grid.
- [Jekyll-swfobject](https://github.com/sectore/jekyll-swfobject): Liquid plugin for embedding Adobe Flash files (.swf) using [SWFObject](https://github.com/swfobject/swfobject).
- [Jekyll Picture Tag](https://github.com/robwierzbowski/jekyll-picture-tag): Easy responsive images for Jekyll. Based on the proposed [`<picture>`](https://html.spec.whatwg.org/multipage/embedded-content.html#the-picture-element) element, polyfilled with Scott Jehl’s [Picturefill](https://github.com/scottjehl/picturefill).
- [Jekyll Image Tag](https://github.com/robwierzbowski/jekyll-image-tag): Better images for Jekyll. Save image presets, generate resized images, and add classes, alt text, and other attributes.
- [Ditaa Tag](https://github.com/matze/jekyll-ditaa) by [matze](https://github.com/matze): Renders ASCII diagram art into PNG images and inserts a figure tag.
- [Jekyll Suggested Tweet](https://github.com/davidensinger/jekyll-suggested-tweet) by [David Ensinger](https://github.com/davidensinger/): A Liquid tag for Jekyll that allows for the embedding of suggested tweets via Twitter’s Web Intents API.
- [Jekyll Date Chart](https://github.com/GSI/jekyll_date_chart) by [GSI](https://github.com/GSI): Block that renders date line charts based on textile-formatted tables.
- [Jekyll Image Encode](https://github.com/GSI/jekyll_image_encode) by [GSI](https://github.com/GSI): Tag that renders base64 codes of images fetched from the web.
- [Jekyll Quick Man](https://github.com/GSI/jekyll_quick_man) by [GSI](https://github.com/GSI): Tag that renders pretty links to man page sources on the internet.
- [Image Set/Gallery Tag](https://github.com/callmeed/jekyll-image-set) by [callmeed](https://github.com/callmeed): Renders HTML for an image gallery from a folder in your Jekyll site. Just pass it a folder name and class/tag options.
- [jekyll_figure](https://github.com/lmullen/jekyll_figure): Generate figures and captions with links to the figure in a variety of formats
- [Jekyll GitHub Sample Tag](https://github.com/bwillis/jekyll-github-sample): A liquid tag to include a sample of a github repo file in your Jekyll site.
- [Jekyll Project Version Tag](https://github.com/rob-murray/jekyll-version-plugin): A Liquid tag plugin that renders a version identifier for your Jekyll site sourced from the git repository containing your code.
- [Piwigo Gallery](https://github.com/AlessandroLorenzi/piwigo_gallery) by [Alessandro Lorenzi](http://blog.alorenzi.eu/): Jekyll plugin to generate thumbnails from a Piwigo gallery and display them with a Liquid tag
- [mathml.rb](https://github.com/tmthrgd/jekyll-plugins) by Tom Thorogood: A plugin to convert TeX mathematics into MathML for display.
- [webmention_io.rb](https://github.com/aarongustafson/jekyll-webmention_io) by [Aaron Gustafson](http://aaron-gustafson.com/): A plugin to enable [webmention](https://indieweb.org/webmention) integration using [Webmention.io](https://webmention.io/). Includes an optional JavaScript for updating webmentions automatically between publishes and, if available, in realtime using WebSockets.
- [Jekyll 500px Embed](https://github.com/lkorth/jekyll-500px-embed) by Luke Korth. A Liquid tag plugin that embeds [500px](https://500px.com/) photos.
- [inline\_highlight](https://github.com/bdesham/inline_highlight): A tag for inline syntax highlighting.
- [jekyll-mermaid](https://github.com/jasonbellamy/jekyll-mermaid): Simplify the creation of mermaid diagrams and flowcharts in your posts and pages.
- [twa](https://github.com/Ezmyrelda/twa): Twemoji Awesome plugin for Jekyll. Liquid tag allowing you to use twitter emoji in your jekyll pages.
- [Fetch remote file content](https://github.com/dimitri-koenig/jekyll-plugins) by [Dimitri König](https://www.dimitrikoenig.net/): Using `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.
- [jekyll-asciinema](https://github.com/mnuessler/jekyll-asciinema): A tag for embedding asciicasts recorded with [asciinema](https://asciinema.org) in your Jekyll pages.
- [Jekyll-Youtube](https://github.com/dommmel/jekyll-youtube) A Liquid tag that embeds Youtube videos. The default emded markup is responsive but you can also specify your own by using an include/partial.
- [Jekyll Flickr Plugin](https://github.com/lawmurray/indii-jekyll-flickr) by [Lawrence Murray](http://www.indii.org): Embeds Flickr photosets (albums) as a gallery of thumbnails, with lightbox links to larger images.
- [jekyll-figure](https://github.com/paulrobertlloyd/jekyll-figure): A liquid tag for Jekyll that generates `<figure>` elements.
- [Jekyll Video Embed](https://github.com/eug/jekyll-video-embed): It provides several tags to easily embed videos (e.g. Youtube, Vimeo, UStream and Ted Talks)
- [jekyll-i18n_tags](https://github.com/KrzysiekJ/jekyll-i18n_tags): Translate your templates.
- [Jekyll Ideal Image Slider](https://github.com/jekylltools/jekyll-ideal-image-slider): Liquid tag plugin to create image sliders using [Ideal Image Slider](https://github.com/gilbitron/Ideal-Image-Slider).
- [Jekyll Tags List Plugin](https://github.com/crispgm/jekyll-tags-list-plugin): A Liquid tag plugin that creates tags list in specific order.
- [Jekyll Maps](https://github.com/ayastreb/jekyll-maps) by [Anatoliy Yastreb](https://github.com/ayastreb): A Jekyll plugin to easily embed maps with filterable locations.
- [Jekyll Cloudinary](https://nhoizey.github.io/jekyll-cloudinary/) by [Nicolas Hoizey](https://nicolas-hoizey.com/): a Jekyll plugin adding a Liquid tag to ease the use of Cloudinary for responsive images in your Markdown/Kramdown posts.
- [jekyll-include-absolute-plugin](https://github.com/tnhu/jekyll-include-absolute-plugin) by [Tan Nhu](https://github.com/tnhu): A Jekyll plugin to include a file from its path relative to Jekyll's source folder.
- [Jekyll Download Tag](https://github.com/mattg/jekyll-download-tag): A Liquid tag that acts like `include`, but for external resources.
- [Jekyll Brand Social Wall](https://github.com/MediaComem/jekyll-brand-social-wall): A jekyll plugin to generate a social wall with your favorite social networks
- [Jekyll If File Exists](https://github.com/k-funk/jekyll-if-file-exists): A Jekyll Plugin that checks if a file exists with an if/else block.
plugin to generate publication lists from [BibSonomy](https://www.bibsonomy.org/).
- [github-cards](https://github.com/edward-shen/github-cards): Creates styleable Github cards for your Github projects.
- [disqus-for-jekyll](https://github.com/kacperduras/disqus-for-jekyll): A Jekyll plugin to view the comments powered by Disqus.
- [jekyll-html](https://github.com/kacperduras/jekyll-html): A Jekyll plugin to use HTML tags in Jekyll pages, posts and collections.
- [jekyll-onebox](https://github.com/rriemann/jekyll-onebox): Liquid tag for displaying HTML previews (embeds) for links to popular domains. Plugin is based on [Onebox](https://github.com/discourse/onebox) that powers link previews in [Discourse](http://github.com/discourse/discourse) forums.
- [jekyll-w2m](https://github.com/kacperduras/jekyll-w2m): A Jekyll plugin to liberate content from Microsoft Word documents (powered by [word-to-markdown](https://github.com/benbalter/word-to-markdown)).
- [jekyll-flickr](https://github.com/rriemann/jekyll-flickr): Liquid tag for responsive Flickr images using HTML5 srcset. Subtitles and automatic license notices are supported.
- [CAT](https://github.com/binfalse/jekyll-cat): Include the contents of any file (like the `include` command, but also for files outside of `_include`). Similar to Unix' `cat` tool; useful for including source code etc. in posts and pages.
#### Collections
- [Jekyll Plugins by Recursive Design](https://github.com/recurser/jekyll-plugins): Plugins to generate Project pages from GitHub readmes, a Category page, and a Sitemap generator.
- [Company website and blog plugins](https://github.com/flatterline/jekyll-plugins) by Flatterline, a Ruby on Rails development company: Portfolio/project page generator, team/individual page generator, an author bio liquid tag for use on posts, and a few other smaller plugins.
- [Jekyll plugins by Aucor](https://github.com/aucor/jekyll-plugins): Plugins for trimming unwanted newlines/whitespace and sorting pages by weight attribute.
#### Other
- [Analytics for Jekyll](https://github.com/hendrikschneider/jekyll-analytics) by Hendrik Schneider: An effortless way to add various trackers like Google Analytics, Matomo (formerly Piwik), mPulse, etc. to your site.
- [ditaa-ditaa](https://github.com/tmthrgd/ditaa-ditaa) by Tom Thorogood: a drastic revision of jekyll-ditaa that renders diagrams drawn using ASCII art into PNG images.
- [Pygments Cache Path by Raimonds Simanovskis](https://github.com/rsim/blog.rayapps.com/blob/master/_plugins/pygments_cache_patch.rb): Plugin to cache syntax-highlighted code from Pygments.
- [Related Posts by Lawrence Woodman](https://github.com/LawrenceWoodman/related_posts-jekyll_plugin): Overrides `site.related_posts` to use categories to assess relationship.
- [jekyll-tagging-related_posts](https://github.com/toshimaru/jekyll-tagging-related_posts): Jekyll related_posts function based on tags (works on Jekyll3).
- [Jekyll-localization](https://github.com/blackwinter/jekyll-localization): Jekyll plugin that adds localization features to the rendering engine.
- [Jekyll-rendering](https://github.com/blackwinter/jekyll-rendering): Jekyll plugin to provide alternative rendering engines.
- [Jekyll-pagination](https://github.com/blackwinter/jekyll-pagination): Jekyll plugin to extend the pagination generator.
- [Jekyll-tagging](https://github.com/pattex/jekyll-tagging): Jekyll plugin to automatically generate a tag cloud and tag pages.
- [Jekyll-scholar](https://github.com/inukshuk/jekyll-scholar): Jekyll extensions for the blogging scholar.
- [Jekyll-assets](http://jekyll.github.io/jekyll-assets/) by [ixti](https://github.com/ixti): Rails-alike assets pipeline (write assets in CoffeeScript, Sass, LESS etc; specify dependencies for automatic bundling using simple declarative comments in assets; minify and compress; use JST templates; cache bust; and many-many more).
- [JAPR](https://github.com/kitsched/japr): Jekyll Asset Pipeline Reborn - Powerful asset pipeline for Jekyll that collects, converts and compresses JavaScript and CSS assets.
- [Jekyll-minibundle](https://github.com/tkareine/jekyll-minibundle): Asset bundling and cache busting using external minification tool of your choice. No gem dependencies.
- [Singlepage-jekyll](https://github.com/JCB-K/singlepage-jekyll) by [JCB-K](https://github.com/JCB-K): Turns Jekyll into a dynamic one-page website.
- [generator-jekyllrb](https://github.com/robwierzbowski/generator-jekyllrb): A generator that wraps Jekyll in [Yeoman](http://yeoman.io/), a tool collection and workflow for building modern web apps.
- [grunt-jekyll](https://github.com/dannygarcia/grunt-jekyll): A straightforward [Grunt](http://gruntjs.com/) plugin for Jekyll.
- [jekyll-postfiles](https://github.com/indirect/jekyll-postfiles): Add `_postfiles` directory and {% raw %}`{{ postfile }}`{% endraw %} tag so the files a post refers to will always be right there inside your repo.
- [A layout that compresses HTML](http://jch.penibelst.de/): GitHub Pages compatible, configurable way to compress HTML files on site build.
- [Jekyll CO₂](https://github.com/wdenton/jekyll-co2): Generates HTML showing the monthly change in atmospheric CO₂ at the Mauna Loa observatory in Hawaii.
- [remote-include](http://www.northfieldx.co.uk/remote-include/): Includes files using remote URLs
- [jekyll-minifier](https://github.com/digitalsparky/jekyll-minifier): Minifies HTML, XML, CSS, and Javascript both inline and as separate files utilising yui-compressor and htmlcompressor.
- [Jekyll views router](https://bitbucket.org/nyufac/jekyll-views-router): Simple router between generator plugins and templates.
- [Jekyll Language Plugin](https://github.com/vwochnik/jekyll-language-plugin): Jekyll 3.0-compatible multi-language plugin for posts, pages and includes.
- [Jekyll Deploy](https://github.com/vwochnik/jekyll-deploy): Adds a `deploy` sub-command to Jekyll.
- [Official Contentful Jekyll Plugin](https://github.com/contentful/jekyll-contentful-data-import): Adds a `contentful` sub-command to Jekyll to import data from Contentful.
- [jekyll-paspagon](https://github.com/KrzysiekJ/jekyll-paspagon): Sell your posts in various formats for cryptocurrencies.
- [Hawkins](https://github.com/awood/hawkins): Adds a `liveserve` sub-command to Jekyll that incorporates [LiveReload](http://livereload.com/) into your pages while you preview them. No more hitting the refresh button in your browser!
- [Jekyll Autoprefixer](https://github.com/vwochnik/jekyll-autoprefixer): Autoprefixer integration for Jekyll
- [Jekyll-breadcrumbs](https://github.com/git-no/jekyll-breadcrumbs): Creates breadcrumbs for Jekyll 3.x, includes features like SEO optimization, optional breadcrumb item translation and more.
- [generator-jekyllized](https://github.com/sondr3/generator-jekyllized): A Yeoman generator for rapidly developing sites with Gulp. Live reload your site, automatically minify and optimize your assets and much more.
- [Jekyll-Spotify](https://github.com/MertcanGokgoz/Jekyll-Spotify): Easily output Spotify Embed Player for jekyll
- [jekyll-menus](https://github.com/forestryio/jekyll-menus): Hugo style menus for your Jekyll site... recursive menus included.
- [jekyll-data](https://github.com/ashmaroli/jekyll-data): Read data files within Jekyll Theme Gems.
- [jekyll-pinboard](https://github.com/snaptortoise/jekyll-pinboard-plugin): Access your Pinboard bookmarks within your Jekyll theme.
- [jekyll-migrate-permalink](https://github.com/mpchadwick/jekyll-migrate-permalink): Adds a `migrate-permalink` sub-command to help deal with side effects of changing your permalink.
- [Jekyll-Post](https://github.com/robcrocombe/jekyll-post): A CLI tool to easily draft, edit, and publish Jekyll posts.
- [jekyll-numbered-headings](https://github.com/muratayusuke/jekyll-numbered-headings): Adds ordered number to headings.
- [jekyll-pre-commit](https://github.com/mpchadwick/jekyll-pre-commit): A framework for running checks against your posts using a git pre-commit hook before you publish them.
- [jekyll-pwa-plugin](https://github.com/lavas-project/jekyll-pwa): A plugin provides PWA support for Jekyll. It generates a service worker in Jekyll build process and makes precache and runtime cache available in the runtime with Google Workbox.
- [jekyll-algolia](https://community.algolia.com/jekyll-algolia/): Add fast and relevant search to your Jekyll site through the Algolia API.
- [jekyll-get](https://github.com/18F/jekyll-get): Download data from external JSON API sources to use in generating a site.
- [jekyll-xml-source](https://github.com/mcred/jekyll-xml-source): Download XML and RSS from external sites for use in site data.
<div class="note info">
<h5>Submit your gem plugins</h5>
<p>
You're encouraged to add your Jekyll gem plugins to this list, <a href="../contributing/">read the contributing page</a> to find
... you can [get the PDF]({{ "/assets/mydoc.pdf" | absolute_url }}) directly.
```
{% endraw %}
<div class="info">
</div>
## A typical post
Jekyll can handle many different iterations of the idea you might associate with a "post," however a standard blog style post, including a Title, Layout, Publishing Date, and Categories might look like this:
```markdown
---
layout: post
title: "Welcome to Jekyll!"
date: 2015-11-17 16:16:01 -0600
categories: jekyll update
---
You’ll find this post in your `_posts` directory. Go ahead and edit it and re-build the site to see your changes. You can rebuild the site in many different ways, but the most common way is to run `bundle exec jekyll serve`, which launches a web server and auto-regenerates your site when a file is updated.
To add new posts, simply add a file in the `_posts` directory that follows the convention `YYYY-MM-DD-name-of-post.ext` and includes the necessary front matter. Take a look at the source for this post to get an idea about how it works.
```
Everything in between the first and second `---` are part of the YAML Front Matter, and everything after the second `---` will be rendered with Markdown and show up as "Content".
## Displaying an index of posts
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](../templates/)) is easy, thanks to the [Liquid template
language](https://docs.shopify.com/themes/liquid/basics) and its tags. Here’s a
basic example of how to create a list of links to your blog posts:
{% raw %}
```html
<ul>
{% for post in site.posts %}
<li>
<ahref="{{ post.url }}">{{ post.title }}</a>
</li>
{% endfor %}
</ul>
```
{% endraw %}
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](../templates/) 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.
## Displaying post categories or tags
Hey, that's pretty neat, but what about showing just some of your posts that are
related to each other? For that you can use any of the [variables definable in
Front Matter](https://jekyllrb.com/docs/frontmatter/). In the "typical post"
section you can see how to define categories. Simply add the categories to your
If you already have a full [Ruby](https://www.ruby-lang.org/en/downloads/) development environment with all headers and [RubyGems](https://rubygems.org/pages/download) installed (see Jekyll's [requirements](/docs/installation/#requirements)), you can create a new Jekyll site by doing the following:
```sh
# Install Jekyll and Bundler gems through RubyGems
gem install jekyll bundler
# Create a new Jekyll site at ./myblog
jekyll new myblog
# Change into your new directory
cd myblog
# Build the site on the preview server
bundle exec jekyll serve
# Now browse to http://localhost:4000
```
If you encounter any unexpected errors during the above, please refer to the [troubleshooting](/docs/troubleshooting/#configuration-problems) page or the already-mentioned [requirements](/docs/installation/#requirements) page, as you might be missing development headers or other prerequisites.
## About Bundler
`gem install bundler` installs the [bundler](https://rubygems.org/gems/bundler) gem through [RubyGems](https://rubygems.org/). You only need to install it once — not every time you create a new Jekyll project. Here are some additional details:
*`bundler` is a gem that manages other Ruby gems. It makes sure your gems and gem versions are compatible, and that you have all necessary dependencies each gem requires.
* The `Gemfile` and `Gemfile.lock` files inform Bundler about the gem requirements in your site. If your site doesn't have these Gemfiles, you can omit `bundle exec` and just run `jekyll serve`.
* When you run `bundle exec jekyll serve`, Bundler uses the gems and versions as specified in `Gemfile.lock` to ensure your Jekyll site builds with no compatibility or dependency conflicts.
For more information about how to use Bundler in your Jekyll project, this [tutorial](https://jekyllrb.com/tutorials/using-jekyll-with-bundler/) should provide answers to the most common questions and explain how to get up and running quickly.
## Options for creating a new site with Jekyll
`jekyll new <PATH>` installs a new Jekyll site at the path specified (relative to current directory). In this case, Jekyll will be installed in a directory called `myblog`. Here are some additional details:
* To install the Jekyll site into the directory you're currently in, run `jekyll new .` If the existing directory isn't empty, you can pass the `--force` option with `jekyll new . --force`.
*`jekyll new` automatically initiates `bundle install` to install the dependencies required. (If you don't want Bundler to install the gems, use `jekyll new myblog --skip-bundle`.)
* By default, the Jekyll site installed by `jekyll new` uses a gem-based theme called [Minima](https://github.com/jekyll/minima). With [gem-based themes](../themes), some of the directories and files are stored in the theme-gem, hidden from your immediate view.
* We recommend setting up Jekyll with a gem-based theme but if you want to start with a blank slate, use `jekyll new myblog --blank`
* To learn about other parameters you can include with `jekyll new`, type `jekyll new --help`.
When in doubt, use the <code>help</code> command to remind you of all available options and usage, it also works with the <code>new</code>, <code>build</code> and <code>serve</code> subcommands, e.g. <code>jekyll help new</code> or <code>jekyll help build</code>.
{: .note .info }
## Next steps
Building a Jekyll site with the default theme is just the first step. 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.
Jekyll's growing use is producing a wide variety of tutorials, frameworks, extensions, examples, and other resources that can be very helpful. Below is a collection of links to some of the most popular Jekyll resources.
## Editors
- [jekyll-atom](https://atom.io/packages/jekyll): A collection of snippets and tools for Jekyll in Atom
- [markdown-writer](https://atom.io/packages/markdown-writer): An Atom package for Jekyll. It can create new posts/drafts, manage tags/categories, insert link/images and add many useful key mappings.
- [sublime-jekyll](https://github.com/23maverick23/sublime-jekyll): A Sublime Text package for Jekyll static sites. This package should help creating Jekyll sites and posts easier by providing access to key template tags and filters, as well as common completions and a current date/datetime command (for dating posts). You can install this package manually via GitHub, or via [Package Control](https://packagecontrol.io/packages/Jekyll).
- [vim-jekyll](https://github.com/parkr/vim-jekyll): A vim plugin to generate new posts and run `jekyll build` all without leaving vim.
- [WordPress2Jekyll](https://wordpress.org/plugins/wp2jekyll/): A WordPress plugin that allows you to use WordPress as your editor and (automatically) export content in to Jekyll. WordPress2Jekyll attempts to marry these two systems together in order to make a site that can be easily managed from all devices.
## Useful Guides
- [CloudCannon Academy](https://learn.cloudcannon.com/) is a set of resources created by [CloudCannon](https://cloudcannon.com/) to help folks get up and running with Jekyll. They cover all skill levels, and even include some great video tutorials.
- [Jekyll Cheatsheet](https://learn.cloudcannon.com/jekyll-cheat-sheet/) is a single-page resource for Jekyll filters, variables, and the like.
- ["Creating and Hosting a Personal Site on GitHub"](http://jmcglone.com/guides/github-pages/)
- ['Build A Blog With Jekyll And GitHub Pages' on Smashing Magazine](https://www.smashingmagazine.com/2014/08/01/build-blog-jekyll-github-pages/)
- Publishing to GitHub Pages? [Check out our documentation page for just that purpose](/docs/github-pages/).
- [Blogging with Git, Emacs and Jekyll](https://metajack.im/2009/01/23/blogging-with-git-emacs-and-jekyll/)
- [Tips for working with GitHub Pages Integration](https://gist.github.com/jedschneider/2890453)
## Integrations
- Use a SaaS service as a backend for forms (contact forms, hiring forms, etc.)
- [Talkyard](https://www.talkyard.io/blog-comments): Embedded comments for Jekyll and others (free and open source, or hosted serverless)
- [Staticman](https://staticman.net): Add user-generated content to a Jekyll site (free and open source)
- [Snipcart](https://snipcart.com/blog/static-site-e-commerce-part-2-integrating-snipcart-with-jekyll): Add a shopping cart to a Jekyll site
- [Contentful](https://www.contentful.com/ecosystem/jekyll/): use Jekyll together with the API-driven Contentful CMS.
- [Algolia](https://blog.algolia.com/instant-search-blog-documentation-jekyll-plugin/): Add a powerful instant search to your Jekyll site
## Other commentary
- [How I'm using Jekyll in 2016](https://mademistakes.com/articles/using-jekyll-2016/)
- [Talkyard comments instructions for Jekyll](https://jekyll-demo.talkyard.io/2018/01/09/installation-instructions.html)
- [Static Comments with Jekyll & Staticman](https://mademistakes.com/articles/improving-jekyll-static-comments/)
- [Adding Ajax pagination to Jekyll](https://eduardoboucas.com/blog/2014/11/05/adding-ajax-pagination-to-jekyll.html)
- ['My Jekyll Fork', by Mike West](https://mikewest.org/2009/11/my-jekyll-fork)
> "Jekyll is a well-architected throwback to a time before WordPress, when men were men, and HTML was static. I like the ideas it espouses, and have made a few improvements to it's core. Here, I'll point out some highlights of my fork in the hopes that they see usage beyond this site."
- ['About this Website', by Carter Allen](http://cartera.me/2010/08/12/about-this-website/)
> "Jekyll is everything that I ever wanted in a blogging engine. Really. It isn't perfect, but what's excellent about it is that if there's something wrong, I know exactly how it works and how to fix it. It runs on the your machine only, and is essentially an added"build" step between you and the browser. I coded this entire site in TextMate using standard HTML5 and CSS3, and then at the end I added just a few little variables to the markup. Presto-chango, my site is built and I am at peace with the world."
- [Generating a Tag Cloud in Jekyll](http://www.justkez.com/generating-a-tag-cloud-in-jekyll/) – A guide to implementing a tag cloud and per-tag content pages using Jekyll.
- A way to [extend Jekyll](https://github.com/rfelix/jekyll_ext) without forking and modifying the Jekyll gem codebase and some [portable Jekyll extensions](https://wiki.github.com/rfelix/jekyll_ext/extensions) that can be reused and shared.
- [Using your Rails layouts in Jekyll](http://numbers.brighterplanet.com/2010/08/09/sharing-rails-views-with-jekyll)
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:
<div class="mobile-side-scroller">
<table>
<thead>
<tr>
<th>Variable</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr>
<td><p><code>file.path</code></p></td>
<td><p>
The relative path to the file, e.g. <code>/assets/img/image.jpg</code>
</p></td>
</tr>
<tr>
<td><p><code>file.modified_time</code></p></td>
<td><p>
The `Time` the file was last modified, e.g. <code>2016-04-01 16:35:26 +0200</code>
</p></td>
</tr>
<tr>
<td><p><code>file.name</code></p></td>
<td><p>
The string name of the file e.g. <code>image.jpg</code> for <code>image.jpg</code>
</p></td>
</tr>
<tr>
<td><p><code>file.basename</code></p></td>
<td><p>
The string basename of the file e.g. <code>image</code> for <code>image.jpg</code>
</p></td>
</tr>
<tr>
<td><p><code>file.extname</code></p></td>
<td><p>
The extension name for the file, e.g.
<code>.jpg</code> for <code>image.jpg</code>
</p></td>
</tr>
</tbody>
</table>
</div>
Note that in the above table, `file` can be anything. It's simply an arbitrarily set variable used in your own logic (such as in a for loop). It isn't a global site or page variable.
## Add front matter to static files
Although you can't directly add front matter values to static files, you can set front matter values through the [defaults property](../configuration/#front-matter-defaults) in your configuration file. When Jekyll builds the site, it will use the front matter values you set.
Here's an example:
In your `_config.yml` file, add the following values to the `defaults` property:
```yaml
defaults:
- scope:
path:"assets/img"
values:
image:true
```
This assumes that your Jekyll site has a folder path of `assets/img` where you have images (static files) stored. When Jekyll builds the site, it will treat each image as if it had the front matter value of `image: true`.
Suppose you want to list all your image assets as contained in `assets/img`. You could use this for loop to look in the `static_files` object and get all static files that have this front matter property:
└── index.html # can also be an 'index.md' with valid YAML Frontmatter
```
<div class="note info">
<h5>Directory structure of Jekyll sites using gem-based themes</h5>
<p>
Starting <strong>Jekyll 3.2</strong>, a new Jekyll project bootstrapped with <code>jekyll new</code> uses <a href="../themes/">gem-based themes</a> to define the look of the site. This results in a lighter default directory structure : <code>_layouts</code>, <code>_includes</code> and <code>_sass</code> are stored in the theme-gem, by default.
</p>
<br />
<p>
<a href="https://github.com/jekyll/minima">minima</a> is the current default theme, and <code>bundle show minima</code> will show you where minima theme's files are stored on your computer.
</p>
</div>
An overview of what each of these does:
@@ -54,11 +67,9 @@ An overview of what each of these does:
</td>
<td>
<p>
Stores <a href="../configuration/">configuration</a> 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.
</p>
</td>
</tr>
@@ -68,9 +79,9 @@ An overview of what each of these does:
</td>
<td>
<p>
Drafts are unpublished posts. The format of these files is without a date: <code>title.MARKUP</code>. Learn how to <a href="../drafts/">work with drafts</a>.
Drafts are unpublished posts. The format of these files is without a
date: <code>title.MARKUP</code>. Learn how to <a href="../drafts/">
work with drafts</a>.
</p>
</td>
</tr>
@@ -80,13 +91,11 @@ An overview of what each of these does:
</td>
<td>
<p>
These are the partials that can be mixed and matched by your layouts
and posts to facilitate reuse. The liquid tag
<code>{% raw %}{% include file.ext %}{% endraw %}</code>
can be used to include the partial in
<code>_includes/file.ext</code>.
</p>
</td>
</tr>
@@ -96,13 +105,12 @@ An overview of what each of these does:
</td>
<td>
<p>
These are the templates that wrap posts. Layouts are chosen on a post-
by-post basis in the <a href="../frontmatter/">YAML Front Matter</a>,
These are the templates that wrap posts. Layouts are chosen on a
post-by-post basis in the
<a href="../frontmatter/">YAML Front Matter</a>,
which is described in the next section. The liquid tag
<code>{% raw %}{{ content }}{% endraw %}</code>
is used to inject content into the web page.
</p>
</td>
</tr>
@@ -112,14 +120,12 @@ An overview of what each of these does:
</td>
<td>
<p>
Your dynamic content, so to speak. The naming convention of these files is
important, and must follow the format:
Your dynamic content, so to speak. The naming convention of these
files is important, and must follow the format:
<code>YEAR-MONTH-DAY-title.MARKUP</code>.
The <a href="../permalinks/">permalinks</a> can be customized for each
post, but the date and markup language are determined solely by the
file name.
The <a href="../permalinks/">permalinks</a> can be customized for
each post, but the date and markup language are determined solely by
the file name.
</p>
</td>
</tr>
@@ -129,12 +135,25 @@ An overview of what each of these does:
</td>
<td>
<p>
Well-formatted site data should be placed here. The jekyll engine will
autoload all yaml files (ends with <code>.yml</code> or <code>.yaml</code>)
in this directory. If there's a file <code>members.yml</code> under the directory,
then you can access contents of the file through <code>site.data.members</code>.
Well-formatted site data should be placed here. The Jekyll engine
will autoload all data files (using either the <code>.yml</code>,
<code>.yaml</code>, <code>.json</code> or <code>.csv</code>
formats and extensions) in this directory, and they will be
accessible via `site.data`. If there's a file
<code>members.yml</code> under the directory, then you can access
contents of the file through <code>site.data.members</code>.
</p>
</td>
</tr>
<tr>
<td>
<p><code>_sass</code></p>
</td>
<td>
<p>
These are sass partials that can be imported into your <code>main.scss</code>
which will then be processed into a single stylesheet
<code>main.css</code> that defines the styles to be used by your site.
</p>
</td>
</tr>
@@ -144,27 +163,38 @@ An overview of what each of these does:
</td>
<td>
<p>
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 <code>.gitignore</code> file.
</p>
</td>
</tr>
<tr>
<td>
<p><code>index.html</code> and other HTML, Markdown, Textile files</p>
<p><code>.jekyll-metadata</code></p>
</td>
<td>
<p>
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
<code>.gitignore</code> file.
</p>
</td>
</tr>
<tr>
<td>
<p><code>index.html</code> or <code>index.md</code> and other HTML,
Markdown files</p>
</td>
<td>
<p>
Provided that the file has a <a href="../frontmatter/">YAML Front
Matter</a> section, it will be transformed by Jekyll. The same will
happen for any <code>.html</code>, <code>.markdown</code>,
<code>.md</code>, or <code>.textile</code> file in your site’s root
directory or directories not listed above.
</p>
</td>
</tr>
@@ -174,14 +204,12 @@ An overview of what each of these does:
</td>
<td>
<p>
Every other directory and file except for those listed above—such as
<code>css</code> and <code>images</code> folders,
<code>favicon.ico</code> files, and so forth—will be copied verbatim
to the generated site. There are plenty of <a href="../sites/">sites
already using Jekyll</a> if you’re curious to see how they’re laid
* If you have a question about using Jekyll, start a discussion on [Jekyll Forum](https://talk.jekyllrb.com/) or [StackOverflow](https://stackoverflow.com/questions/tagged/jekyll)
* Chat with Jekyllers — Join [our Gitter channel](https://gitter.im/jekyll/jekyll) or [our IRC channel on Freenode](irc:irc.freenode.net/jekyll)
There are a bunch of helpful community members on these services that should be willing to point you in the right direction.
## Report a bug
* If you think you've found a bug within a Jekyll plugin, open an issue in that plugin's repository — First [look for the plugin on rubygems](https://rubygems.org/) then click on the `Homepage` link to access the plugin repository.
* If you think you've found a bug within Jekyll itself, [open an issue](https://github.com/jekyll/jekyll/issues/new).
Percent encodes any special characters in a URI. URI escape normally replaces a space with <code>%20</code>. <a href="https://en.wikipedia.org/wiki/Percent-encoding#Types_of_URI_characters">Reserved characters</a> will not be escaped.
<p>Convert an object into its String representation for debugging.</p>
</td>
<td class="align-center">
<p>
<code class="filter">{% raw %}{{ some_var | inspect }}{% endraw %}</code>
</p>
</td>
</tr>
</tbody>
</table>
</div>
### Options for the `slugify` filter
The `slugify` filter accepts an option, each specifying what to filter.
The default is `default`. They are as follows (with what they filter):
-`none`: no characters
-`raw`: spaces
-`default`: spaces and non-alphanumeric characters
-`pretty`: spaces and non-alphanumeric characters except for `._~!$&'()+,;=@`
-`ascii`: spaces, non-alphanumeric, and non-ASCII characters
-`latin`: like `default`, except Latin characters are first transliterated (e.g. `àèïòü` to `aeiou`) {%- include docs_version_badge.html version="3.7.0" -%}
* [Linking to pages, collections and posts (the new and improved way)](#links)
* [Linking to posts (the old way)](#linking-to-posts)
### Includes
If you have small page snippets that you want to include in multiple places on your site, save the snippets as *include files* and insert them where required, by using the `include` tag:
{% raw %}
```liquid
{% include footer.html %}
```
{% endraw %}
Jekyll expects all *include files* to be placed in an `_includes` directory at the root of your source directory. In the above example, this will embed the contents of `_includes/footer.html` into the calling file.
For more advanced information on using includes, see [Includes](../includes).
### Code snippet highlighting
Jekyll has built in support for syntax highlighting of over 60 languages
thanks to [Rouge](http://rouge.jneen.net). 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](http://pygments.org) 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](http://pygments.org/languages/)
To render a code block with syntax highlighting, surround your code as follows:
{% raw %}
```liquid
{% highlight ruby %}
def foo
puts 'foo'
end
{% endhighlight %}
```
{% endraw %}
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
or the [Pygments' Lexers page](http://pygments.org/docs/lexers/).
<div class="note info">
<h5>Jekyll processes all Liquid filters in code blocks</h5>
<p>If you are using a language that contains curly braces, you
will likely need to place <code>{% raw %}</code> and
<code>{% endraw %}</code> tags around your code.</p>
</div>
#### Line numbers
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:
{% raw %}
```liquid
{% highlight ruby linenos %}
def foo
puts 'foo'
end
{% endhighlight %}
```
{% endraw %}
#### Stylesheets for syntax highlighting
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](https://github.com/mojombo/tpw/tree/master/css/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.
## Links
### Linking to pages {#link}
To link to a post, a page, collection item, or file, the `link` tag will generate the correct permalink URL for the path you specify. For example, if you use the `link` tag to link to `mypage.html`, even if you change your permalink style to include the file extension or omit it, the URL formed by the `link` tag will always be valid.
You must include the file's original extension when using the `link` tag. Here are some examples:
{% raw %}
```liquid
{{ site.baseurl }}{% link _collection/name-of-document.md %}
{{ site.baseurl }}{% link _posts/2016-07-26-name-of-post.md %}
{{ site.baseurl }}{% link news/index.html %}
{{ site.baseurl }}{% link /assets/files/doc.pdf %}
```
{% endraw %}
You can also use the `link` tag to create a link in Markdown as follows:
{% raw %}
```liquid
[Link to a document]({{ site.baseurl }}{% link _collection/name-of-document.md %})
[Link to a post]({{ site.baseurl }}{% link _posts/2016-07-26-name-of-post.md %})
[Link to a page]({{ site.baseurl }}{% link news/index.html %})
[Link to a file]({{ site.baseurl }}{% link /assets/files/doc.pdf %})
```
{% endraw %}
(Including `{% raw %}{{ site.baseurl }}{% endraw %}` is optional — it depends on whether you want to preface the page URL with the `baseurl` value.)
The path to the post, page, or collection is defined as the path relative to the root directory (where your config file is) to the file, not the path from your existing page to the other page.
For example, suppose you're creating a link in `page_a.md` (stored in `pages/folder1/folder2`) to `page_b.md` (stored in `pages/folder1`). Your path in the link would not be `../page_b.html`. Instead, it would be `/pages/folder1/page_b.md`.
If you're unsure of the path, add `{% raw %}{{ page.path }}{% endraw %}` to the page and it will display the path.
One major benefit of using the `link` or `post_url` tag is link validation. If the link doesn't exist, Jekyll won't build your site. This is a good thing, as it will alert you to a broken link so you can fix it (rather than allowing you to build and deploy a site with broken links).
Note you cannot add filters to `link` tags. For example, you cannot append a string using Liquid filters, such as `{% raw %}{% link mypage.html | append: "#section1" %} {% endraw %}`. To link to sections on a page, you will need to use regular HTML or Markdown linking techniques.
### Linking to posts
If you want 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.
Jekyll has an extensive theme system that allows you to leverage community-maintained templates and styles to customize your site's presentation. Jekyll themes specify plugins and package up assets, layouts, includes, and stylesheets in a way that can be overridden by your site's content.
## Understanding gem-based themes
When you [create a new Jekyll site](/docs/quickstart) (by running the `jekyll new <PATH>` command), Jekyll installs a site that uses a gem-based theme called [Minima](https://github.com/jekyll/minima).
With gem-based themes, some of the site's directories (such as the `assets`, `_layouts`, `_includes`, and `_sass` directories) are stored in the theme's gem, hidden from your immediate view. Yet all of the necessary directories will be read and processed during Jekyll's build process.
In the case of Minima, you see only the following files in your Jekyll site directory:
```
├── Gemfile
├── Gemfile.lock
├── _config.yml
├── _posts
│ └── 2016-12-04-welcome-to-jekyll.markdown
├── about.markdown
└── index.markdown
```
The `Gemfile` and `Gemfile.lock` files are used by Bundler to keep track of the required gems and gem versions you need to build your Jekyll site.
Gem-based themes make it easy for theme developers to make updates available to anyone who has the theme gem. When there's an update, theme developers push the update to RubyGems.
If you have the theme gem, you can (if you desire) run `bundle update` to update all gems in your project. Or you can run `bundle update <THEME>`, replacing `<THEME>` with the theme name, such as `minima`, to just update the theme gem. Any new files or updates the theme developer has made (such as to stylesheets or includes) will be pulled into your project automatically.
The goal of gem-based themes is to allow you to get all the benefits of a robust, continually updated theme without having all the theme's files getting in your way and over-complicating what might be your primary focus: creating content.
## Overriding theme defaults
Jekyll themes set default layouts, includes, and stylesheets. However, you can override any of the theme defaults with your own site content.
To replace layouts or includes in your theme, make a copy in your `_layouts` or `_includes` directory of the specific file you wish to modify, or create the file from scratch giving it the same name as the file you wish to override.
For example, if your selected theme has a `page` layout, you can override the theme's layout by creating your own `page` layout in the `_layouts` directory (that is, `_layouts/page.html`).
To locate a theme's files on your computer:
1. Run `bundle show` followed by the name of the theme's gem, e.g., `bundle show minima` for Jekyll's default theme.
This returns the location of the gem-based theme files. For example, the Minima theme's files might be located in `/usr/local/lib/ruby/gems/2.3.0/gems/minima-2.1.0` on macOS.
2. Open the theme's directory in Finder or Explorer:
```sh
# On MacOS
open $(bundle show minima)
# On Windows
explorer /usr/local/lib/ruby/gems/2.3.0/gems/minima-2.1.0
# On Linux
xdg-open $(bundle show minima)
```
A Finder or Explorer window opens showing the theme's files and directories. The Minima theme gem contains these files:
```
├── LICENSE.txt
├── README.md
├── _includes
│ ├── disqus_comments.html
│ ├── footer.html
│ ├── google-analytics.html
│ ├── head.html
│ ├── header.html
│ ├── icon-github.html
│ ├── icon-github.svg
│ ├── icon-twitter.html
│ └── icon-twitter.svg
├── _layouts
│ ├── default.html
│ ├── home.html
│ ├── page.html
│ └── post.html
├── _sass
│ ├── minima
│ │ ├── _base.scss
│ │ ├── _layout.scss
│ │ └── _syntax-highlighting.scss
│ └── minima.scss
└── assets
└── main.scss
```
With a clear understanding of the theme's files, you can now override any theme file by creating a similarly named file in your Jekyll site directory.
Let's say, for a second example, you want to override Minima's footer. In your Jekyll site, create an `_includes` folder and add a file in it called `footer.html`. Jekyll will now use your site's `footer.html` file instead of the `footer.html` file from the Minima theme gem.
To modify any stylesheet you must take the extra step of also copying the main sass file (`_sass/minima.scss` in the Minima theme) into the `_sass` directory in your site's source.
Jekyll will look first to your site's content before looking to the theme's defaults for any requested file in the following folders:
- `/assets`
- `/_layouts`
- `/_includes`
- `/_sass`
Note that making copies of theme files will prevent you from receiving any theme updates on those files. An alternative, to continue getting theme updates on all stylesheets, is to use higher specificity CSS selectors in your own additional, originally named CSS files.
Refer to your selected theme's documentation and source repository for more information on what files you can override.
{: .note .info}
## Converting gem-based themes to regular themes
Suppose you want to get rid of the gem-based theme and convert it to a regular theme, where all files are present in your Jekyll site directory, with nothing stored in the theme gem.
To do this, copy the files from the theme gem's directory into your Jekyll site directory. (For example, copy them to `/myblog` if you created your Jekyll site at `/myblog`. See the previous section for details.)
Then you must tell Jekyll about the plugins that were referenced by the theme. You can find these plugins in the theme's gemspec file as runtime dependencies. If you were converting the Minima theme, for example, you might see:
You should include these references in the `Gemfile` in one of two ways.
You could list them individually in both `Gemfile` and `_config.yml`.
```ruby
# ./Gemfile
gem "jekyll-feed", "~> 0.9"
gem "jekyll-seo-tag", "~> 2.1"
```
```yaml
# ./_config.yml
plugins:
- jekyll-feed
- jekyll-seo-tag
```
Or you could list them explicitly as Jekyll plugins in your Gemfile, and not update `_config.yml`, like this:
```ruby
# ./Gemfile
group :jekyll_plugins do
gem "jekyll-feed", "~> 0.9"
gem "jekyll-seo-tag", "~> 2.1"
end
```
Either way, don't forget to `bundle update`.
However, if you're publishing on GitHub Pages you should update only your `_config.yml` as GitHub Pages doesn't load plugins via Bundler.
Finally, remove references to the theme gem in `Gemfile` and configuration. For example, to remove `minima`:
- Open `Gemfile` and remove `gem "minima", "~> 2.0"`.
- Open `_config.yml` and remove `theme: minima`.
Now `bundle update` will no longer get updates for the theme gem.
## Installing a gem-based theme {#installing-a-theme}
The `jekyll new <PATH>` command isn't the only way to create a new Jekyll site with a gem-based theme. You can also find gem-based themes online and incorporate them into your Jekyll project.
For example, search for [jekyll theme on RubyGems](https://rubygems.org/search?utf8=%E2%9C%93&query=jekyll-theme) to find other gem-based themes. (Note that not all themes are using `jekyll-theme` as a convention in the theme name.)
To install a gem-based theme:
1. Add the theme gem to your site's `Gemfile`:
```ruby
# ./Gemfile
# This is an example, declare the theme gem you want to use here
gem "jekyll-theme-minimal"
```
Or if you've started with the `jekyll new` command, replace `gem "minima", "~> 2.0"` with the gem you want, e.g:
```diff
# ./Gemfile
- gem "minima", "~> 2.0"
+ gem "jekyll-theme-minimal"
```
2. Install the theme:
```sh
bundle install
```
3. Add the following to your site's `_config.yml` to activate the theme:
```yaml
theme: jekyll-theme-minimal
```
4. Build your site:
```sh
bundle exec jekyll serve
```
You can have multiple themes listed in your site's `Gemfile`, but only one theme can be selected in your site's `_config.yml`.
{: .note .info }
If you're publishing your Jekyll site on [GitHub Pages](https://pages.github.com/), note that GitHub Pages supports only [some gem-based themes](https://pages.github.com/themes/). GitHub Pages also supports [using any theme hosted on GitHub](https://help.github.com/articles/adding-a-jekyll-theme-to-your-github-pages-site/#adding-a-jekyll-theme-in-your-sites-_configyml-file) using the `remote_theme` configuration as if it were a gem-based theme.
## Creating a gem-based theme
If you're a Jekyll theme developer (rather than just a consumer of themes), you can package up your theme in RubyGems and allow users to install it through Bundler.
If you're unfamiliar with creating Ruby gems, don't worry. Jekyll will help you scaffold a new theme with the `new-theme` command. Run `jekyll new-theme` with the theme name as an argument.
Your new Jekyll theme, jekyll-theme-awesome, is ready for you in /path/to/jekyll-theme-awesome!
For help getting started, read /path/to/jekyll-theme-awesome/README.md.
```
Add your template files in the corresponding folders. Then complete the `.gemspec` and the README files according to your needs.
### Layouts and includes
Theme layouts and includes work just like they work in any Jekyll site. Place layouts in your theme's `/_layouts` folder, and place includes in your themes `/_includes` folder.
For example, if your theme has a `/_layouts/page.html` file, and a page has `layout: page` in its YAML front matter, Jekyll will first look to the site's `_layouts` folder for the `page` layout, and if none exists, will use your theme's `page` layout.
### Assets
Any file in `/assets` will be copied over to the user's site upon build unless they have a file with the same relative path. You can ship any kind of asset here: SCSS, an image, a webfont, etc. These files behave like pages and static files in Jekyll:
- If the file has [YAML front matter](/docs/frontmatter/) at the top, it will be rendered.
- If the file does not have YAML front matter, it will simply be copied over into the resulting site.
This allows theme creators to ship a default `/assets/styles.scss` file which their layouts can depend on as `/assets/styles.css`.
All files in `/assets` will be output into the compiled site in the `/assets` folder just as you'd expect from using Jekyll on your sites.
### Stylesheets
Your theme's stylesheets should be placed in your theme's `_sass` folder, again, just as you would when authoring a Jekyll site.
```
_sass
├── jekyll-theme-awesome.scss
```
Your theme's styles can be included in the user's stylesheet using the `@import` directive.
{% raw %}
```css
@import "{{ site.theme }}";
```
{% endraw %}
### Theme-gem dependencies {%- include docs_version_badge.html version="3.5.0" -%}
Jekyll will automatically require all whitelisted `runtime_dependencies` of your theme-gem even if they're not explicitly included under the `plugins` array in the site's config file. (Note: whitelisting is only required when building or serving with the `--safe` option.)
With this, the end-user need not keep track of the plugins required to be included in their config file for their theme-gem to work as intended.
### Documenting your theme
Your theme should include a `/README.md` file, which explains how site authors can install and use your theme. What layouts are included? What includes? Do they need to add anything special to their site's configuration file?
### Adding a screenshot
Themes are visual. Show users what your theme looks like by including a screenshot as `/screenshot.png` within your theme's repository where it can be retrieved programmatically. You can also include this screenshot within your theme's documentation.
### Previewing your theme
To preview your theme as you're authoring it, it may be helpful to add dummy content in, for example, `/index.html` and `/page.html` files. This will allow you to use the `jekyll build` and `jekyll serve` commands to preview your theme, just as you'd preview a Jekyll site.
If you do preview your theme locally, be sure to add `/_site` to your theme's `.gitignore` file to prevent the compiled site from also being included when you distribute your theme.
{: .info .note}
### Publishing your theme
Themes are published via [RubyGems.org](https://rubygems.org). You will need a RubyGems account, which you can [create for free](https://rubygems.org/sign_up).
1. First, you need to have it in a git repository:
```sh
git init # Only the first time
git add -A
git commit -m "Init commit"
```
2. Next, package your theme, by running the following command, replacing `jekyll-theme-awesome` with the name of your theme:
```sh
gem build jekyll-theme-awesome.gemspec
```
3. Finally, push your packaged theme up to the RubyGems service, by running the following command, again replacing `jekyll-theme-awesome` with the name of your theme:
```sh
gem push jekyll-theme-awesome-*.gem
```
4. To release a new version of your theme, update the version number in the gemspec file, ( `jekyll-theme-awesome.gemspec` in this example ), and then repeat Steps 1 - 3 above. We recommend that you follow [Semantic Versioning](http://semver.org/) while bumping your theme-version.
If you encounter errors during gem installation, you may need to install
the header files for compiling extension modules for Ruby 2.x This
can be done on Ubuntu or Debian by running:
```sh
sudo apt-get install ruby2.3-dev
```
On Red Hat, CentOS, and Fedora systems you can do this by running:
```sh
sudo yum install ruby-devel
```
If you installed the above - specifically on Fedora 23 - but the extensions would still not compile, you are probably running a Fedora image that misses the `redhat-rpm-config` package. To solve this, simply run:
```sh
sudo dnf install redhat-rpm-config
```
On Arch Linux you need to run:
```sh
sudo pacman -S ruby-ffi
```
On Ubuntu if you get stuck after `bundle exec jekyll serve` and see error
messages like `Could not locate Gemfile` or `.bundle/ directory`, it's likely
because all requirements have not been fully met. Recent stock Ubuntu
distributions require the installation of both the `ruby` and `ruby-all-dev`
packages:
```sh
sudo apt-get install ruby ruby-all-dev
```
On [NearlyFreeSpeech](https://www.nearlyfreespeech.net/) you need to run the
If you elect to use one of the above methods to install Ruby, it might be
necessary to modify your `$PATH` variable using the following command:
```sh
exportPATH=/usr/local/bin:$PATH
```
GUI apps can modify the `$PATH` as follows:
```sh
launchctl setenv PATH "/usr/local/bin:$PATH"
```
Either of these approaches are useful because `/usr/local` is considered a
"safe" location on systems which have SIP enabled, they avoid potential
conflicts with the version of Ruby included by Apple, and it keeps Jekyll and
its dependencies in a sandboxed environment. This also has the added
benefit of not requiring `sudo` when you want to add or remove a gem.
### Could not find a JavaScript runtime. (ExecJS::RuntimeUnavailable)
This error can occur during the installation of `jekyll-coffeescript` when
you don't have a proper JavaScript runtime. To solve this, either install
`execjs` and `therubyracer` gems, or install `nodejs`. Check out
[issue #2327](https://github.com/jekyll/jekyll/issues/2327) for more info.
## Problems running Jekyll
On Debian or Ubuntu, you may need to add `/var/lib/gems/1.8/bin/` to your path
in order to have the `jekyll` executable be available in your Terminal.
## Base-URL Problems
If you are using base-url option like:
```sh
jekyll serve --baseurl '/blog'
```
… then make sure that you access the site at:
```
http://localhost:4000/blog/index.html
```
It won’t work to just access:
```
http://localhost:4000/blog
```
## Configuration problems
The order of precedence for conflicting [configuration settings](../configuration/)
is as follows:
1. Command-line flags
2. Configuration file settings
3. Defaults
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.
**Note: From v3.3.0 onward, Jekyll does not process `node_modules` and certain subdirectories within `vendor`, by default. But, by having an `exclude:` array defined explicitly in the config file overrides this default setting, which results in some users to encounter an error in building the site, with the following error message:**
```sh
ERROR: YOUR SITE COULD NOT BE BUILT:
------------------------------------
Invalid date '<%= Time.now.strftime('%Y-%m-%d %H:%M:%S %z') %>':
does not have a valid date in the YAML front matter.
```
Simply adding `vendor/bundle` to the `exclude:` list will solve this problem but will lead to having other sub-directories under `/vendor/` (and also `/node_modules/`, if present) be processed to the destination folder `_site`.
The proper solution is to incorporate the default setting for `exclude:` rather than override it completely:
For versions upto `v3.4.3`, the `exclude:` setting must look like following:
```yaml
exclude:
- Gemfile
- Gemfile.lock
- node_modules
- vendor/bundle/
- vendor/cache/
- vendor/gems/
- vendor/ruby/
- any_additional_item# any user-specific listing goes at the end
```
From `v3.5` onward, `Gemfile` and `Gemfile.lock` are also excluded by default. So, in most cases there is no need to define another `exclude:` array in the config file. So an existing definition can either be modified as above, or removed completely, or simply commented out to enable easy edits in future.
## Markup Problems
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.
### Liquid
Liquid version 2.0 seems to break the use of `{{ "{{" }}` in templates.
Unlike previous versions, using `{{ "{{" }}` in 2.0 triggers the following error:
```sh
'{{ "{{" }}' was not properly terminated with regexp: /\}\}/ (Liquid::SyntaxError)
```
### Excerpts
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.
## Production Problems
If you run into an issue that a static file can't be found in your
production environment during build since v3.2.0 you should set your
[environment to `production`](../configuration/#specifying-a-jekyll-environment-at-build-time).
The issue is caused by trying to copy a non-existing symlink.
<div class="note">
<h5>Please report issues you encounter!</h5>
<p>
If you come across a bug, please <a href="{{ site.repository }}/issues/new">create an issue</a>
on GitHub describing the problem and any work-arounds you find so we can
Upgrading from an older version of Jekyll? Upgrading to a new major version of
Jekyll (e.g. from v2.x to v3.x) may cause some headaches. Take the following
guides to aid your upgrade:
- [From 0.x to 1.x and 2.x](/docs/upgrading/0-to-2/)
- [From 2.x to 3.x](/docs/upgrading/2-to-3/)
## Minor updates
<div class="note">
<h5>Stay Up to Date</h5>
<p>We recommend you update Jekyll as often as possible to benefit from
the latest bug fixes.
</p>
</div>
If you followed our setup recommendations and installed [Bundler](http://bundler.io/), run `bundle update jekyll` or simply `bundle update` and all your gems will
update to the latest versions.
If you don't have Bundler installed, run `gem update jekyll`.
The procedure is similar [if you use the `github-pages`
This is a bit cumbersome at first, but is easier than a big `for` loop.
### Textile support
We dropped native support for Textile, from now on you have to install our [jekyll-textile-converter](https://github.com/jekyll/jekyll-textile-converter) plugin to work with Textile files.
### Dropped dependencies
We dropped a number of dependencies the Core Team felt were optional. As such, in 3.0, they must be explicitly installed and included if you use any of the features. They are:
- jekyll-paginate – Jekyll's pagination solution from days past
- jekyll-coffeescript – processing of CoffeeScript
- jekyll-gist – the `gist` Liquid tag
- pygments.rb – the Pygments highlighter
- redcarpet – the Markdown processor
- toml – an alternative to YAML for configuration files
- classifier-reborn – for `site.related_posts`
### Future posts
A seeming feature regression in 2.x, the `--future` flag was automatically _enabled_.
The future flag allows post authors to give the post a date in the future and to have
it excluded from the build until the system time is equal or after the post time.
In Jekyll 3, this has been corrected. **Now, `--future` is disabled by default.**
This means you will need to include `--future` if you want your future-dated posts to
generate when running `jekyll build` or `jekyll serve`.
<div class="note info">
<h5>Future Posts on GitHub Pages</h5>
<p>
An exception to the above rule are GitHub Pages sites, where the <code>--future</code> flag remains <em>enabled</em>
by default to maintain historical consistency for those sites.
</p>
</div>
### Layout metadata
Introducing: `layout`. In Jekyll 2 and below, any metadata in the layout was merged onto
the `page` variable in Liquid. This caused a lot of confusion in the way the data was
merged and some unexpected behaviour. In Jekyll 3, all layout data is accessible via `layout`
in Liquid. For example, if your layout has `class: my-layout` in its YAML front matter,
then the layout can access that via `{% raw %}{{ layout.class }}{% endraw %}`.
### Syntax highlighter changed
For the first time, the default syntax highlighter has changed for the
`highlight` tag and for backtick code blocks. Instead of [Pygments.rb](https://github.com/tmm1/pygments.rb),
it's now [Rouge](http://rouge.jneen.net/). If you were using the `highlight` tag with certain
options, such as `hl_lines`, they may not be available when using Rouge. To
go back to using Pygments, set `highlighter: pygments` in your
`_config.yml` file and run `gem install pygments.rb` or add
`gem 'pygments.rb'` to your project's `Gemfile`.
### Relative Permalink support removed
In Jekyll 3 and above, relative permalinks have been deprecated. If you
created your site using Jekyll 2 and below, you may receive the following
error when trying to **serve** or **build**:
```text
Since v3.0, permalinks for pages in subfolders must be relative to the site
source directory, not the parent directory. Check
https://jekyllrb.com/docs/upgrading/ for more info.
```
This can be fixed by removing the following line from your `_config.yml` file:
```yaml
relative_permalinks:true
```
### Permalinks no longer automatically add a trailing slash
In Jekyll 2, any URL constructed from the `permalink:` field had a trailing slash (`/`) added to it automatically. Jekyll 3 no longer adds a trailing slash automatically to `permalink:` URLs. This can potentially result in old links to pages returning a 404 error. For example, suppose a page previously contained the YAML `permalink: /:year-:month-:day-:title` that resulted in the URL `example.com/2016-02-01-test/` (notice the trailing slash), Jekyll internally generates a folder named `2016-02-01-test`. In Jekyll 3, the same `permalink:` generate the file `2016-02-01-test.html` and the URL for the same page will be `example.com/2016-02-01-test`, and consequently any links to the old URL will result in a 404 error. In order to maintain the same URLs and avoid this problem, a trailing slash should be added to the `permalink:` field, for example `permalink: /:year-:month-:day-:title/`.
### All my posts are gone! Where'd they go!
Try adding `future: true` to your `_config.yml` file. Are they showing up now? If they are, then you were ensnared by an issue with the way Ruby parses times. Each of your posts is being read in a different timezone than you might expect and, when compared to the computer's current time, is "in the future." The fix for this is to add [a timezone offset](https://en.wikipedia.org/wiki/List_of_UTC_time_offsets) to each post (and make sure you remove `future: true` from your `_config.yml` file). If you're writing from California, for example, you would change this:
```yaml
---
date:2016-02-06 19:32:10
---
```
to this (note the offset):
```yaml
---
date:2016-02-06 19:32:10 -0800
---
```
### My categories have stopped working!
If you organized your categories as `/_posts/code/2008-12-24-closures.md`, you will need to restructure your directories to put the categories _above_ the `_posts` directories, as follows: `/code/_posts/2008-12-24-closures.md`.
_Did we miss something? Please click "Improve this page" above and add a section. Thanks!_
For more about the possible configuration options, see the
[configuration](../configuration/) page.
<div class="note info">
<h5>Call for help</h5>
<p>
The <code>help</code> command is always here to remind you of all available options and usage, and also works with the <code>build</code>, <code>serve</code> and <code>new</code> subcommands, e.g <code>jekyll help new</code> or <code>jekyll help build</code>.
</p>
</div>
If you're interested in browsing these docs on-the-go, install the
`jekyll-docs` gem and run `jekyll docs` in your terminal.
@@ -42,6 +39,16 @@ following is a reference of the available data.
</p></td>
</tr>
<tr>
<td><p><code>layout</code></p></td>
<td><p>
Layout specific information + the <a href="../frontmatter/">YAML front
matter</a>. Custom variables set via the YAML Front Matter in
layouts will be available here.
</p></td>
</tr>
<tr>
<td><p><code>content</code></p></td>
<td><p>
@@ -105,10 +112,9 @@ following is a reference of the available data.
<td><p>
If the page being processed is a Post, this contains a list of up to ten
related Posts. By default, these are low quality but fast to compute.
related Posts. By default, these are the ten most recent posts.
For high quality but slow to compute results, run the
<code>jekyll</code> command with the <code>--lsi</code> (latent semantic
indexing) option.
<code>jekyll</code> command with the <code>--lsi</code> (<a href="https://en.wikipedia.org/wiki/Latent_semantic_analysis#Latent_semantic_indexing">latent semantic indexing</a>) option. Also note GitHub Pages does not support the <code>lsi</code> option when generating sites.
</p></td>
</tr>
@@ -116,9 +122,9 @@ following is a reference of the available data.
<td><p><code>site.static_files</code></p></td>
<td><p>
A list of all staticfiles (i.e. files not processed by Jekyll's
converters or the Liquid renderer). Each file has three properties:
<code>path</code>, <code>modified_time</code> and <code>extname</code>.
A list of all <a href="/docs/static-files/">static files</a> (i.e.
files not processed by Jekyll's converters or the Liquid renderer).
Each file has five properties: <code>path</code>, <code>modified_time</code>, <code>name</code>, <code>basename</code> and <code>extname</code>.
</p></td>
</tr>
@@ -126,7 +132,15 @@ following is a reference of the available data.
<td><p><code>site.html_pages</code></p></td>
<td><p>
A list of all HTML Pages.
A subset of `site.pages` listing those which end in `.html`.
</p></td>
</tr>
<tr>
<td><p><code>site.html_files</code></p></td>
<td><p>
A subset of `site.static_files` listing those which end in `.html`.
</p></td>
</tr>
@@ -170,17 +184,32 @@ following is a reference of the available data.
</p></td>
</tr>
<tr>
<td><p><code>site.url</code></p></td>
<td><p>
Contains the url of your site as it is configured in the <code>_config.yml</code>.
For example, if you have <code>url: http://mysite.com</code>
in your configuration file, then it will be accessible in Liquid as
<code>site.url</code>. For the development environment there is
While Windows is not an officially-supported platform, it can be used to run Jekyll with the proper tweaks. This page aims to collect some of the general knowledge and lessons that have been unearthed by Windows users.
## Installing Jekyll
The easiest way to run Jekyll is by using the [RubyInstaller][] for Windows.
### Installation via RubyInstaller
[RubyInstaller][] is a self-contained Windows-based installer that includes the Ruby language, an execution environment, important documentation, and more.
We only cover RubyInstaller-2.4 and newer here, older versions need to [install the Devkit][Devkit-install] manually.
1. Download and Install a **Ruby+Devkit** version from [RubyInstaller Downloads][RubyInstaller-downloads].
Use default options for installation.
2. Open a new command prompt window from the start menu, so that changes to the `PATH` environment variable becomes effective.
Install Jekyll and Bundler via: `gem install jekyll bundler`
3. Check if Jekyll installed properly: `jekyll -v`
That's it, you're ready to install our [default minimal blog theme](https://github.com/jekyll/minima) with `jekyll new jekyll-website`.
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 when you're running Jekyll on Windows.
Additionally, you might need to change the code page of the console window to UTF-8 in case you get a "Liquid Exception: Incompatible character encoding" error during the site generation process. It can be done with the following command:
```sh
chcp 65001
```
### Time-Zone Management
Since Windows doesn't have a native source of zoneinfo data, the Ruby Interpreter would not understand IANA Timezones and hence using them had the `TZ` environment variable default to UTC/GMT 00:00.
Though Windows users could alternatively define their blog's timezone by setting the key to use POSIX format of defining timezones, it wasn't as user-friendly when it came to having the clock altered to changing DST-rules.
Jekyll now uses a rubygem to internally configure Timezone based on established [IANA Timezone Database][IANA-database].
While 'new' blogs created with Jekyll v3.4 and greater, will have the following added to their 'Gemfile' by default, existing sites *will* have to update their 'Gemfile' (and installed) to enable development on Windows:
```ruby
# Windows does not include zoneinfo files, so bundle the tzinfo-data gem
Jekyll uses the `listen` gem to watch for changes when the `--watch` switch is specified during a build or serve. While `listen` has built-in support for UNIX systems, it may require an extra gem for compatibility with Windows.
Add the following to the Gemfile for your site if you have issues with auto-regeneration on Windows alone:
```ruby
gem'wdm','~> 0.1.1'ifGem.win_platform?
```
You have to use a [Ruby+Devkit](https://rubyinstaller.org/downloads/) version of the RubyInstaller.
## Installation via Bash on Windows 10
If you are using Windows 10 version 1607 or later, another option to run Jekyll is by [installing][WSL-Guide] the Windows Subsystem for Linux.
*Note:* You must have [Windows Subsystem for Linux][BASH-WSL] enabled.
First let's make sure all our packages / repositories are up to date. Open a new Command Prompt instance, and type the following:
```sh
bash
```
Your Command Prompt instance should now be a Bash instance. Now we must update our repo lists and packages.
```sh
sudo apt-get update -y && sudo apt-get upgrade -y
```
Now we can install Ruby. To do this we will use a repository from [BrightBox](https://www.brightbox.com/docs/ruby/ubuntu/), which hosts optimized versions of Ruby for Ubuntu.
Configure the bundler/gem path so bundle doesn't prompt for sudo
```sh
bundle config path vendor/bundle
```
**And that's it!**
To start a new project named `my_blog`, just run:
```sh
jekyll new my_blog
```
You can make sure time management is working properly by inspecting your `_posts` folder. You should see a markdown file with the current date in the filename.
<div class="note info">
<h5>Non-superuser account issues</h5>
<p>If the `jekyll new` command prints the error "Your user account isn't allowed to install to the system RubyGems", see the "Running Jekyll as Non-Superuser" instructions in <a href="/docs/troubleshooting/#no-sudo">Troubleshooting</a>.</p>
</div>
**Note:** Bash on Ubuntu on Windows is still under development, so you may run into issues.
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
