mirror of
https://github.com/jekyll/jekyll.git
synced 2026-04-28 03:01:03 -04:00
Compare commits
2 Commits
url-drop-o
...
roadmap
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
fb04d0db3b | ||
|
|
f9411bd362 |
@@ -1,33 +1,29 @@
|
||||
engines:
|
||||
fixme:
|
||||
enabled: false
|
||||
rubocop:
|
||||
enabled: true
|
||||
|
||||
rubocop: { enabled: true }
|
||||
fixme: { enabled: false }
|
||||
exclude_paths:
|
||||
- .codeclimate.yml
|
||||
- .gitignore
|
||||
- .rspec
|
||||
- .rubocop.yml
|
||||
- .travis.yml
|
||||
- .rubocop.yml
|
||||
- .codeclimate.yml
|
||||
- .travis.yml
|
||||
- .gitignore
|
||||
- .rspec
|
||||
|
||||
- Gemfile.lock
|
||||
- CHANGELOG.{md,markdown,txt,textile}
|
||||
- CONTRIBUTING.{md,markdown,txt,textile}
|
||||
- readme.{md,markdown,txt,textile}
|
||||
- README.{md,markdown,txt,textile}
|
||||
- Readme.{md,markdown,txt,textile}
|
||||
- ReadMe.{md,markdown,txt,textile}
|
||||
- COPYING
|
||||
- LICENSE
|
||||
|
||||
- features/**/*
|
||||
- script/**/*
|
||||
- docs/**/*
|
||||
- spec/**/*
|
||||
- test/**/*
|
||||
- vendor/**/*
|
||||
- Gemfile.lock
|
||||
- CHANGELOG.{md,markdown,txt,textile}
|
||||
- CONTRIBUTING.{md,markdown,txt,textile}
|
||||
- readme.{md,markdown,txt,textile}
|
||||
- README.{md,markdown,txt,textile}
|
||||
- Readme.{md,markdown,txt,textile}
|
||||
- ReadMe.{md,markdown,txt,textile}
|
||||
- COPYING
|
||||
- LICENSE
|
||||
|
||||
- site/**/*
|
||||
- test/**/*
|
||||
- vendor/**/*
|
||||
- features/**/*
|
||||
- script/**/*
|
||||
- spec/**/*
|
||||
ratings:
|
||||
paths:
|
||||
- lib/**/*.rb
|
||||
- lib/**/*.rb
|
||||
|
||||
@@ -1,14 +0,0 @@
|
||||
# editorconfig.org
|
||||
|
||||
root = true
|
||||
|
||||
[*]
|
||||
charset = utf-8
|
||||
end_of_line = lf
|
||||
indent_size = 2
|
||||
indent_style = space
|
||||
insert_final_newline = true
|
||||
trim_trailing_whitespace = true
|
||||
|
||||
[*.md]
|
||||
trim_trailing_whitespace = false
|
||||
32
.github/CONTRIBUTING.markdown
vendored
32
.github/CONTRIBUTING.markdown
vendored
@@ -28,7 +28,7 @@ Whether you're a developer, a designer, or just a Jekyll devotee, there are lots
|
||||
|
||||
* 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/).
|
||||
* Pull request 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.
|
||||
|
||||
@@ -49,7 +49,7 @@ That's it! You'll be automatically subscribed to receive updates as others revie
|
||||
### 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`.
|
||||
2. Clone the repository lcoally `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)
|
||||
@@ -62,33 +62,13 @@ We want the Jekyll documentation to be the best it can be. We've open-sourced ou
|
||||
|
||||
### 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.
|
||||
You can find the documentation for jekyllrb.com in the [site](https://github.com/jekyll/jekyll/tree/master/site) 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
|
||||
`<jekyll>/docs/_sass/_font-awesome.scss` sass partial.
|
||||
- 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.
|
||||
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](site/_docs/plugins.md) by adding a link to your plugin under the proper subheading depending upon its type.
|
||||
|
||||
## Code Contributions
|
||||
|
||||
@@ -100,7 +80,7 @@ Any time you propose a code change, you should also include updates to the docum
|
||||
|
||||
#### 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.
|
||||
If your contribution changes any Jekyll behavior, make sure to update the documentation. Documentation lives in the `site/_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
|
||||
|
||||
@@ -110,7 +90,7 @@ If your contribution changes any Jekyll behavior, make sure to update the docume
|
||||
|
||||
### 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.
|
||||
* Jekyll follows the [GitHub Ruby Styleguide](https://github.com/styleguide/ruby).
|
||||
|
||||
* Don't bump the Gem version in your pull request (if you don't know what that means, you probably didn't).
|
||||
|
||||
|
||||
75
.github/ISSUE_TEMPLATE.md
vendored
75
.github/ISSUE_TEMPLATE.md
vendored
@@ -1,83 +1,20 @@
|
||||
<!--
|
||||
Hi! Thanks for considering to file a bug with Jekyll. Please take the time to
|
||||
answer the basic questions. You can convert `[ ]` into `[x]` to check boxes (or submit
|
||||
and check.) If there is no need for certain fields like output and redirection, please delete
|
||||
those headers before submitting. We know not all tickets require those steps.
|
||||
Otherwise, please try to be as detailed as possible.
|
||||
###### What version of Jekyll are you using (`jekyll -v`)?
|
||||
|
||||
If you are unsure this is a bug in Jekyll, or this is a bug caused
|
||||
by a plugin that isn't directly related to Jekyll, or if this is just
|
||||
a generic usage question, please consider asking your question at
|
||||
https://talk.jekyllrb.com where non-bug questions go.
|
||||
|
||||
Please make sure to mention an affinity team whose responsibilities
|
||||
most closely align with your issue.
|
||||
|
||||
Thanks!
|
||||
-->
|
||||
###### What operating system are you using?
|
||||
|
||||
- [ ] I believe this to be a bug, not a question about using Jekyll.
|
||||
- [ ] I updated to the latest Jekyll (or) if on GitHub Pages to the latest `github-pages`
|
||||
- [ ] I ran `jekyll doctor` to check my configuration
|
||||
- [ ] I read the CONTRIBUTION file at https://jekyllrb.com/docs/contributing/
|
||||
- [ ] This is a feature request.
|
||||
|
||||
---
|
||||
|
||||
- [ ] I am on (or have tested on) ***macOS*** 10+
|
||||
- [ ] I am on (or have tested on) ***Debian/Ubuntu*** GNU/Linux
|
||||
- [ ] I am on (or have tested on) ***Fedora*** GNU/Linux
|
||||
- [ ] I am on (or have tested on) ***Arch*** GNU/Linux
|
||||
- [ ] I am on (or have tested on) ***Other*** GNU/Linux
|
||||
- [ ] I am on (or have tested on) ***Windows*** 10+
|
||||
###### What did you do?
|
||||
(Please include the content causing the issue, any relevant configuration settings, and the command you ran)
|
||||
|
||||
<!--
|
||||
Other GNU/Linux includes Scientific GNU/Linux, CentOS GNU/Linux, and others.
|
||||
If you are on a minor sub-distro (such as ElementaryOS which does not diverge from
|
||||
Ubuntu much, please check the parent distro. Kubuntu, Edubuntu, Lubuntu should
|
||||
also be flagged as Ubuntu as their packages come from upstream Ubuntu.
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
- [ ] I was trying to install.
|
||||
- [ ] There is a broken Plugin API.
|
||||
- [ ] I had an error on GitHub Pages, and I have reproduced it locally.
|
||||
- [ ] I had an error on GitHub Pages, and GitHub Support said it was a Jekyll Bug.
|
||||
- [ ] I had an error on GitHub Pages and I did not test it locally.
|
||||
- [ ] I was trying to build.
|
||||
- [ ] It was another bug.
|
||||
###### What did you expect to see?
|
||||
|
||||
## My Reproduction Steps
|
||||
|
||||
<!--
|
||||
If this error occured on GitHub Pages, please try to provide us with logs,
|
||||
and look at them yourself, to determine if this is an actual Jekyll bug. In
|
||||
the event you are unsure, file a ticket, however, when you do please provide
|
||||
the logs (strip them of personal information.)
|
||||
|
||||
If you have trouble finding your logs, please email support@github.com and
|
||||
they will happily help you. If you cannot find logs, please try your best to
|
||||
replicate it locally because we cannot fix a problem if we do not know
|
||||
exactly what caused it, or within a relatively close distance.
|
||||
-->
|
||||
###### What did you see instead?
|
||||
|
||||
<!--
|
||||
Insert the steps you took to for this problem to exist. Such as the
|
||||
directories you created and, the full command you ran, and include any
|
||||
plugins you have installed, this is very important.
|
||||
|
||||
If your steps are complicated, you can also submit a GitHub
|
||||
repository (please no zips, they will be removed and rejected by maintainers,)
|
||||
and just supply a command for us to reproduce it ourselves.
|
||||
-->
|
||||
|
||||
## The Output I Wanted
|
||||
|
||||
<!--
|
||||
Insert the output from the command. Alter it as little as you can.
|
||||
The minimum should be personal information. Though we normally don't log
|
||||
anything like that so there should be no need to alter it.
|
||||
-->
|
||||
|
||||
/cc include any Jekyll affinity teams here (see https://teams.jekyllrb.com/ for more info)
|
||||
|
||||
1
.gitignore
vendored
1
.gitignore
vendored
@@ -13,7 +13,6 @@
|
||||
/vendor
|
||||
Gemfile.lock
|
||||
_site/
|
||||
bin/
|
||||
bbin/
|
||||
coverage
|
||||
gh-pages/
|
||||
|
||||
225
.rubocop.yml
225
.rubocop.yml
@@ -1,153 +1,80 @@
|
||||
---
|
||||
Metrics/MethodLength: { Max: 24 }
|
||||
Metrics/ClassLength: { Max: 240 }
|
||||
Metrics/ModuleLength: { Max: 240 }
|
||||
Metrics/LineLength: { Max: 112 }
|
||||
Metrics/CyclomaticComplexity: { Max: 8 }
|
||||
Metrics/PerceivedComplexity: { Max: 8 }
|
||||
Metrics/ParameterLists: { Max: 4 }
|
||||
Metrics/MethodLength: { Max: 24 }
|
||||
Metrics/AbcSize: { Max: 20 }
|
||||
|
||||
Style/IndentHash: { EnforcedStyle: consistent }
|
||||
Style/HashSyntax: { EnforcedStyle: hash_rockets }
|
||||
Style/SignalException: { EnforcedStyle: only_raise }
|
||||
Style/AlignParameters: { EnforcedStyle: with_fixed_indentation }
|
||||
Style/StringLiteralsInInterpolation: { EnforcedStyle: double_quotes }
|
||||
Style/MultilineMethodCallIndentation: { EnforcedStyle: indented }
|
||||
Style/MultilineOperationIndentation: { EnforcedStyle: indented }
|
||||
Style/FirstParameterIndentation: { EnforcedStyle: consistent }
|
||||
Style/StringLiterals: { EnforcedStyle: double_quotes }
|
||||
Style/RegexpLiteral: { EnforcedStyle: slashes }
|
||||
Style/IndentArray: { EnforcedStyle: consistent }
|
||||
Style/ExtraSpacing: { AllowForAlignment: true }
|
||||
|
||||
Style/PercentLiteralDelimiters:
|
||||
PreferredDelimiters:
|
||||
'%q': '{}'
|
||||
'%Q': '{}'
|
||||
'%r': '!!'
|
||||
'%s': '()'
|
||||
'%w': '()'
|
||||
'%W': '()'
|
||||
'%x': '()'
|
||||
|
||||
Style/AlignArray: { Enabled: false }
|
||||
Style/StringLiterals: { Enabled: false }
|
||||
Style/Documentation: { Enabled: false }
|
||||
Style/DoubleNegation: { Enabled: false }
|
||||
Style/UnneededCapitalW: { Enabled: false }
|
||||
Style/EmptyLinesAroundModuleBody: { Enabled: false }
|
||||
Style/EmptyLinesAroundAccessModifier: { Enabled: false }
|
||||
Style/BracesAroundHashParameters: { Enabled: false }
|
||||
Style/SpaceInsideBrackets: { Enabled: false }
|
||||
Style/IfUnlessModifier: { Enabled: false }
|
||||
Style/ModuleFunction: { Enabled: false }
|
||||
Style/RescueModifier: { Enabled: false }
|
||||
Style/GuardClause: { Enabled: false }
|
||||
Style/FileName: { Enabled: false }
|
||||
Lint/UselessAccessModifier: { Enabled: false }
|
||||
Style/SpaceAroundOperators: { Enabled: false }
|
||||
Style/RedundantReturn: { Enabled: false }
|
||||
Style/SingleLineMethods: { Enabled: false }
|
||||
|
||||
AllCops:
|
||||
TargetRubyVersion: 2.0
|
||||
Include:
|
||||
- lib/**/*.rb
|
||||
- lib/**/*.rb
|
||||
|
||||
Exclude:
|
||||
- bin/**/*
|
||||
- exe/**/*
|
||||
- benchmark/**/*
|
||||
- script/**/*
|
||||
- vendor/**/*
|
||||
Layout/AlignArray:
|
||||
Enabled: false
|
||||
Layout/AlignHash:
|
||||
EnforcedHashRocketStyle: table
|
||||
Layout/AlignParameters:
|
||||
Enabled: false
|
||||
Layout/EmptyLinesAroundAccessModifier:
|
||||
Enabled: false
|
||||
Layout/EmptyLinesAroundModuleBody:
|
||||
Enabled: false
|
||||
Layout/EndOfLine:
|
||||
EnforcedStyle: lf
|
||||
Layout/ExtraSpacing:
|
||||
AllowForAlignment: true
|
||||
Layout/FirstParameterIndentation:
|
||||
EnforcedStyle: consistent
|
||||
Layout/IndentationWidth:
|
||||
Severity: error
|
||||
Layout/IndentArray:
|
||||
EnforcedStyle: consistent
|
||||
Layout/IndentHash:
|
||||
EnforcedStyle: consistent
|
||||
Layout/IndentHeredoc:
|
||||
Enabled: false
|
||||
Layout/MultilineMethodCallIndentation:
|
||||
EnforcedStyle: indented
|
||||
Layout/MultilineOperationIndentation:
|
||||
EnforcedStyle: indented
|
||||
Layout/SpaceAroundOperators:
|
||||
Enabled: true
|
||||
Layout/SpaceInsideBrackets:
|
||||
Enabled: false
|
||||
Lint/EndAlignment:
|
||||
Severity: error
|
||||
Lint/UnreachableCode:
|
||||
Severity: error
|
||||
Lint/UselessAccessModifier:
|
||||
Enabled: false
|
||||
Metrics/AbcSize:
|
||||
Max: 21
|
||||
Metrics/BlockLength:
|
||||
Exclude:
|
||||
- test/**/*.rb
|
||||
- lib/jekyll/configuration.rb
|
||||
- rake/*.rake
|
||||
- jekyll.gemspec
|
||||
Metrics/ClassLength:
|
||||
Exclude:
|
||||
- !ruby/regexp /features\/.*.rb$/
|
||||
- !ruby/regexp /test\/.*.rb$/
|
||||
Max: 300
|
||||
Metrics/CyclomaticComplexity:
|
||||
Max: 9
|
||||
Metrics/LineLength:
|
||||
Exclude:
|
||||
- !ruby/regexp /features\/.*.rb/
|
||||
- Rakefile
|
||||
- rake/*.rake
|
||||
- Gemfile
|
||||
- jekyll.gemspec
|
||||
Max: 90
|
||||
Severity: warning
|
||||
Metrics/MethodLength:
|
||||
CountComments: false
|
||||
Max: 20
|
||||
Severity: error
|
||||
Metrics/ModuleLength:
|
||||
Max: 240
|
||||
Metrics/ParameterLists:
|
||||
Max: 4
|
||||
Metrics/PerceivedComplexity:
|
||||
Max: 8
|
||||
Security/MarshalLoad:
|
||||
Exclude:
|
||||
- !ruby/regexp /test\/.*.rb$/
|
||||
- lib/jekyll/regenerator.rb
|
||||
Security/YAMLLoad:
|
||||
Exclude:
|
||||
- !ruby/regexp /features\/.*.rb/
|
||||
- !ruby/regexp /test\/.*.rb$/
|
||||
Style/Alias:
|
||||
Enabled: false
|
||||
Style/AndOr:
|
||||
Severity: error
|
||||
Style/Attr:
|
||||
Enabled: false
|
||||
Style/BracesAroundHashParameters:
|
||||
Enabled: false
|
||||
Style/ClassAndModuleChildren:
|
||||
Enabled: false
|
||||
Style/Documentation:
|
||||
Enabled: false
|
||||
Exclude:
|
||||
- !ruby/regexp /features\/.*.rb$/
|
||||
Style/DoubleNegation:
|
||||
Enabled: false
|
||||
Style/FileName:
|
||||
Enabled: false
|
||||
Style/GuardClause:
|
||||
Enabled: false
|
||||
Style/HashSyntax:
|
||||
EnforcedStyle: hash_rockets
|
||||
Severity: error
|
||||
Style/IfUnlessModifier:
|
||||
Enabled: false
|
||||
Style/InverseMethods:
|
||||
Enabled: false
|
||||
Style/ModuleFunction:
|
||||
Enabled: false
|
||||
Style/MultilineTernaryOperator:
|
||||
Severity: error
|
||||
Style/PercentLiteralDelimiters:
|
||||
PreferredDelimiters:
|
||||
"%q": "{}"
|
||||
"%Q": "{}"
|
||||
"%r": "!!"
|
||||
"%s": "()"
|
||||
"%w": "()"
|
||||
"%W": "()"
|
||||
"%x": "()"
|
||||
Style/RedundantReturn:
|
||||
Enabled: false
|
||||
Style/RedundantSelf:
|
||||
Enabled: false
|
||||
Style/RegexpLiteral:
|
||||
EnforcedStyle: percent_r
|
||||
Style/RescueModifier:
|
||||
Enabled: false
|
||||
Style/SignalException:
|
||||
EnforcedStyle: only_raise
|
||||
Style/SingleLineMethods:
|
||||
Enabled: false
|
||||
Style/StringLiterals:
|
||||
EnforcedStyle: double_quotes
|
||||
Style/StringLiteralsInInterpolation:
|
||||
EnforcedStyle: double_quotes
|
||||
Style/SymbolArray:
|
||||
Enabled: false
|
||||
Style/TrailingCommaInLiteral:
|
||||
EnforcedStyleForMultiline: consistent_comma
|
||||
Style/UnneededCapitalW:
|
||||
Enabled: false
|
||||
- .rubocop.yml
|
||||
- .codeclimate.yml
|
||||
- .travis.yml
|
||||
- .gitignore
|
||||
- .rspec
|
||||
|
||||
- Gemfile.lock
|
||||
- CHANGELOG.{md,markdown,txt,textile}
|
||||
- CONTRIBUTING.{md,markdown,txt,textile}
|
||||
- readme.{md,markdown,txt,textile}
|
||||
- README.{md,markdown,txt,textile}
|
||||
- Readme.{md,markdown,txt,textile}
|
||||
- ReadMe.{md,markdown,txt,textile}
|
||||
- COPYING
|
||||
- LICENSE
|
||||
|
||||
- site/**/*
|
||||
- test/**/*
|
||||
- vendor/**/*
|
||||
- features/**/*
|
||||
- script/**/*
|
||||
- spec/**/*
|
||||
|
||||
41
.travis.yml
41
.travis.yml
@@ -1,3 +1,4 @@
|
||||
before_script: bundle update
|
||||
bundler_args: --without benchmark:site:development
|
||||
script: script/cibuild
|
||||
cache: bundler
|
||||
@@ -5,35 +6,35 @@ language: ruby
|
||||
sudo: false
|
||||
|
||||
rvm:
|
||||
- &ruby1 2.4.1
|
||||
- &ruby2 2.3.4
|
||||
- &ruby3 2.2.7
|
||||
- &ruby4 2.1.10
|
||||
- &jruby jruby-9.1.7.0
|
||||
- &ruby1 2.3.0
|
||||
- &ruby2 2.2.4
|
||||
- &ruby3 2.1.8
|
||||
- &jruby jruby-9.0.4.0
|
||||
- &rhead ruby-head
|
||||
|
||||
matrix:
|
||||
include:
|
||||
- rvm: *ruby1
|
||||
env: TEST_SUITE=fmt
|
||||
- rvm: *ruby1
|
||||
env: TEST_SUITE=default-site
|
||||
- rvm: *ruby1
|
||||
env: ROUGE_VERSION=1.11.1 # runs everything with this version
|
||||
exclude:
|
||||
fast_finish: true
|
||||
allow_failures:
|
||||
- rvm: *jruby
|
||||
env: TEST_SUITE=cucumber
|
||||
|
||||
- rvm: *rhead
|
||||
env:
|
||||
matrix:
|
||||
- TEST_SUITE=test
|
||||
- TEST_SUITE=cucumber
|
||||
|
||||
branches:
|
||||
only:
|
||||
- master
|
||||
- themes
|
||||
- /*-stable/
|
||||
|
||||
notifications:
|
||||
irc:
|
||||
template: "%{repository}#%{build_number} (%{branch}) %{message} %{build_url}"
|
||||
channels: irc.freenode.org#jekyll
|
||||
|
||||
email:
|
||||
recipients:
|
||||
- jordon@envygeeks.io
|
||||
|
||||
slack:
|
||||
secure: "\
|
||||
dNdKk6nahNURIUbO3ULhA09/vTEQjK0fNbgjVjeYPEvROHgQBP1cIP3AJy8aWs8rl5Yyow4Y\
|
||||
@@ -49,9 +50,3 @@ addons:
|
||||
DA4vsRURfABU0fIhwYkQuZqEcA3d8TL36BZcGEshG6MQ2AmnYsmFiTcxqV5bmlElHEqQuT\
|
||||
5SUFXLafgZPBnL0qDwujQcHukID41sE=\
|
||||
"
|
||||
# regular test configuration
|
||||
after_success:
|
||||
- bundle exec codeclimate-test-reporter
|
||||
|
||||
before_install:
|
||||
- gem update --system
|
||||
|
||||
77
Gemfile
77
Gemfile
@@ -1,13 +1,10 @@
|
||||
source "https://rubygems.org"
|
||||
gemspec :name => "jekyll"
|
||||
|
||||
gem "rake", "~> 12.0"
|
||||
|
||||
# Dependency of jekyll-mentions. RubyGems in Ruby 2.1 doesn't shield us from this.
|
||||
gem "activesupport", "~> 4.2", :groups => [:test_legacy, :site] if RUBY_VERSION < "2.2.2"
|
||||
|
||||
gem "rake", "~> 11.0"
|
||||
group :development do
|
||||
gem "launchy", "~> 2.3"
|
||||
gem "rubocop", :branch => :master, :github => "bbatsov/rubocop"
|
||||
gem "pry"
|
||||
|
||||
unless RUBY_ENGINE == "jruby"
|
||||
@@ -18,86 +15,74 @@ end
|
||||
#
|
||||
|
||||
group :test do
|
||||
gem "codeclimate-test-reporter", "~> 1.0.5"
|
||||
gem "cucumber", "~> 2.1"
|
||||
gem "jekyll_test_plugin"
|
||||
gem "jekyll_test_plugin_malicious"
|
||||
# nokogiri v1.8 does not work with ruby 2.1 and below
|
||||
gem "nokogiri", RUBY_VERSION >= "2.2" ? "~> 1.7" : "~> 1.7.0"
|
||||
gem "rspec"
|
||||
gem "codeclimate-test-reporter"
|
||||
gem "rspec-mocks"
|
||||
gem "rubocop", "~> 0.49.1"
|
||||
gem "test-dependency-theme", :path => File.expand_path("test/fixtures/test-dependency-theme", __dir__)
|
||||
gem "test-theme", :path => File.expand_path("test/fixtures/test-theme", __dir__)
|
||||
|
||||
gem "jruby-openssl" if RUBY_ENGINE == "jruby"
|
||||
gem "nokogiri"
|
||||
gem "rspec"
|
||||
end
|
||||
|
||||
#
|
||||
|
||||
group :test_legacy do
|
||||
if RUBY_PLATFORM =~ %r!cygwin! || RUBY_VERSION.start_with?("2.2")
|
||||
gem "test-unit"
|
||||
if RUBY_PLATFORM =~ /cygwin/ || RUBY_VERSION.start_with?("2.2")
|
||||
gem 'test-unit'
|
||||
end
|
||||
|
||||
gem "minitest"
|
||||
gem "minitest-profile"
|
||||
gem "minitest-reporters"
|
||||
gem "redgreen"
|
||||
gem "shoulda"
|
||||
gem "simplecov"
|
||||
gem "minitest-reporters"
|
||||
gem "minitest-profile"
|
||||
gem "minitest"
|
||||
gem "shoulda"
|
||||
end
|
||||
|
||||
#
|
||||
|
||||
group :benchmark do
|
||||
if ENV["BENCHMARK"]
|
||||
gem "benchmark-ips"
|
||||
gem "benchmark-memory"
|
||||
gem "rbtrace"
|
||||
gem "ruby-prof"
|
||||
gem "benchmark-ips"
|
||||
gem "stackprof"
|
||||
gem "rbtrace"
|
||||
end
|
||||
end
|
||||
|
||||
#
|
||||
|
||||
group :jekyll_optional_dependencies do
|
||||
gem "coderay", "~> 1.1.0"
|
||||
gem "jekyll-coffeescript"
|
||||
gem "jekyll-docs", :path => "../docs" if Dir.exist?("../docs") && ENV["JEKYLL_VERSION"]
|
||||
gem "jekyll-feed", "~> 0.9"
|
||||
gem "jekyll-gist"
|
||||
gem "jekyll-paginate"
|
||||
gem "jekyll-redirect-from"
|
||||
gem "kramdown", "~> 1.9"
|
||||
gem "mime-types", "~> 3.0"
|
||||
gem "rdoc", "~> 5.0"
|
||||
gem "toml", "~> 0.1.0"
|
||||
gem "coderay", "~> 1.1.0"
|
||||
gem "jekyll-docs", :path => '../docs' if Dir.exist?('../docs') && ENV['JEKYLL_VERSION']
|
||||
gem "jekyll-gist", "~> 1.0"
|
||||
gem "jekyll-feed", "~> 0.1.3"
|
||||
gem "jekyll-coffeescript", "~> 1.0"
|
||||
gem "jekyll-redirect-from", "~> 0.9.1"
|
||||
gem "jekyll-paginate", "~> 1.0"
|
||||
gem "mime-types", "~> 3.0"
|
||||
gem "kramdown", "~> 1.9"
|
||||
gem "rdoc", "~> 4.2"
|
||||
|
||||
platform :ruby, :mswin, :mingw, :x64_mingw do
|
||||
gem "classifier-reborn", "~> 2.1.0"
|
||||
gem "liquid-c", "~> 3.0"
|
||||
gem "pygments.rb", "~> 0.6.0"
|
||||
platform :ruby, :mswin, :mingw do
|
||||
gem "rdiscount", "~> 2.0"
|
||||
gem "pygments.rb", "~> 0.6.0"
|
||||
gem "redcarpet", "~> 3.2", ">= 3.2.3"
|
||||
gem "yajl-ruby", "~> 1.2"
|
||||
gem "classifier-reborn", "~> 2.0"
|
||||
gem "liquid-c", "~> 3.0"
|
||||
end
|
||||
|
||||
# Windows does not include zoneinfo files, so bundle the tzinfo-data gem
|
||||
gem "tzinfo-data", :platforms => [:mingw, :mswin, :x64_mingw, :jruby]
|
||||
end
|
||||
|
||||
#
|
||||
|
||||
group :site do
|
||||
if ENV["PROOF"]
|
||||
gem "html-proofer", "~> 3.4"
|
||||
gem "html-proofer", "~> 2.0"
|
||||
end
|
||||
|
||||
gem "jekyll-avatar"
|
||||
gem "jekyll-mentions"
|
||||
gem "jekyll-seo-tag"
|
||||
gem "jemoji", "0.5.1"
|
||||
gem "jekyll-sitemap"
|
||||
gem "jemoji"
|
||||
gem "jekyll-seo-tag", "~> 1.1"
|
||||
gem "jekyll-avatar"
|
||||
end
|
||||
|
||||
699
History.markdown
699
History.markdown
@@ -1,583 +1,35 @@
|
||||
## HEAD
|
||||
|
||||
### Development Fixes
|
||||
|
||||
* Strip unnecessary leading whitespace in template (#6228)
|
||||
* Users should be installing patch versions. (#6198)
|
||||
* fix tests (#6240)
|
||||
* Define path with __dir__ (#6087)
|
||||
* exit site.process sooner (#6239)
|
||||
|
||||
### Minor Enhancements
|
||||
|
||||
* Ignore final newline in folded YAML string (#6054)
|
||||
* Add URL checks to Doctor (#5760)
|
||||
* Fix serving files that clash with directories (#6222) (#6231)
|
||||
* Bump supported Ruby version to `>= 2.1.0` (#6220)
|
||||
|
||||
### Bug Fixes
|
||||
|
||||
* `Deprecator`: fix typo for `--serve` command (#6229)
|
||||
* `Reader#read_directories`: guard against an entry not being a directory (#6226)
|
||||
* kramdown: symbolize keys in-place (#6247)
|
||||
* Call to_s on site.url before attempting to concatenate strings (#6253)
|
||||
|
||||
### Documentation
|
||||
|
||||
* Fix a typo in `custom-404-page.md` (#6218)
|
||||
* Docs: fix links to issues in History.markdown (#6255)
|
||||
|
||||
### Site Enhancements
|
||||
|
||||
* Adding DevKit helpers (#6225)
|
||||
|
||||
## 3.5.1 / 2017-07-17
|
||||
|
||||
### Minor Enhancements
|
||||
|
||||
* Use Warn for deprecation messages (#6192)
|
||||
* site template: Use plugins key instead of gems (#6045)
|
||||
|
||||
### Bug Fixes
|
||||
|
||||
* Backward compatiblize URLFilters module (#6163)
|
||||
* Static files contain front matter default keys when `to_liquid`'d (#6162)
|
||||
* Always normalize the result of the `relative_url` filter (#6185)
|
||||
|
||||
### Documentation
|
||||
|
||||
* Update reference to trouble with OS X/macOS (#6139)
|
||||
* added BibSonomy plugin (#6143)
|
||||
* add plugins for multiple page pagination (#6055)
|
||||
* Update minimum Ruby version in installation.md (#6164)
|
||||
* [docs] Add information about finding a collection in `site.collections` (#6165)
|
||||
* Add `{% raw %}` to Liquid example on site (#6179)
|
||||
* Added improved Pug plugin - removed 404 Jade plugin (#6174)
|
||||
* Linking the link (#6210)
|
||||
* Small correction in documentation for includes (#6193)
|
||||
* Fix docs site page margin (#6214)
|
||||
|
||||
### Development Fixes
|
||||
|
||||
* Add jekyll doctor to GitHub Issue Template (#6169)
|
||||
* Test with Ruby 2.4.1-1 on AppVeyor (#6176)
|
||||
* set minimum requirement for jekyll-feed (#6184)
|
||||
|
||||
## 3.5.0 / 2017-06-18
|
||||
|
||||
### Minor Enhancements
|
||||
|
||||
* Upgrade to Liquid v4 (#4362)
|
||||
* Convert StaticFile liquid representation to a Drop & add front matter defaults support to StaticFiles (#5871)
|
||||
* Add support for Tab-Separated Values data files (`*.tsv`) (#5985)
|
||||
* Specify version constraint in subcommand error message. (#5974)
|
||||
* Add a template for custom 404 page (#5945)
|
||||
* Require `runtime_dependencies` of a Gem-based theme from its `.gemspec` file (#5914)
|
||||
* Don't raise an error if URL contains a colon (#5889)
|
||||
* Date filters should never raise an exception (#5722)
|
||||
* add `plugins` config key as replacement for `gems` (#5130)
|
||||
* create configuration from options only once in the boot process (#5487)
|
||||
* Add option to fail a build with front matter syntax errors (#5832)
|
||||
* Disable default layouts for documents with a `layout: none` declaration (#5933)
|
||||
* In `jekyll new`, make copied site template user-writable (#6072)
|
||||
* Add top-level `layout` liquid variable to Documents (#6073)
|
||||
* Address reading non-binary static files in themes (#5918)
|
||||
* Allow filters to sort & select based on subvalues (#5622)
|
||||
* Add strip_index filter (#6075)
|
||||
|
||||
### Documentation
|
||||
|
||||
* Install troubleshooting on Ubuntu (#5817)
|
||||
* Add Termux section on troubleshooting (#5837)
|
||||
* fix ial css classes in theme doc (#5876)
|
||||
* Update installation.md (#5880)
|
||||
* Update Aerobatic docs (#5883)
|
||||
* Add note to collections doc on hard-coded collections. (#5882)
|
||||
* Makes uri_escape template docs more specific. (#5887)
|
||||
* Remove duplicate footnote_nr from default config (#5891)
|
||||
* Fixed tutorial for publishing gem to include repo. (#5900)
|
||||
* update broken links (#5905)
|
||||
* Fix typo in contribution information (#5910)
|
||||
* update plugin repo URL to reflect repo move (#5916)
|
||||
* Update exclude array in configuration.md (#5947)
|
||||
* Fixed path in "Improve this page" link in Tutorials section (#5951)
|
||||
* Corrected permalink (#5949)
|
||||
* Included more details about adding defaults to static files (#5971)
|
||||
* Create buddyworks (#5962)
|
||||
* added (buddyworks) to ci list (#5965)
|
||||
* Add a tutorial on serving custom Error 404 page (#5946)
|
||||
* add custom 404 to tutorial navigation (#5978)
|
||||
* Add link to order of interpretation tutorial in Tutorials nav (#5952)
|
||||
* Document Jekyll's Philosophy (#5792)
|
||||
* Require Ruby > 2.1.0 (#5983)
|
||||
* Fix broken link (#5994)
|
||||
* Default options for script/proof (#5995)
|
||||
* Mention Bash on Ubuntu on Windows (#5960)
|
||||
* Document `--unpublished` flag introduced in 91e9ecf (#5959)
|
||||
* Update upgrading.md to mention usage of `bundle update` (#5604)
|
||||
* Fix missing quotation mark (#6002)
|
||||
* New tutorial: Convert an HTML site to Jekyll (#5881)
|
||||
* Revamp Permalink section (#5912)
|
||||
* Fixup tutorial on creating theme from existing HTML templates (#6006)
|
||||
* Standardise on "URLs" without apostrophe in docs (#6018)
|
||||
* Added txtpen in tutorial (#6021)
|
||||
* fix typo using past participle (#6026)
|
||||
* changed formatting to fit the style of the documentation (#6027)
|
||||
* doc fix typo word usage (#6028)
|
||||
* corrected reference to layout in index.md (#6032)
|
||||
* (Minor) Update MathJax CDN (#6013)
|
||||
* Add MvvmCross to samples (#6035)
|
||||
* Update travis-ci.md to correct procedure (#6043)
|
||||
* fix sentence in documentation (#6048)
|
||||
* rephrase a sentence in posts.md to be more direct (#6049)
|
||||
* Compress Website Sass output (#6009)
|
||||
* doc correct spelling error (#6050)
|
||||
* adjusted date-format in sitemap (#6053)
|
||||
* Typo fix (welcomed change -> welcome change). (#6070)
|
||||
* Fixed documentation inconsistency (#6068)
|
||||
* Add own plugin -> Jekyll Brand Social Wall (#6064)
|
||||
* Added plugin jekyll-analytics (#6042)
|
||||
* Use more precise language when explaining links (#6078)
|
||||
* Update plugins.md (#6088)
|
||||
* windows 10 tutorial (#6100)
|
||||
* Explain how to override theme styles (#6107)
|
||||
* updated Bash on Ubuntu on Windows link in tutorial (#6111)
|
||||
* Fix wording in `_docs/templates.md` links section (#6114)
|
||||
* Update windows.md (#6115)
|
||||
* Added windows to docs.yml (#6109)
|
||||
* Be more specific on what to upload (#6119)
|
||||
* Remove Blank Newlines from "Jekyll on Windows" Page (#6126)
|
||||
* Link the troubleshooting page in the quickstart page (#6134)
|
||||
* add documentation about the "pinned" label (#6147)
|
||||
* docs(JekyllOnWindows): Add a new Installation way (#6141)
|
||||
* corrected windows.md (#6149)
|
||||
* Refine documentation for Windows (#6153)
|
||||
|
||||
### Development Fixes
|
||||
|
||||
* [Rubocop] add missing comma (#5835)
|
||||
* Appease classifier-reborn (#5934)
|
||||
* Allow releases & development on `*-stable` branches (#5926)
|
||||
* Add script/backport-pr (#5925)
|
||||
* Prefer .yaml over .toml (#5966)
|
||||
* Fix Appveyor with DST-aware cucumber steps (#5961)
|
||||
* Use Rubocop v0.47.1 till we're ready for v0.48 (#5989)
|
||||
* Test against Ruby 2.4.0 (#5687)
|
||||
* rubocop: lib/jekyll/renderer.rb complexity fixes (#5052)
|
||||
* Use yajl-ruby 1.2.2 (now with 2.4 support) (#6007)
|
||||
* Bump Rubocop to v0.48 (#5997)
|
||||
* doc use example.com (#6031)
|
||||
* fix typo (#6040)
|
||||
* Fix CI (#6044)
|
||||
* Remove `ruby RUBY_VERSION` from generated Gemfile (#5803)
|
||||
* Test if hidden collections output a document with a future date (#6103)
|
||||
* Add test for uri_escape on reserved characters (#6086)
|
||||
* Allow you to specify the rouge version via an environment variable for testing (#6138)
|
||||
* Bump Rubocop to 0.49.1 (#6093)
|
||||
* Lock nokogiri to 1.7.x for Ruby 2.1 (#6140)
|
||||
|
||||
### Site Enhancements
|
||||
|
||||
* Corrected date for version 3.4.0 (#5842)
|
||||
* Add the correct year to the 3.4.0 release date (#5858)
|
||||
* Add documentation about order of interpretation (#5834)
|
||||
* Documentation on how to build navigation (#5698)
|
||||
* Navigation has been moved out from docs (#5927)
|
||||
* Make links in sidebar for current page more prominent (#5820)
|
||||
* Update normalize.css to v6.0.0 (#6008)
|
||||
* Docs: rename `gems` to `plugins` (#6082)
|
||||
* plugins -> gems (#6110)
|
||||
* Document difference between cgi_escape and uri_escape #5970 (#6081)
|
||||
|
||||
### Bug Fixes
|
||||
|
||||
* Exclude Gemfile by default (#5860)
|
||||
* Convertible#validate_permalink!: ensure the return value of data["permalink"] is a string before asking if it is empty (#5878)
|
||||
* Allow abbreviated post dates (#5920)
|
||||
* Remove dependency on include from default about.md (#5903)
|
||||
* Allow colons in `uri_escape` filter (#5957)
|
||||
* Re-surface missing public methods in `Jekyll::Document` (#5975)
|
||||
* absolute_url should not mangle URL if called more than once (#5789)
|
||||
* patch URLFilters to prevent `//` (#6058)
|
||||
* add test to ensure variables work in `where_exp` condition (#5315)
|
||||
* Read explicitly included dot-files in collections. (#6092)
|
||||
* Default `baseurl` to `nil` instead of empty string (#6137)
|
||||
* Filters#time helper: Duplicate time before calling #localtime. (#5996)
|
||||
|
||||
## 3.4.5 / 2017-06-30
|
||||
|
||||
* Backport #6185 for v3.4.x: Always normalize the result of the `relative_url` filter (#6186)
|
||||
|
||||
## 3.4.4 / 2017-06-17
|
||||
|
||||
* Backport #6137 for v3.4.x: Default `baseurl` to `nil` instead of empty string (#6146)
|
||||
|
||||
## 3.4.3 / 2017-03-21
|
||||
|
||||
* Backport #5957 for v3.4.x: Allow colons in `uri_escape` filter (#5968)
|
||||
|
||||
## 3.4.2 / 2017-03-09
|
||||
|
||||
* Backport #5871 for v3.4.x: Convert StaticFile liquid representation to a Drop & add front matter defaults support to StaticFiles (#5940)
|
||||
|
||||
## 3.4.1 / 2017-03-02
|
||||
|
||||
* Backport #5920 for v3.4.x: Allow abbreviated post dates (#5924)
|
||||
|
||||
## 3.4.0 / 2017-01-27
|
||||
|
||||
### Minor Enhancements
|
||||
|
||||
* Add connector param to `array_to_sentence_string` filter (#5597)
|
||||
* Adds `group_by_exp` filter (#5513)
|
||||
* Use Addressable instead of URI to decode (#5726)
|
||||
* throw IncludeTagError if error occurs in included file (#5767)
|
||||
* Write Jekyll::Utils::Exec.run for running shell commands. (#5640)
|
||||
* Use the current year for the LICENSE of theme (#5712)
|
||||
* Update License (#5713)
|
||||
|
||||
### Bug Fixes
|
||||
|
||||
* Escaped regular expressions when using `post_url`. (#5605)
|
||||
* fix date parsing in file names to be stricter (#5609)
|
||||
* Add a module to re-define `ENV["TZ"]` in Windows (#5612)
|
||||
* Use each instead of map to actually return nothing (#5668)
|
||||
* include: fix 'no implicit conversion of nil to String' (#5750)
|
||||
* Don't include the theme's includes_path if it is nil. (#5780)
|
||||
* test double slash when input = '/' (#5542)
|
||||
* use logger.info for related posts (#5822)
|
||||
|
||||
### Site Enhancements
|
||||
|
||||
* Use only the used Font Awesome icons. (#5530)
|
||||
* Switch to `https` when possible. (#5611)
|
||||
* Update `_font-awesome.scss` to move .woff file before .ttf (#5614)
|
||||
* Update documentation on updating FontAwesome Iconset (#5655)
|
||||
* [site] Use defaults for docs and news-items (#5744)
|
||||
* Sort gems in `docs/_config.yml` (#5746)
|
||||
* Add missing class (#5791)
|
||||
* Improve template docs (#5694)
|
||||
|
||||
### Development Fixes
|
||||
|
||||
* clean unit-test names in `test/test_tags.rb` (#5608)
|
||||
* Add cucumber feature to test for bonafide theme gems (#5384)
|
||||
* Use `assert_nil` instead of `assert_equal nil` (#5652)
|
||||
* Rubocop -a on lib/jekyll (#5666)
|
||||
* Bump to rake 12.0 (#5670)
|
||||
* Rubocop Gemfile (#5671)
|
||||
* update Classifier-Reborn to 2.1.0 (#5711)
|
||||
* Rubocop: fix Rakefile and gemspec (#5745)
|
||||
* Use `assert_nil` (#5725)
|
||||
* Sort gems in `jekyll.gemspec` (#5746)
|
||||
* Rubocop: Require consistent comma in multiline literals (#5761)
|
||||
* Bump rubocop (#5765)
|
||||
* New rubocop security checks (#5768)
|
||||
* test/helper: fix flaky plugin path test by removing calls to Dir.chdir without a block (#5779)
|
||||
* Use latest jemoji gem (#5782)
|
||||
* Bump htmlproofer (#5781)
|
||||
* Bump rubies we test against (#5784)
|
||||
* Bump rdoc to v5.0 (#5797)
|
||||
* Bump codeclimate-test-reporter to v1.0.5 (#5798)
|
||||
|
||||
### Documentation
|
||||
|
||||
* Improve quickstart docs (#5689)
|
||||
* Add Jekyll-Post to list of plugins (#5705)
|
||||
* Add jekyll-numbered-headings (#5688)
|
||||
* Docs: move permalinks from documents into config (#5544)
|
||||
* Improve collections docs (#5691)
|
||||
* Fix #5730: add gcc and make to the list of requirements (#5731)
|
||||
* Remove instructions to install Jekyll 2 on Windows (#5582)
|
||||
* Fix example URL inconsistency (#5592)
|
||||
* Replace backticks within HTML blocks with HTML tags (#5435)
|
||||
* Add jekyll-migrate-permalink (#5600)
|
||||
* Fix bad config YAML in collections example (#5587)
|
||||
* Bring documentation on 'Directory Structure' up-to-date (#5573)
|
||||
* Fixed typo (#5632)
|
||||
* use backticks for Gemfile for consistency since in the next sentence … (#5641)
|
||||
* Update Core team list in the README file (#5643)
|
||||
* Improve Permalinks documentation. (#5653)
|
||||
* Fix typo in Variables doc page (#5657)
|
||||
* Fix a couple of typos in the docs (#5658)
|
||||
* Update windows.md (#5683)
|
||||
* Improve permalinks docs (#5693)
|
||||
* Document --unpublished build option (#5720)
|
||||
* Improve pages docs (#5692)
|
||||
* Added new includes.md topic to docs (#5696)
|
||||
* Replace a dead link with a web-archived one (#5738)
|
||||
* Remove duplicate paragraph. (#5740)
|
||||
* Addition of a sample "typical post" (#5473)
|
||||
* Fix a minor grammatical mistake on themes' document ### -dev (#5748)
|
||||
* Correct comments in data_reader.rb (#5621)
|
||||
* Add jekyll-pre-commit to plugins list (#5752)
|
||||
* Update quickstart.md (#5758)
|
||||
* Correct minor typo (#5764)
|
||||
* Fix a markdown link to look properly on the web (#5769)
|
||||
* [docs] Info about the help command usage (#5312)
|
||||
* Add missing merge labels for jekyllbot (#5753)
|
||||
* Fix broken links in documentation (#5736)
|
||||
* Docs: add `match_regex` and `replace_regex` filters (#5799)
|
||||
* Got that diaper money? (#5810)
|
||||
* Sort content by popularity using Google Analytics (#5812)
|
||||
* Rework CI doc to include multiple providers. (#5815)
|
||||
* Improve theme docs (#5690)
|
||||
* Add mention of classifier-reborn for LSI (#5811)
|
||||
* Added note about --blank flag (#5802)
|
||||
* Fixed inaccuracy in "Built-in permalink styles" docs (#5819)
|
||||
|
||||
## 3.3.1 / 2016-11-14
|
||||
|
||||
### Minor Enhancements
|
||||
|
||||
* Collapse `gsub` for performance (#5494)
|
||||
* URL: warn if key doesn't exist in url drop (#5524)
|
||||
|
||||
### Bug Fixes
|
||||
|
||||
* Fix typo in `theme_template` README (#5472)
|
||||
* Do not swallow all exceptions on render (#5495)
|
||||
* Site template: fixed `_config.yml` comment typo (#5511)
|
||||
* `jekyll new-theme` should specify Jekyll as a runtime dependency for the theme (#5457)
|
||||
* Be much more specific about ignoring specific vendored directories. (#5564)
|
||||
* Only warn about auto-regeneration bug on Bash On Windows. (#5464)
|
||||
* Allow permalink template to have underscores (#5572)
|
||||
|
||||
### Site Enhancements
|
||||
|
||||
* Documentation: `link` Liquid tag (#5449)
|
||||
* Updating install instruction link for Jekyll 3 on Windows (#5475)
|
||||
* Update normalize.css to v5.0.0 (#5471)
|
||||
* Add jekyll-data to the list of plugins (#5491)
|
||||
* Add info about checking version + updating (#5497)
|
||||
* Add jekyll-include-absolute-plugin to list of third-party plugins (#5492)
|
||||
* Remove jekyll-hook from deployment methods (#5502)
|
||||
* Update deployment-methods.md (#5504)
|
||||
* Ubuntu users should install ruby2.3-dev (#5512)
|
||||
* Remove Glynn as deployment option (#5519)
|
||||
* Fix broken forum link (#5466)
|
||||
* Move documentation to docs folder (#5459)
|
||||
* Fix broken links in CONTRIBUTING (#5533)
|
||||
* Update documentation on jekyllrb.com (#5540)
|
||||
* Fix HTML rendering (#5536)
|
||||
* Remove outdated deployment information (#5557)
|
||||
* no more invalid US-ASCII on lines 30 and 97 (#5520)
|
||||
* Add permalinks to docs in '/maintaining/' (#5532)
|
||||
* Add jekyll-pinboard to list of third-party plugins (#5514)
|
||||
* Fix formatting in 2-to-3.md (#5507)
|
||||
* Add two plugins to the plugins page (#5493)
|
||||
* Use site.baseurl before link and post_url tags (#5559)
|
||||
* Fix link to jekyll-pinboard plugin (#5570)
|
||||
* mention `docs` folder as a way to deploy on GitHub Pages (#5571)
|
||||
|
||||
### Development Fixes
|
||||
|
||||
* fix rubocop errors on testing with Rubocop 0.44 (#5489)
|
||||
* script/test: add missing whitespace (#5479)
|
||||
* Restrict Rubocop version (#5496)
|
||||
* include a hashbang for all benchmark scripts & make them executable (#5505)
|
||||
* Update source in script/proof (#5538)
|
||||
* Collections.feature: conditional steps to have it pass on Windows (#5546)
|
||||
* Fix tests to get script/test to pass on Windows (#5526)
|
||||
|
||||
## 3.3.0 / 2016-10-06
|
||||
|
||||
### Minor Enhancements
|
||||
|
||||
* Colorize interpolated output in logger.info (#5239)
|
||||
* Site template: exclude Gemfile and Gemfile.lock in site config (#5293)
|
||||
* Fix #5233: Increase our ability to detect Windows. (#5235)
|
||||
* update gitignore template to ignore theme gems built by user (#5326)
|
||||
* Adds ability to link to all files (#5199)
|
||||
* Exclude vendor by default (#5361)
|
||||
* Add ThemeAssetsReader which reads assets from a theme (#5364)
|
||||
* Add bundle install to jekyll new command (#5237)
|
||||
* Add absolute_url and relative_url filters. (#5399)
|
||||
* Site template: remove `css/` from new site scaffolding (#5402)
|
||||
* Site template: Move contents of the index.html page to the 'home' layout (#5420)
|
||||
* Exclude node_modules by default (#5210)
|
||||
* Run hooks in priority order. (#5157)
|
||||
* Add `static_file.name` and `.basename` Liquid attributes (#5264)
|
||||
* set site.url in dev environment to `http://localhost:4000` (#5431)
|
||||
* Add support for indented link references on excerpt (#5212)
|
||||
|
||||
### Bug Fixes
|
||||
|
||||
* Use jekyll-feed to generate the default site's RSS feed (#5196)
|
||||
* Site#configure_theme: do not set theme unless it's a string (#5189)
|
||||
* Convertible: set self.output in #render_all_layouts and #do_layout (#5337)
|
||||
* Only complain about `kramdown.coderay` if it is actually in the config (#5380)
|
||||
* Clarify documentation in theme gem's README template (#5376)
|
||||
* Allow underscore in highlighter language (#5375)
|
||||
* Site template: set empty url in config file by default (#5338)
|
||||
* Site template config: prepend 'jekyll serve' with 'bundle exec' (#5430)
|
||||
* Don't call `File.utime` for StaticFiles if it's a symlink (#5427)
|
||||
* Fix handling of non-ASCII characters in new `*_url` filters (#5410)
|
||||
* Remove autoload of Draft which no longer exists. (#5441)
|
||||
* Fix issue where Windows drive name is stripped from Jekyll.sanitized_path incorrectly (#5256)
|
||||
* Fix bug where `post_url` tag matched incorrect post with subdirectory (#4873)
|
||||
* Fix loading data from subdir with a period in name (#5433)
|
||||
* Revert Commands::Serve#server_address signature change. (#5456)
|
||||
|
||||
### Site Enhancements
|
||||
|
||||
* Document `to_integer` and `inspect` filters (#5185)
|
||||
* Fix path in the prompt (#5194)
|
||||
* need subcommand build (#5190)
|
||||
* Add the Jekyll Cloudinary plugin (#5183)
|
||||
* Documentation : `new-theme` command (#5205)
|
||||
* Document `link` Liquid tag (#5182)
|
||||
* Remove mention of page for link tag in release post (#5214)
|
||||
* fixed typo (#5226)
|
||||
* Add missing comma (#5222)
|
||||
* Maintain aspect ratio with `height: auto;` (#5254)
|
||||
* Fix a link in deployment-methods.md (#5244)
|
||||
* Documentation: improve highlight in `Creating a theme` (#5249)
|
||||
* Bundler isn't installed by default (#5258)
|
||||
* Update troubleshooting documentation to include fix for issue with vendored gems (#5271)
|
||||
* Link `--lsi` option's description to Wikipedia docs on LSI (#5274)
|
||||
* Document `--profile` option on the configuration page (#5279)
|
||||
* Update homepage to sync with merge of #5258 (#5287)
|
||||
* Add post about Jekyll Admin initial release (#5291)
|
||||
* Replace liquid highlight tag with backticks (#5262)
|
||||
* Word update (#5294)
|
||||
* Site documentation section links always point to https://jekyllrb.com (#5281)
|
||||
* Missing `:site, :post_render` payload documentation on site (#5280)
|
||||
* Site: exclude README.md and .gitignore (#5304)
|
||||
* Add link to Staticman (#5224)
|
||||
* Update url for OpenShift (#5320)
|
||||
* [docs] add help for missing static_file e.g. on heroku (#5334)
|
||||
* Add a line about updating theme-gems in the docs (#5318)
|
||||
* Explain how to copy a theme's files (#5335)
|
||||
* [docs] .md as default extension in examples (#5316)
|
||||
* Fix small typo in docs (#5347)
|
||||
* Add missing period to sentence in first paragraph. (#5372)
|
||||
* added jekyll-spotify plugin (#5369)
|
||||
* Add jekyll-menus to the list of plugins. (#5397)
|
||||
* macOS and one grammar fix (#5403)
|
||||
* Add documentation for `relative_url` and `absolute_url` (#5405)
|
||||
* Bugfix on logo in JSON-LD (#5421)
|
||||
* Fix Travis.ci documentation (#5413)
|
||||
* [docs] Update documentation regarding `bundle install` after `jekyll new` (#5428)
|
||||
* Replace classic box-sizing reset with inheritance reset (#5411)
|
||||
* Update Wikipedia YAML list link (#5452)
|
||||
* Add Jekyll 3.3 release post (#5442)
|
||||
|
||||
### Development Fixes
|
||||
|
||||
* Update appveyor.yml and fix optional deps for Ruby x64 (#5180)
|
||||
* Improve tests for Jekyll::PluginManager (#5167)
|
||||
* Update Ruby versions in travis.yml (#5221)
|
||||
* Avoid installing unecessary gems for site testing (#5272)
|
||||
* Proposal: Affinity teams and their captains (#5273)
|
||||
* Replace duplicate with postive local test in issue template (#5286)
|
||||
* Update AppVeyor config. (#5240)
|
||||
* Execute jekyll from clone instead of defined binary when running 'script/default-site' (#5295)
|
||||
* rubocop: lib/jekyll/document.rb complexity fixes (#5045)
|
||||
* Proxy a number of Convertible methods to Renderer (#5308)
|
||||
* Run executable for Cucumber via Ruby instead of Shell (#5383)
|
||||
* Appease Rubocop (#5381)
|
||||
* remove features' directories on windows with proper access (#5389)
|
||||
* `site_configuration.feature`: use UTC format in timezone (#5416)
|
||||
* swallow bundle output from `jekyll new` while in CI (#5408)
|
||||
* Add .editorconfig (#5412)
|
||||
|
||||
## 3.2.1 / 2016-08-02
|
||||
|
||||
### Bug Fixes
|
||||
|
||||
* Include theme directories in default gemspec (#5152)
|
||||
* Fix for symlinked themes (#5156)
|
||||
* Layout: set `relative_path` without using Pathname (#5164)
|
||||
|
||||
### Development Fixes
|
||||
|
||||
* Add test to build the default site (#5154)
|
||||
* script/default-site: specify `BUNDLE_GEMFILE` for new site (#5178)
|
||||
* script/default-site: read Jekyll source from local clone (#5188)
|
||||
|
||||
### Site Enhancements
|
||||
|
||||
* Enable site excerpts (#5150)
|
||||
* Initial 404 page (#5143)
|
||||
* Remove the "this feature is unreleased" warning from the theme docs (#5158)
|
||||
* Future True on GitHub Pages note (#5173)
|
||||
* Minor updates and corrections (#5177)
|
||||
* index.html: update instructions to require bundler (#5169)
|
||||
* docs/quickstart: update instructions to require bundler (#5168)
|
||||
|
||||
## 3.2.0 / 2016-07-26
|
||||
|
||||
### Minor Enhancements
|
||||
|
||||
* Stop testing with Ruby 2.0.x, which is EOL'd. (#4381)
|
||||
* Allow collections to have documents that have no file extension (#4545)
|
||||
* Add size property to `group_by` result (#4557)
|
||||
* Add size property to group_by result (#4557)
|
||||
* Site Template: Removed unnecessary nesting from `_base.scss` (#4637)
|
||||
* Adding a debug log statment for skipped future documents. (#4558)
|
||||
* Site Template: Changed main `<div>` to `<main>` and added accessibility info (#4636)
|
||||
* Add array support to `where` filter (#4555)
|
||||
* 'jekyll clean': also remove .sass-cache (#4652)
|
||||
* Clean up `Tags::PostUrl` a bit, including better errors and date parsing (#4670)
|
||||
* Use `String#encode` for `xml_escape` filter instead of `CGI.escapeHTML` (#4694)
|
||||
* Add `show_dir_listing` option for serve command and fix index file names (#4533)
|
||||
* Clean up Tags::PostUrl a bit, including better errors and date parsing (#4670)
|
||||
* Use String#encode for xml_escape filter instead of CGI.escapeHTML (#4694)
|
||||
* Add show_dir_listing option for serve command and fix index file names (#4533)
|
||||
* Site Template: write a Gemfile which is educational to the new site (#4542)
|
||||
* Site template: add explanation of site variables in the example `_config.yml` (#4704)
|
||||
* Adds `link` Liquid tag to make generation of URLs easier (#4624)
|
||||
* Adds `link` Liquid tag to make generation of URL's easier (#4624)
|
||||
* Allow static files to be symlinked in unsafe mode or non-prod environments (#4640)
|
||||
* Add `:after_init` hook & add `Site#config=` to make resetting config easy (#4703)
|
||||
* DocumentDrop: add `#<=>` which sorts by date (falling back to path) (#4741)
|
||||
* Add a `where_exp` filter for filtering by expression (#4478)
|
||||
* Globalize Jekyll's Filters. (#4792)
|
||||
* Gem-based themes (#4595)
|
||||
* Allow symlinks if they point to stuff inside `site.source` (#4710)
|
||||
* Update colorator dependency to v1.x (#4855)
|
||||
* Move EntryFilter to use Pathutil & fix `glob_include?` (#4859)
|
||||
* Add 'jekyll new-theme' command to help users get up and running creating a theme (#4848)
|
||||
* `markdownify` and `smartify` should convert input to string before conversion (#4958)
|
||||
* Run `Site#generate` for 'jekyll doctor' to catch plugin issues (#5005)
|
||||
* Add `normalize_whitepace` filter (#4917)
|
||||
* Move bin/jekyll to exe/jekyll to prevent collision with binstubs (#5014)
|
||||
* Cleaning up site template & theme updates. (#4922)
|
||||
* Add fetch method to Drops (#5056)
|
||||
* Extract tag name to class method (#5063)
|
||||
* check if relative URL contains a colon (#5069)
|
||||
* Enable strict (or lax) liquid parsing via a config variable. (#5053)
|
||||
* Add filter: `to_integer` (#5101)
|
||||
* watcher: pass site instance to watch plugin (#5109)
|
||||
* Show liquid warnings. (#5129)
|
||||
* Add `--baseurl` to `build` subcommand (#5135)
|
||||
|
||||
### Bug Fixes
|
||||
|
||||
* Site Template: Added a default lang attribute (#4633)
|
||||
* Site template: Escape title and description where it is used in HTML (#4606)
|
||||
* `Document#date`: drafts which have no date should use source file mtime (#4611)
|
||||
* `Filters#time`: clone an input Time so as to be non-destructive (#4590)
|
||||
* Document#date: drafts which have no date should use source file mtime (#4611)
|
||||
* Filters#time: clone an input Time so as to be non-destructive (#4590)
|
||||
* Doctor: fix issue where `--config` wasn't a recognized flag (#4598)
|
||||
* Ensures `related_posts` are only set for a post (#4620)
|
||||
* `EntryFilter#special?`: ignore filenames which begin with `~` (#4491)
|
||||
* Ensures related_posts are only set for a post (#4620)
|
||||
* EntryFilter#special?: ignore filenames which begin with '~' (#4491)
|
||||
* Cleaner: `keep_files` should only apply to the beginning of paths, not substrings with index > 0 (#3849)
|
||||
* Use SSLEnable instead of EnableSSL and make URL HTTPS. (#4693)
|
||||
* convertible: use `Document::YAML_FRONT_MATTER_REGEXP` to parse transformable files (#4786)
|
||||
* Example in the site template should be IANA-approved example.com (#4793)
|
||||
* 3.2.x/master: Fix defaults for Documents (posts/collection docs) (#4808)
|
||||
* Don't rescue LoadError or bundler load errors for Bundler. (#4857)
|
||||
* `Serve.process` should receive same config as `Build.process` (#4953)
|
||||
* Prevent reset of page in Liquid payload right before rendering layouts (#5009)
|
||||
* Add missing fields to ExcerptDrop (#5067)
|
||||
* Stringify configuration overrides before first use (#5060)
|
||||
* hooks: move `after_init` hook call at the end of `Site#initialize` (#5106)
|
||||
* filters: raise error if no input given to date filters (#5127)
|
||||
* `where_exp` filter should filter posts (#4860)
|
||||
|
||||
### Forward Ports
|
||||
|
||||
* From v3.1.4: Add ExcerptDrop and remove excerpt's ability to refer to itself in Liquid (#4941)
|
||||
* From v3.1.4: Configuration permalink fix and addition of Configuration.from and sorting `site.collections` by label (#4942)
|
||||
* From v3.1.4: Fix `{{ layout }}` oddities (proper inheritance & fixing overflow of old data) (#4943)
|
||||
* From v3.1.5: Sort the results of the `require_all` glob (#4944)
|
||||
* From v3.1.6: Add ability to render drops as JSON (#4945)
|
||||
|
||||
### Development Fixes
|
||||
|
||||
@@ -589,56 +41,6 @@
|
||||
* Update Rake & disable warnings when running tests (#4720)
|
||||
* Fix many warnings (#4537)
|
||||
* Don't blindly assume the last system when determining "open" cmd (#4717)
|
||||
* Fix "locally" typo in contributing documentation (#4756)
|
||||
* Update Rubocop rules (#4886)
|
||||
* Flesh out the issue template to be much more detailed (#4849)
|
||||
* Fixing rubocop offenses in lib/jekyll/cleaner.rb (#4892)
|
||||
* Update `jekyll/commands*` to pass rubocop rules (#4888)
|
||||
* Clean up many test files to pass Rubocop rules (#4902)
|
||||
* Rubocop cleanup for some utils and further test files (#4916)
|
||||
* Rubocop: Low hanging fruit (#4936)
|
||||
* Rubocop: `Drop` changes from v3.1 forward-ports (#4949)
|
||||
* Rubocop: cleanup for misc files (#4946)
|
||||
* Rubocop: Stevenson (#4951)
|
||||
* Rubocop: lib/jekyll/entry_filter.rb (#4950)
|
||||
* Rubocop: `test/*` (#4947)
|
||||
* Rubocop: features (#4934)
|
||||
* Rubocop: Liquid renderer (#4933)
|
||||
* Rubocop: converters (#4931)
|
||||
* Rubocop: Site Drop (#4948)
|
||||
* Rubocop: tags (#4938)
|
||||
* Rubocop: Readers (#4932)
|
||||
* rubocop: jekyll/lib/frontmatter_defaults.rb (#4974)
|
||||
* rubocop: features/step_definitions.rb (#4956)
|
||||
* Rubocop theme and url jekyll libs (#4959)
|
||||
* Rubocop jekyll.rb (#4966)
|
||||
* Rubocop: use %r for all regular expressions. (#4979)
|
||||
* Cleanup and make misc files compliant with Rubocop. (#4940)
|
||||
* Rubocop: jekyll/lib/site.rb (#4973)
|
||||
* Add timings for each scenario in cucumber & print worst offenders (#4908)
|
||||
* rubocop: jekyll/lib/filters.rb (#4993)
|
||||
* Fix rubocop offenses in exe/jekyll (#5017)
|
||||
* Rubocop: lib/jekyll/command.rb (#5018)
|
||||
* rubocop: lib/jekyll/static_file.rb (#5019)
|
||||
* rubocop: lib/jekyll/utils.rb (#5026)
|
||||
* rubocop: lib/jekyll/regenerator.rb (#5025)
|
||||
* rubocop: lib/jekyll/configuration.rb (#5024)
|
||||
* rubocop: lib/jekyll/renderer.rb style fixes (#5032)
|
||||
* rubocop: lib/jekyll/convertible.rb style fixes (#5031)
|
||||
* rubocop: lib/jekyll/document.rb style fixes (#5030)
|
||||
* Remove ruby-head from Travis matrix & fix jruby failures (#5015)
|
||||
* Remove useless statement from Configuration test (#5065)
|
||||
* Change baseurl to example.com for some test cases (#5068)
|
||||
* use activesupport < 5 if we are on a Ruby < 2.2.2 (#5100)
|
||||
* Internal documentation for working on Jekyll (#5011)
|
||||
* rubocop: lib/jekyll/collection.rb (#5022)
|
||||
* tests: Typo fixes. (#5114)
|
||||
* Normalize yml files. (#5116)
|
||||
* Whitespace cleanup. (#5113)
|
||||
* Add AppVeyor support. (#5115)
|
||||
* appveyor.yml: drop Ruby 2.0.0. (#5119)
|
||||
* Fix indentation in benchmark (#5124)
|
||||
* Style fixes for Rubocop 0.42.0 - var == 0 becomes var.zero? - when defining method_missing, also define respond_to_missing? (#5137)
|
||||
|
||||
### Site Enhancements
|
||||
|
||||
@@ -663,78 +65,6 @@
|
||||
* Add Hawkins to the list of third-party plugins (#4755)
|
||||
* Fix a typo in pagination doc (#4763)
|
||||
* Switch second GitHub Pages link to HTTPS (#4760)
|
||||
* Explain data file format requirements more clearly in documentation (#4781)
|
||||
* Add jekyll-i18n_tags to list of third-party plugins (#4775)
|
||||
* Remove Leonard Lamprecht's website from Sites page (#4771)
|
||||
* Updates documentation for collections to include `date` property (#4769)
|
||||
* Added an explicit rerun note to configuration.md, defaults section (#4734)
|
||||
* Update Rack-Jekyll Heroku deployment blog post url (#4789)
|
||||
* Added missing single quote on rsync client side command (#4813)
|
||||
* Organize Form Platforms-as-a-Service into unified list & add FormSpree.io (#4754)
|
||||
* Fixed typo on Configuration page (#4804)
|
||||
* Update FormKeep URL on the Resources doc (#4844)
|
||||
* site: use liquid & reduce some whitespace noise (#4854)
|
||||
* Add jekyll-breadcrumbs to list of third-party plugins (#4874)
|
||||
* Added Pug converter to list of third-party plugins (#4872)
|
||||
* Add jekyll-ideal-image-slider to list of third-party plugins (#4863)
|
||||
* Add Jekyll Tips and the Cheatsheet to the list of resources (#4887)
|
||||
* Removed extra `</p>` from `site/_docs/permalinks.md` (#4890)
|
||||
* Add pubstorm deployment instructions to docs (#4881)
|
||||
* Corrected pagination docs for hidden: true feature (#4903)
|
||||
* Remove a Broken Link for Refheap Plugin (#4971)
|
||||
* Instructions on how to install github-gem on Windows (#4975)
|
||||
* Minor tweak to fix missing apostrophne (#4962)
|
||||
* Instructions on how to install github-gem on Windows (v2) (#4977)
|
||||
* Fix inaccurate HTTP response header field name (#4976)
|
||||
* Add post about GSoC project (#4980)
|
||||
* Link to the HTML page instead of Markdown (#4985)
|
||||
* Update normalize.css to v4.0.0. (#4989)
|
||||
* Add jekyll-tags-list-plugin to list of third-party plugins (#5000)
|
||||
* Windows docs: Command needs to be called from blog path (#5006)
|
||||
* Update text to be consitent with example (#5010)
|
||||
* Update template links to point to core Liquid site (#5012)
|
||||
* Add generator-jekyllized to third-party plugins (#5027)
|
||||
* Add Jekyll Art Hallery generator plugin to list of third-party plugins (#5043)
|
||||
* Add Formingo to the list of Jekyll form SaaS (#5054)
|
||||
* Highlight help nav item when navigated to. (#5058)
|
||||
* Update normalize.css to v4.2.0. (#5096)
|
||||
* Updates html-proofer code (#5098)
|
||||
* Jekyll Community (#5097)
|
||||
* Typo in documentation file templates.md (#5117)
|
||||
* Slightly, improve PNG compression. (#5112)
|
||||
* docs: add jekyll-maps plugin reference (#5123)
|
||||
* docs: fix link to plugins page source (#5122)
|
||||
* Update the configuration docs to match the code (#5131)
|
||||
* Removed confusing word repetition. (#5139)
|
||||
* Add a note about script/fmt (#5138)
|
||||
|
||||
## 3.1.6 / 2016-05-19
|
||||
|
||||
### Bug Fixes
|
||||
|
||||
* Add ability to `jsonify` Drops such that, e.g. `site | jsonify`, works. (#4914)
|
||||
|
||||
## 3.1.5 / 2016-05-18
|
||||
|
||||
### Bug Fixes
|
||||
|
||||
* Sort the results of the `require_all` glob (affects Linux only). (#4912)
|
||||
|
||||
## 3.1.4 / 2016-05-18
|
||||
|
||||
### Bug Fixes
|
||||
|
||||
* Add `ExcerptDrop` and remove excerpt's ability to refer to itself in Liquid (#4907)
|
||||
* Configuration permalink fix where `collections.posts.permalink` inherits properly from `permalink` only when it doesn't exist (#4910)
|
||||
* Add `Configuration.from` to make it easier to build configs from just a hash
|
||||
* Sorting `site.collections` in Liquid by label (#4910)
|
||||
* Fix bug where `layout` in Liquid would inherit from previously-rendered layouts' metadatas (#4909)
|
||||
* Fix bug where `layout` in Liquid would override in the wrong direction (more-specific layouts' data were overwritten by their parent layouts' data; this has now been reversed) (#4909)
|
||||
|
||||
## 3.1.3 / 2016-04-18
|
||||
|
||||
* Fix defaults for Documents to lookup defaults based on `relative_path` instead of `url` (#4807)
|
||||
* Use SSLEnable instead of EnableSSL and make URL HTTPS (WEBrick) (#4693)
|
||||
|
||||
## 3.1.2 / 2016-02-19
|
||||
|
||||
@@ -883,15 +213,6 @@
|
||||
* Add Contentful Extension to list of third-party plugins (#4390)
|
||||
* Correct Minor spelling error (#4394)
|
||||
|
||||
## 3.0.5 / 2016-04-26
|
||||
|
||||
* Remove call to `#backwards_compatibilize` in `Configuration.from` (#4846)
|
||||
|
||||
## 3.0.4 / 2016-04-18
|
||||
|
||||
* Fix defaults for Documents to lookup defaults based on `relative_path` instead of `url` (#4806)
|
||||
* Configuration: allow users to specify a `collections.posts.permalink` directly without `permalink` clobbering it (#4753)
|
||||
|
||||
## 3.0.3 / 2016-02-08
|
||||
|
||||
### Bug Fixes
|
||||
@@ -1306,7 +627,7 @@
|
||||
* Fix Rouge's RedCarpet plugin interface integration (#2951)
|
||||
* Remove `--watch` from the site template blog post since it defaults to watching in in 2.4.0 (#2922)
|
||||
* Fix code for media query mixin in site template (#2946)
|
||||
* Allow post URLs to have `.htm` extensions (#2925)
|
||||
* Allow post URL's to have `.htm` extensions (#2925)
|
||||
* `Utils.slugify`: Don't create new objects when gsubbing (#2997)
|
||||
* The jsonify filter should deep-convert to Liquid when given an Array. (#3032)
|
||||
* Apply `jsonify` filter to Hashes deeply and effectively (#3063)
|
||||
|
||||
2
LICENSE
2
LICENSE
@@ -1,6 +1,6 @@
|
||||
The MIT License (MIT)
|
||||
|
||||
Copyright (c) 2008-2017 Tom Preston-Werner and Jekyll contributors
|
||||
Copyright (c) 2008-2016 Tom Preston-Werner
|
||||
|
||||
Permission is hereby granted, free of charge, to any person obtaining a copy
|
||||
of this software and associated documentation files (the "Software"), to deal
|
||||
|
||||
@@ -1,11 +1,10 @@
|
||||
# [Jekyll](https://jekyllrb.com/)
|
||||
|
||||
[][ruby-gems]
|
||||
[][travis]
|
||||
[][appveyor]
|
||||
[][coverage]
|
||||
[][codeclimate]
|
||||
[][gemnasium]
|
||||
[][travis]
|
||||
[][coverage]
|
||||
[][codeclimate]
|
||||
[][gemnasium]
|
||||
[][hakiri]
|
||||
|
||||
[ruby-gems]: https://rubygems.org/gems/jekyll
|
||||
@@ -14,7 +13,6 @@
|
||||
[coverage]: https://codeclimate.com/github/jekyll/jekyll/coverage
|
||||
[hakiri]: https://hakiri.io/github/jekyll/jekyll/master
|
||||
[travis]: https://travis-ci.org/jekyll/jekyll
|
||||
[appveyor]: https://ci.appveyor.com/project/jekyll/jekyll/branch/master
|
||||
|
||||
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.
|
||||
|
||||
@@ -22,9 +20,9 @@ Jekyll is a simple, blog-aware, static site generator perfect for personal, proj
|
||||
|
||||
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.
|
||||
|
||||
## Having trouble with OS X/macOS?
|
||||
## Having trouble with OS X El Capitan?
|
||||
|
||||
See: https://jekyllrb.com/docs/troubleshooting/
|
||||
See: https://jekyllrb.com/docs/troubleshooting/#jekyll-amp-mac-os-x-1011
|
||||
|
||||
## Getting Started
|
||||
|
||||
@@ -43,7 +41,8 @@ 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 a maintainer ([@parkr](https://github.com/parkr), [@envygeeks](https://github.com/envygeeks), [@mattr-](https://github.com/mattr-), or [@alfredxing](https://github.com/alfredxing)) know and we will address it as soon as possible.
|
||||
these terms, please let a maintainer ([@parkr](https://github.com/parkr), [@envygeeks](https://github.com/envygeeks), or [@mattr-](https://github.com/mattr-)) know
|
||||
and we will address it as soon as possible.
|
||||
|
||||
## Diving In
|
||||
|
||||
|
||||
77
Rakefile
77
Rakefile
@@ -1,13 +1,13 @@
|
||||
require "rubygems"
|
||||
require "rake"
|
||||
require "rdoc"
|
||||
require "date"
|
||||
require "yaml"
|
||||
require 'rubygems'
|
||||
require 'rake'
|
||||
require 'rdoc'
|
||||
require 'date'
|
||||
require 'yaml'
|
||||
|
||||
$LOAD_PATH.unshift File.expand_path("lib", __dir__)
|
||||
require "jekyll/version"
|
||||
$LOAD_PATH.unshift(File.join(File.dirname(__FILE__), *%w[lib]))
|
||||
require 'jekyll/version'
|
||||
|
||||
Dir.glob("rake/**.rake").each { |f| import f }
|
||||
Dir.glob('rake/**.rake').each { |f| import f }
|
||||
|
||||
#############################################################################
|
||||
#
|
||||
@@ -27,30 +27,26 @@ def docs_name
|
||||
"#{name}-docs"
|
||||
end
|
||||
|
||||
def docs_folder
|
||||
"docs"
|
||||
end
|
||||
|
||||
def gemspec_file
|
||||
"#{name}.gemspec"
|
||||
end
|
||||
|
||||
def gem_file
|
||||
"#{name}-#{Gem::Version.new(version)}.gem"
|
||||
"#{name}-#{Gem::Version.new(version).to_s}.gem"
|
||||
end
|
||||
|
||||
def normalize_bullets(markdown)
|
||||
markdown.gsub(%r!\n\s{2}\*{1}!, "\n-")
|
||||
markdown.gsub(/\n\s{2}\*{1}/, "\n-")
|
||||
end
|
||||
|
||||
def linkify_prs(markdown)
|
||||
markdown.gsub(%r!#(\d+)!) do |word|
|
||||
markdown.gsub(/#(\d+)/) do |word|
|
||||
"[#{word}]({{ site.repository }}/issues/#{word.delete("#")})"
|
||||
end
|
||||
end
|
||||
|
||||
def linkify_users(markdown)
|
||||
markdown.gsub(%r!(@\w+)!) do |username|
|
||||
markdown.gsub(/(@\w+)/) do |username|
|
||||
"[#{username}](https://github.com/#{username.delete("@")})"
|
||||
end
|
||||
end
|
||||
@@ -60,13 +56,13 @@ def linkify(markdown)
|
||||
end
|
||||
|
||||
def liquid_escape(markdown)
|
||||
markdown.gsub(%r!(`{[{%].+[}%]}`)!, "{% raw %}\\1{% endraw %}")
|
||||
markdown.gsub(/(`{[{%].+[}%]}`)/, "{% raw %}\\1{% endraw %}")
|
||||
end
|
||||
|
||||
def custom_release_header_anchors(markdown)
|
||||
header_regexp = %r!^(\d{1,2})\.(\d{1,2})\.(\d{1,2}) \/ \d{4}-\d{2}-\d{2}!
|
||||
section_regexp = %r!^### \w+ \w+$!
|
||||
markdown.split(%r!^##\s!).map do |release_notes|
|
||||
header_regexp = /^(\d{1,2})\.(\d{1,2})\.(\d{1,2}) \/ \d{4}-\d{2}-\d{2}/
|
||||
section_regexp = /^### \w+ \w+$/
|
||||
markdown.split(/^##\s/).map do |release_notes|
|
||||
_, major, minor, patch = *release_notes.match(header_regexp)
|
||||
release_notes
|
||||
.gsub(header_regexp, "\\0\n{: #v\\1-\\2-\\3}")
|
||||
@@ -75,11 +71,11 @@ def custom_release_header_anchors(markdown)
|
||||
end
|
||||
|
||||
def sluffigy(header)
|
||||
header.delete("#").strip.downcase.gsub(%r!\s+!, "-")
|
||||
header.gsub(/#/, '').strip.downcase.gsub(/\s+/, '-')
|
||||
end
|
||||
|
||||
def remove_head_from_history(markdown)
|
||||
index = markdown =~ %r!^##\s+\d+\.\d+\.\d+!
|
||||
index = markdown =~ /^##\s+\d+\.\d+\.\d+/
|
||||
markdown[index..-1]
|
||||
end
|
||||
|
||||
@@ -88,28 +84,25 @@ def converted_history(markdown)
|
||||
custom_release_header_anchors(
|
||||
liquid_escape(
|
||||
linkify(
|
||||
normalize_bullets(markdown)
|
||||
)
|
||||
)
|
||||
)
|
||||
)
|
||||
normalize_bullets(markdown)))))
|
||||
end
|
||||
|
||||
def siteify_file(file, overrides_front_matter = {})
|
||||
abort "You seem to have misplaced your #{file} file. I can haz?" unless File.exist?(file)
|
||||
abort "You seem to have misplaced your #{file} file. I can haz?" unless File.exists?(file)
|
||||
title = begin
|
||||
File.read(file).match(%r!\A# (.*)$!)[1]
|
||||
File.read(file).match(/\A# (.*)$/)[1]
|
||||
rescue
|
||||
File.basename(file, ".*").downcase.capitalize
|
||||
end
|
||||
slug = File.basename(file, ".markdown").downcase
|
||||
front_matter = {
|
||||
"title" => title,
|
||||
"layout" => "docs",
|
||||
"permalink" => "/docs/#{slug}/",
|
||||
"note" => "This file is autogenerated. Edit /#{file} instead.",
|
||||
"note" => "This file is autogenerated. Edit /#{file} instead."
|
||||
}.merge(overrides_front_matter)
|
||||
contents = "#{front_matter.to_yaml}---\n\n#{content_for(file)}"
|
||||
File.write("#{docs_folder}/_docs/#{slug}.md", contents)
|
||||
File.write("site/_docs/#{slug}.md", contents)
|
||||
end
|
||||
|
||||
def content_for(file)
|
||||
@@ -118,7 +111,7 @@ def content_for(file)
|
||||
when "History.markdown"
|
||||
converted_history(contents)
|
||||
else
|
||||
contents.gsub(%r!\A# .*\n\n?!, "")
|
||||
contents.gsub(/\A# .*\n\n?/, "")
|
||||
end
|
||||
end
|
||||
|
||||
@@ -131,23 +124,23 @@ end
|
||||
multitask :default => [:test, :features]
|
||||
|
||||
task :spec => :test
|
||||
require "rake/testtask"
|
||||
require 'rake/testtask'
|
||||
Rake::TestTask.new(:test) do |test|
|
||||
test.libs << "lib" << "test"
|
||||
test.pattern = "test/**/test_*.rb"
|
||||
test.libs << 'lib' << 'test'
|
||||
test.pattern = 'test/**/test_*.rb'
|
||||
test.verbose = true
|
||||
end
|
||||
|
||||
require "rdoc/task"
|
||||
require 'rdoc/task'
|
||||
Rake::RDocTask.new do |rdoc|
|
||||
rdoc.rdoc_dir = "rdoc"
|
||||
rdoc.rdoc_dir = 'rdoc'
|
||||
rdoc.title = "#{name} #{version}"
|
||||
rdoc.rdoc_files.include("README*")
|
||||
rdoc.rdoc_files.include("lib/**/*.rb")
|
||||
rdoc.rdoc_files.include('README*')
|
||||
rdoc.rdoc_files.include('lib/**/*.rb')
|
||||
end
|
||||
|
||||
begin
|
||||
require "cucumber/rake/task"
|
||||
require 'cucumber/rake/task'
|
||||
Cucumber::Rake::Task.new(:features) do |t|
|
||||
t.profile = "travis"
|
||||
end
|
||||
@@ -155,9 +148,9 @@ begin
|
||||
t.profile = "html_report"
|
||||
end
|
||||
rescue LoadError
|
||||
desc "Cucumber rake task not available"
|
||||
desc 'Cucumber rake task not available'
|
||||
task :features do
|
||||
abort "Cucumber rake task is not available. Be sure to install cucumber as a gem or plugin"
|
||||
abort 'Cucumber rake task is not available. Be sure to install cucumber as a gem or plugin'
|
||||
end
|
||||
end
|
||||
|
||||
|
||||
42
appveyor.yml
42
appveyor.yml
@@ -1,42 +0,0 @@
|
||||
version: "{build}"
|
||||
|
||||
clone_depth: 10
|
||||
|
||||
branches:
|
||||
only:
|
||||
- master
|
||||
- themes
|
||||
|
||||
build: off
|
||||
|
||||
install:
|
||||
- SET PATH=C:\Ruby%RUBY_FOLDER_VER%\bin;%PATH%
|
||||
- bundle install --retry 5 --jobs=%NUMBER_OF_PROCESSORS% --clean --path vendor\bundle
|
||||
|
||||
environment:
|
||||
BUNDLE_WITHOUT: "benchmark:site:development"
|
||||
matrix:
|
||||
- RUBY_FOLDER_VER: "24"
|
||||
TEST_SUITE: "test"
|
||||
- RUBY_FOLDER_VER: "24"
|
||||
TEST_SUITE: "cucumber"
|
||||
- RUBY_FOLDER_VER: "24"
|
||||
TEST_SUITE: "default-site"
|
||||
- RUBY_FOLDER_VER: "24-x64"
|
||||
TEST_SUITE: "test"
|
||||
- RUBY_FOLDER_VER: "23"
|
||||
TEST_SUITE: "test"
|
||||
- RUBY_FOLDER_VER: "22"
|
||||
TEST_SUITE: "test"
|
||||
- RUBY_FOLDER_VER: "21"
|
||||
TEST_SUITE: "test"
|
||||
|
||||
test_script:
|
||||
- ruby --version
|
||||
- gem --version
|
||||
- bundler --version
|
||||
- bash ./script/cibuild
|
||||
|
||||
cache:
|
||||
# If one of the files after the right arrow changes, cache will be skipped
|
||||
- 'vendor\bundle -> appveyor.yml,Gemfile,jekyll.gemspec'
|
||||
@@ -1,21 +0,0 @@
|
||||
#!/usr/bin/env ruby
|
||||
require "liquid"
|
||||
require "benchmark/ips"
|
||||
|
||||
puts "Ruby #{RUBY_VERSION}-p#{RUBY_PATCHLEVEL}"
|
||||
puts "Liquid #{Liquid::VERSION}"
|
||||
|
||||
template1 = '{% capture foobar %}foo{{ bar }}{% endcapture %}{{ foo }}{{ foobar }}'
|
||||
template2 = '{% assign foobar = "foo" | append: bar %}{{ foobar }}'
|
||||
|
||||
def render(template)
|
||||
Liquid::Template.parse(template).render("bar" => "42")
|
||||
end
|
||||
|
||||
puts render(template1)
|
||||
puts render(template2)
|
||||
|
||||
Benchmark.ips do |x|
|
||||
x.report('capture') { render(template1) }
|
||||
x.report('assign') { render(template2) }
|
||||
end
|
||||
1
benchmark/end-with-vs-regexp
Executable file → Normal file
1
benchmark/end-with-vs-regexp
Executable file → Normal file
@@ -1,4 +1,3 @@
|
||||
#!/usr/bin/env ruby
|
||||
require 'benchmark/ips'
|
||||
|
||||
Benchmark.ips do |x|
|
||||
|
||||
0
benchmark/file-dir-ensure-trailing-slash
Executable file → Normal file
0
benchmark/file-dir-ensure-trailing-slash
Executable file → Normal file
1
benchmark/flat-map
Executable file → Normal file
1
benchmark/flat-map
Executable file → Normal file
@@ -1,4 +1,3 @@
|
||||
#!/usr/bin/env ruby
|
||||
require 'benchmark/ips'
|
||||
|
||||
enum = (0..50).to_a
|
||||
|
||||
1
benchmark/hash-fetch
Executable file → Normal file
1
benchmark/hash-fetch
Executable file → Normal file
@@ -1,4 +1,3 @@
|
||||
#!/usr/bin/env ruby
|
||||
require 'benchmark/ips'
|
||||
|
||||
h = {:bar => 'uco'}
|
||||
|
||||
0
benchmark/jekyll-sanitize-path
Executable file → Normal file
0
benchmark/jekyll-sanitize-path
Executable file → Normal file
1
benchmark/proc-call-vs-yield
Executable file → Normal file
1
benchmark/proc-call-vs-yield
Executable file → Normal file
@@ -1,4 +1,3 @@
|
||||
#!/usr/bin/env ruby
|
||||
require 'benchmark/ips'
|
||||
|
||||
def fast
|
||||
|
||||
@@ -1,36 +0,0 @@
|
||||
#!/usr/bin/env ruby
|
||||
# frozen_string_literal: true
|
||||
|
||||
require "benchmark/ips"
|
||||
require "benchmark/memory"
|
||||
|
||||
GC.disable
|
||||
|
||||
PERIOD = "."
|
||||
PROPERTY_AS_HASH = ["hello", "there_oh", "friends"]
|
||||
property = "hello.there_oh.friends"
|
||||
item = Hash.new { |h, k| h[k] = Hash.new(&h.default_proc) }
|
||||
|
||||
def candidate(property, item)
|
||||
property.to_s.split(".".freeze).each_with_object(item) do |attribute, memo|
|
||||
memo = memo[attribute]
|
||||
end
|
||||
end
|
||||
|
||||
def control(property, item)
|
||||
property.to_s.split(".").reduce(item) do |subvalue, attribute|
|
||||
subvalue[attribute]
|
||||
end
|
||||
end
|
||||
|
||||
Benchmark.ips do |x|
|
||||
x.report("candidate") { candidate(property, item) }
|
||||
x.report("control") { control(property, item) }
|
||||
x.compare!
|
||||
end
|
||||
|
||||
Benchmark.memory do |x|
|
||||
x.report("candidate") { candidate(property, item) }
|
||||
x.report("control") { control(property, item) }
|
||||
x.compare!
|
||||
end
|
||||
0
benchmark/regexp-vs-include.rb
Executable file → Normal file
0
benchmark/regexp-vs-include.rb
Executable file → Normal file
1
benchmark/sequential-assignment
Executable file → Normal file
1
benchmark/sequential-assignment
Executable file → Normal file
@@ -1,4 +1,3 @@
|
||||
#!/usr/bin/env ruby
|
||||
require 'benchmark/ips'
|
||||
|
||||
Benchmark.ips do |x|
|
||||
|
||||
3
benchmark/string-concat
Executable file → Normal file
3
benchmark/string-concat
Executable file → Normal file
@@ -1,7 +1,6 @@
|
||||
#!/usr/bin/env ruby
|
||||
require 'benchmark/ips'
|
||||
|
||||
url = "https://jekyllrb.com"
|
||||
url = "http://jekyllrb.com"
|
||||
|
||||
Benchmark.ips do |x|
|
||||
x.report('+=') { url += '/' }
|
||||
|
||||
1
benchmark/string-replacement
Executable file → Normal file
1
benchmark/string-replacement
Executable file → Normal file
@@ -1,4 +1,3 @@
|
||||
#!/usr/bin/env ruby
|
||||
require 'benchmark/ips'
|
||||
|
||||
def str
|
||||
|
||||
1
benchmark/symbol-to-proc
Executable file → Normal file
1
benchmark/symbol-to-proc
Executable file → Normal file
@@ -1,4 +1,3 @@
|
||||
#!/usr/bin/env ruby
|
||||
require 'benchmark/ips'
|
||||
|
||||
Benchmark.ips do |x|
|
||||
|
||||
@@ -1,10 +1,10 @@
|
||||
#!/usr/bin/env ruby
|
||||
STDOUT.sync = true
|
||||
|
||||
$LOAD_PATH.unshift File.expand_path("../lib", __dir__)
|
||||
$LOAD_PATH.unshift File.join(File.dirname(__FILE__), *%w( .. lib ))
|
||||
|
||||
require "jekyll"
|
||||
require "mercenary"
|
||||
require 'jekyll'
|
||||
require 'mercenary'
|
||||
|
||||
Jekyll::PluginManager.require_from_bundler
|
||||
|
||||
@@ -12,26 +12,22 @@ Jekyll::Deprecator.process(ARGV)
|
||||
|
||||
Mercenary.program(:jekyll) do |p|
|
||||
p.version Jekyll::VERSION
|
||||
p.description "Jekyll is a blog-aware, static site generator in Ruby"
|
||||
p.syntax "jekyll <subcommand> [options]"
|
||||
p.description 'Jekyll is a blog-aware, static site generator in Ruby'
|
||||
p.syntax 'jekyll <subcommand> [options]'
|
||||
|
||||
p.option "source", "-s", "--source [DIR]", "Source directory (defaults to ./)"
|
||||
p.option "destination", "-d", "--destination [DIR]",
|
||||
"Destination directory (defaults to ./_site)"
|
||||
p.option "safe", "--safe", "Safe mode (defaults to false)"
|
||||
p.option "plugins_dir", "-p", "--plugins PLUGINS_DIR1[,PLUGINS_DIR2[,...]]", Array,
|
||||
"Plugins directory (defaults to ./_plugins)"
|
||||
p.option "layouts_dir", "--layouts DIR", String,
|
||||
"Layouts directory (defaults to ./_layouts)"
|
||||
p.option "profile", "--profile", "Generate a Liquid rendering profile"
|
||||
p.option 'source', '-s', '--source [DIR]', 'Source directory (defaults to ./)'
|
||||
p.option 'destination', '-d', '--destination [DIR]', 'Destination directory (defaults to ./_site)'
|
||||
p.option 'safe', '--safe', 'Safe mode (defaults to false)'
|
||||
p.option 'plugins_dir', '-p', '--plugins PLUGINS_DIR1[,PLUGINS_DIR2[,...]]', Array, 'Plugins directory (defaults to ./_plugins)'
|
||||
p.option 'layouts_dir', '--layouts DIR', String, 'Layouts directory (defaults to ./_layouts)'
|
||||
p.option 'profile', '--profile', 'Generate a Liquid rendering profile'
|
||||
|
||||
Jekyll::External.require_if_present(Jekyll::External.blessed_gems) do |g, ver_constraint|
|
||||
cmd = g.split("-").last
|
||||
Jekyll::External.require_if_present(Jekyll::External.blessed_gems) do |g|
|
||||
cmd = g.split('-').last
|
||||
p.command(cmd.to_sym) do |c|
|
||||
c.syntax cmd
|
||||
c.action do
|
||||
Jekyll.logger.abort_with "You must install the '#{g}' gem" \
|
||||
" version #{ver_constraint} to use the 'jekyll #{cmd}' command."
|
||||
Jekyll.logger.abort_with "You must install the '#{g}' gem to use the 'jekyll #{cmd}' command."
|
||||
end
|
||||
end
|
||||
end
|
||||
@@ -1,40 +0,0 @@
|
||||
---
|
||||
layout: error
|
||||
permalink: /404.html
|
||||
sitemap: false
|
||||
---
|
||||
|
||||
<section class="intro">
|
||||
<div class="grid">
|
||||
<div class="unit whole align-center">
|
||||
<p class="first">Huh. It seems that page is<br/>Hyde-ing...</p>
|
||||
</div>
|
||||
</div>
|
||||
</section>
|
||||
|
||||
<section class="error">
|
||||
<div class="grid">
|
||||
<div class="unit whole align-center">
|
||||
<p>The resource you requested was not found. Here are some links to help you find your way:</p>
|
||||
<nav class="main-nav">
|
||||
<ul>
|
||||
<li>
|
||||
<a href="/">Home</a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="/docs/home/">Documentation</a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="/news/">News</a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="/community/">Community</a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="/help/">Help</a>
|
||||
</li>
|
||||
</ul>
|
||||
</nav>
|
||||
</div>
|
||||
</div>
|
||||
</section>
|
||||
@@ -1,167 +0,0 @@
|
||||
- speaker: Ben Balter
|
||||
twitter_handle: BenBalter
|
||||
youtube_id: Z-37y1qaoxc
|
||||
topic: GitHub Pages behind the scenes
|
||||
year: 2015
|
||||
|
||||
- speaker: Brandon Mathis
|
||||
twitter_handle: imathis
|
||||
youtube_id: KS6e4XxY2H4
|
||||
topic: What the heck is Octopress and why should I care?
|
||||
year: 2015
|
||||
|
||||
- speaker: Brian Rinaldi
|
||||
twitter_handle: remotesynth
|
||||
youtube_id: vT7DhK5zbv0
|
||||
topic: Comparing Jekyll with the Competition
|
||||
year: 2015
|
||||
|
||||
- speaker: Kyle Rush
|
||||
twitter_handle: kylerush
|
||||
youtube_id: ia8vsuiXiL0
|
||||
topic: Meet the Obama Campaign's $250 Million Fundraising Platform
|
||||
year: 2015
|
||||
|
||||
- speaker: Michael Jovel
|
||||
twitter_handle: mjovel
|
||||
youtube_id: 8zSHG6XU_xY
|
||||
topic: Building Living Style Guides with Jekyll
|
||||
year: 2015
|
||||
|
||||
- speaker: Mike Neumegen
|
||||
twitter_handle: mikeneumegen
|
||||
youtube_id: NuChR_YdjrI
|
||||
topic: A CMS for Jekyll
|
||||
year: 2015
|
||||
|
||||
- speaker: Parker Moore
|
||||
twitter_handle: parkr
|
||||
youtube_id: y2SbOIQ5nSA
|
||||
topic: Jekyll 3 and Beyond
|
||||
year: 2015
|
||||
|
||||
- speaker: Tom Preston-Werner
|
||||
twitter_handle: mojombo
|
||||
youtube_id: BMve1OCKj6M
|
||||
topic: Some crazy ideas I have for the future of static sites
|
||||
year: 2015
|
||||
|
||||
- speaker: Allison Zadrozny
|
||||
twitter_handle: allizad
|
||||
youtube_id: Rsc0Mmp1qc8
|
||||
topic: Elasticsearch for Jekyll
|
||||
year: 2016
|
||||
|
||||
- speaker: Amy Johnston
|
||||
twitter_handle: amybeukenex
|
||||
youtube_id: HR12JiUI2Zc
|
||||
topic: Jekyll for Technical Documentation
|
||||
year: 2016
|
||||
|
||||
- speaker: Bud Parr
|
||||
twitter_handle: budparr
|
||||
youtube_id: A1nTuNjoNbg
|
||||
topic: Real World Content Strategy with Jekyll
|
||||
year: 2016
|
||||
|
||||
- speaker: George Phillips
|
||||
twitter_handle: gphillips_nz
|
||||
youtube_id: skb_XWABEDc
|
||||
topic: Building client-editable Jekyll sites
|
||||
year: 2016
|
||||
|
||||
- speaker: Ire Aderinokun
|
||||
twitter_handle: ireaderinokun
|
||||
youtube_id: PRKV5IGKF2c
|
||||
topic: Using Jekyll for Rapid CSS Testing
|
||||
year: 2016
|
||||
|
||||
- speaker: Jon Chan
|
||||
twitter_handle: JonHMChan
|
||||
youtube_id: vDeKPs6xpOM
|
||||
topic: Stack Overflow on Jekyll
|
||||
year: 2016
|
||||
|
||||
- speaker: Julio Faerman
|
||||
twitter_handle: jmfaerman
|
||||
youtube_id: SOMonG8Iqak
|
||||
topic: Jekyll on AWS
|
||||
year: 2016
|
||||
|
||||
- speaker: Katy DeCorah
|
||||
twitter_handle: katydecorah
|
||||
youtube_id: s84wFRD8vfE
|
||||
topic: Unconventional use cases for Jekyll
|
||||
year: 2016
|
||||
|
||||
- speaker: David Darnes
|
||||
twitter_handle: DavidDarnes
|
||||
youtube_id: Y4qwpN40Dvg
|
||||
topic: Doing a lot with a little
|
||||
year: 2016
|
||||
|
||||
- speaker: Ronan Berder
|
||||
twitter_handle: hunvreus
|
||||
youtube_id: TteAQq25_Ns
|
||||
topic: Designing fast websites with Jekyll
|
||||
year: 2016
|
||||
|
||||
- speaker: David Von Lehman
|
||||
twitter_handle: davidvlsea
|
||||
youtube_id: wMlPlKCZfEk
|
||||
topic: Continuous deployment of Jekyll sites powered by Docker
|
||||
year: 2016
|
||||
|
||||
- speaker: David Jones
|
||||
twitter_handle: d_jones
|
||||
youtube_id: 4XxYQ7efk0E
|
||||
topic: Building our agency site with Jekyll
|
||||
year: 2016
|
||||
|
||||
- speaker: Scott Hewitt
|
||||
twitter_handle: scotthewitt
|
||||
youtube_id: qSd3pXQaPsE
|
||||
topic: Jekyll For Every Case
|
||||
year: 2016
|
||||
|
||||
- speaker: Tim Carry
|
||||
twitter_handle: pixelastic
|
||||
youtube_id: ivMML1J4ABY
|
||||
topic: Algolia search on Jekyll sites
|
||||
year: 2016
|
||||
|
||||
- speaker: Nils Borchers
|
||||
twitter_handle: nilsborchers
|
||||
youtube_id: DtNMjuv6Rbo
|
||||
topic: Building a living brand guide with Jekyll and Hologram
|
||||
year: 2016
|
||||
|
||||
- speaker: Mike Neumegen
|
||||
twitter_handle: mikeneumegen
|
||||
youtube_id: rJ5EhVmTR7I
|
||||
topic: Learning resources for the Jekyll community
|
||||
year: 2016
|
||||
|
||||
- speaker: Oliver Pattison
|
||||
twitter_handle: olivermakes
|
||||
youtube_id: BIf6oNpGl74
|
||||
topic: Responsive srcset images with imgix
|
||||
year: 2016
|
||||
|
||||
- speaker: Michael Lee
|
||||
twitter_handle: michaelsoolee
|
||||
youtube_id: F4bJRLEvXIc
|
||||
topic: Jekyll, Your Website's Baseplate
|
||||
year: 2016
|
||||
|
||||
- speaker: Paul Webb
|
||||
twitter_handle: NetOpWibby
|
||||
youtube_id: BRB5DgAE5nM
|
||||
topic: Deploy Jekyll Like A Boss
|
||||
year: 2016
|
||||
|
||||
- speaker: Tom Johnson
|
||||
twitter_handle: tomjohnson
|
||||
youtube_id: nq1AUB72GCQ
|
||||
topic: Overcoming challenges in using Jekyll for documentation projects
|
||||
year: 2016
|
||||
@@ -1,11 +0,0 @@
|
||||
- title: Tutorials
|
||||
tutorials:
|
||||
- home
|
||||
- navigation
|
||||
- orderofinterpretation
|
||||
- custom-404-page
|
||||
- convert-site-to-jekyll
|
||||
|
||||
#- title: Another section
|
||||
# tutorials:
|
||||
# - sample
|
||||
@@ -1,62 +0,0 @@
|
||||
---
|
||||
title: "BuddyWorks"
|
||||
---
|
||||
|
||||
[BuddyWorks][buddyworks-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.
|
||||
|
||||
[buddyworks-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](https://buddy.works) 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.
|
||||
|
||||

|
||||
|
||||
[jekyll-docker-image]: https://hub.docker.com/r/jekyll/jekyll/
|
||||
|
||||
## 3. Using YAML for configuration
|
||||
|
||||
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:
|
||||
|
||||
```ruby
|
||||
- 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 BuddyWorks 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].
|
||||
|
||||
[bw-linux]: https://buddy.works/knowledge/standalone/installation-linux
|
||||
[bw-mac]: https://buddy.works/knowledge/standalone/installation-mac-osx
|
||||
[bw-aws-ec2]: https://buddy.works/knowledge/standalone/installation-amazon-ec2
|
||||
[bw-digitalocean]: https://buddy.works/knowledge/standalone/installation-digitalocean
|
||||
[bw-azure]: https://buddy.works/knowledge/standalone/installation-azure
|
||||
|
||||
## 5. Questions?
|
||||
|
||||
This entire guide is open-source. Go ahead and [edit it][jekyll-docs-ci-buddyworks] if you want to expand it or have a fix or [ask for help][jekyll-help] if you run into trouble and need assistance. BuddyWorks also has an [online community][buddyworks-forum] for help.
|
||||
|
||||
[jekyll-docs-ci-buddyworks]: https://github.com/jekyll/jekyll/edit/master/docs/_docs/continuous-integration/buddyworks.md
|
||||
[jekyll-help]: https://jekyllrb.com/help/
|
||||
[buddyworks-forum]: http://forum.buddy.works/
|
||||
@@ -1,92 +0,0 @@
|
||||
---
|
||||
title: "CircleCI"
|
||||
---
|
||||
|
||||
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
|
||||
|
||||
```yaml
|
||||
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.
|
||||
|
||||
```
|
||||
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.
|
||||
|
||||
[5]: https://github.com/gjtorikian/html-proofer
|
||||
[6]: https://github.com/gjtorikian/html-proofer/blob/master/README.md#configuration
|
||||
|
||||
```yaml
|
||||
test:
|
||||
post:
|
||||
- bundle exec htmlproofer ./_site --check-html --disable-external
|
||||
```
|
||||
|
||||
## Complete Example circle.yml File
|
||||
|
||||
When you put it all together, here's an example of what that `circle.yml` file could look like:
|
||||
|
||||
```
|
||||
machine:
|
||||
environment:
|
||||
NOKOGIRI_USE_SYSTEM_LIBRARIES: true # speeds up installation of html-proofer
|
||||
|
||||
dependencies:
|
||||
post:
|
||||
- bundle exec jekyll build
|
||||
|
||||
test:
|
||||
post:
|
||||
- bundle exec htmlproofer ./_site --allow-hash-href --check-favicon --check-html --disable-external
|
||||
|
||||
deployment:
|
||||
prod:
|
||||
branch: master
|
||||
commands:
|
||||
- rsync -va --delete ./_site username@my-website:/var/html
|
||||
```
|
||||
|
||||
## Questions?
|
||||
|
||||
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.
|
||||
|
||||
[7]: https://github.com/jekyll/jekyll/edit/master/docs/_docs/continuous-integration/circleci.md
|
||||
[8]: https://jekyllrb.com/help/
|
||||
[9]: https://discuss.circleci.com
|
||||
@@ -1,10 +0,0 @@
|
||||
---
|
||||
title: Continuous Integration
|
||||
permalink: /docs/continuous-integration/
|
||||
---
|
||||
|
||||
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:
|
||||
|
||||
* [Travis CI](travis-ci)
|
||||
* [CircleCI](circleci)
|
||||
* [BuddyWorks](buddyworks)
|
||||
@@ -1,160 +0,0 @@
|
||||
---
|
||||
title: GitHub Pages
|
||||
permalink: /docs/github-pages/
|
||||
---
|
||||
|
||||
[GitHub Pages](https://pages.github.com) are public web pages for users,
|
||||
organizations, and repositories, that are freely hosted on GitHub's
|
||||
`github.io` domain or on a custom domain name of your choice. GitHub Pages are
|
||||
powered by Jekyll behind the scenes, so in addition to supporting regular HTML
|
||||
content, they’re also a great way to host your Jekyll-powered website for free.
|
||||
|
||||
Never built a website with GitHub Pages before? [See this marvelous guide by
|
||||
Jonathan McGlone to get you up and running](http://jmcglone.com/guides/github-pages/).
|
||||
This guide will teach you what you need to know about Git, GitHub, and Jekyll to create your very own website on GitHub Pages.
|
||||
|
||||
### Project Page URL Structure
|
||||
|
||||
Sometimes it's nice to preview your Jekyll site before you push your `gh-pages`
|
||||
branch to GitHub. However, the subdirectory-like URL structure GitHub uses for
|
||||
Project Pages complicates the proper resolution of URLs. In order to assure your site builds properly, use `site.github.url` in your URLs.
|
||||
|
||||
```html
|
||||
{% raw %}
|
||||
<!-- Useful for styles with static names... -->
|
||||
<link href="{{ site.github.url }}/path/to/css.css" rel="stylesheet">
|
||||
<!-- and for documents/pages whose URLs can change... -->
|
||||
[{{ page.title }}]("{{ page.url | prepend: site.github.url }}")
|
||||
{% endraw %}
|
||||
```
|
||||
|
||||
This way you can preview your site locally from the site root on localhost,
|
||||
but when GitHub generates your pages from the gh-pages branch all the URLs
|
||||
will resolve properly.
|
||||
|
||||
## Deploying Jekyll to GitHub Pages
|
||||
|
||||
GitHub Pages work by looking at certain branches of repositories on GitHub.
|
||||
There are two basic types available: user/organization pages and project pages.
|
||||
The way to deploy these two types of sites are nearly identical, except for a
|
||||
few minor details.
|
||||
|
||||
<div class="note protip" markdown="1">
|
||||
<div markdown="1">
|
||||
</div>
|
||||
|
||||
##### Use the `github-pages` gem
|
||||
|
||||
Our friends at GitHub have provided the
|
||||
[github-pages](https://github.com/github/pages-gem)
|
||||
gem which is used to manage Jekyll and its dependencies on
|
||||
GitHub Pages. Using it in your projects means that when you deploy
|
||||
your site to GitHub Pages, you will not be caught by unexpected
|
||||
differences between various versions of the gems. To use the
|
||||
currently-deployed version of the gem in your project, add the
|
||||
following to your `Gemfile`:
|
||||
|
||||
<div class="code-block" markdown="1">
|
||||
<div markdown="1">
|
||||
</div>
|
||||
|
||||
```ruby
|
||||
source 'https://rubygems.org'
|
||||
|
||||
require 'json'
|
||||
require 'open-uri'
|
||||
versions = JSON.parse(open('https://pages.github.com/versions.json').read)
|
||||
|
||||
gem 'github-pages', versions['github-pages']
|
||||
```
|
||||
</div>
|
||||
|
||||
This will ensure that when you run `bundle install`, you
|
||||
have the correct version of the `github-pages` gem.
|
||||
|
||||
If that fails, simplify it:
|
||||
|
||||
<div class="code-block" markdown="1">
|
||||
<div markdown="1">
|
||||
</div>
|
||||
|
||||
```ruby
|
||||
source 'https://rubygems.org'
|
||||
|
||||
gem 'github-pages'
|
||||
```
|
||||
</div>
|
||||
|
||||
And be sure to run `bundle update` often.
|
||||
|
||||
If you like to install `pages-gem` on Windows you can find instructions by Jens Willmer on
|
||||
[how to install github-pages gem on Windows (x64)](https://jwillmer.de/blog/tutorial/how-to-install-jekyll-and-pages-gem-on-windows-10-x46#github-pages-and-plugins).
|
||||
</div>
|
||||
|
||||
<div class="note info">
|
||||
<h5>Installing <code>github-pages</code> gem on Windows</h5>
|
||||
<p>
|
||||
While Windows is not officially supported, it is possible
|
||||
to install <code>github-pages</code> gem on Windows.
|
||||
Special instructions can be found on our
|
||||
<a href="../windows/#installation">Windows-specific docs page</a>.
|
||||
</p>
|
||||
</div>
|
||||
|
||||
### User and Organization Pages
|
||||
|
||||
User and organization pages live in a special GitHub repository dedicated to
|
||||
only the GitHub Pages files. This repository must be named after the account
|
||||
name. For example, [@mojombo’s user page repository](https://github.com/mojombo/mojombo.github.io) has the name
|
||||
`mojombo.github.io`.
|
||||
|
||||
Content from the `master` branch of your repository will be used to build and
|
||||
publish the GitHub Pages site, so make sure your Jekyll site is stored there.
|
||||
|
||||
<div class="note info">
|
||||
<h5>Custom domains do not affect repository names</h5>
|
||||
<p>
|
||||
GitHub Pages are initially configured to live under the
|
||||
<code>username.github.io</code> subdomain, which is why repositories must
|
||||
be named this way <strong>even if a custom domain is being used</strong>.
|
||||
</p>
|
||||
</div>
|
||||
|
||||
### Project Pages
|
||||
|
||||
Unlike user and organization Pages, Project Pages are kept in the same
|
||||
repository as the project they are for, except that the website content is
|
||||
stored in a specially named `gh-pages` branch or in a `docs` folder on the
|
||||
`master` branch. The content will be rendered using Jekyll, and the output
|
||||
will become available under a subpath of your user pages subdomain, such as
|
||||
`username.github.io/project` (unless a custom domain is specified).
|
||||
|
||||
The Jekyll project repository itself is a perfect example of this branch
|
||||
structure—the [master branch]({{ site.repository }}) contains the
|
||||
actual software project for Jekyll, and the Jekyll website that you’re
|
||||
looking at right now is contained in the [docs
|
||||
folder]({{ site.repository }}/tree/master/docs) of the same repository.
|
||||
|
||||
Please refer to GitHub official documentation on
|
||||
[user, organization and project pages](https://help.github.com/articles/user-organization-and-project-pages/)
|
||||
to see more detailed examples.
|
||||
|
||||
<div class="note warning">
|
||||
<h5>Source Files Must be in the Root Directory</h5>
|
||||
<p>
|
||||
GitHub Pages <a href="https://help.github.com/articles/troubleshooting-github-pages-build-failures#source-setting">overrides</a>
|
||||
the <a href="/docs/configuration/#global-configuration">“Site Source”</a>
|
||||
configuration value, so if you locate your files anywhere other than the
|
||||
root directory, your site may not build correctly.
|
||||
</p>
|
||||
</div>
|
||||
|
||||
<div class="note">
|
||||
<h5>GitHub Pages Documentation, Help, and Support</h5>
|
||||
<p>
|
||||
For more information about what you can do with GitHub Pages, as well as for
|
||||
troubleshooting guides, you should check out
|
||||
<a href="https://help.github.com/categories/github-pages-basics/">GitHub’s Pages Help section</a>.
|
||||
If all else fails, you should contact <a href="https://github.com/contact">GitHub Support</a>.
|
||||
</p>
|
||||
</div>
|
||||
@@ -1,167 +0,0 @@
|
||||
---
|
||||
title: Includes
|
||||
permalink: /docs/includes/
|
||||
---
|
||||
|
||||
The `include` tag allows you to include the content from another file stored in the `_includes` folder:
|
||||
|
||||
```liquid
|
||||
{% raw %}{% 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:
|
||||
|
||||
```liquid
|
||||
{% raw %}{% 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:
|
||||
|
||||
```liquid
|
||||
{% raw %}{% 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:
|
||||
|
||||
```liquid
|
||||
{% raw %}<div markdown="span" class="alert alert-info" role="alert">
|
||||
<i class="fa fa-info-circle"></i> <b>Note:</b>
|
||||
{{ include.content }}
|
||||
</div>{% endraw %}
|
||||
```
|
||||
|
||||
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:
|
||||
|
||||
```liquid
|
||||
{% raw %}{% 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>
|
||||
<a href="http://jekyllrb.com">
|
||||
<img src="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:
|
||||
|
||||
```liquid
|
||||
{% raw %}<figure>
|
||||
<a href="{{ include.url }}">
|
||||
<img src="{{ include.file }}" style="max-width: {{ include.max-width }};"
|
||||
alt="{{ include.alt }}"/>
|
||||
<figcaption>{{ include.caption }}</figcaption>
|
||||
</figure>{% endraw %}
|
||||
```
|
||||
|
||||
This include contains 5 parameters:
|
||||
|
||||
* `url`
|
||||
* `max-width`
|
||||
* `file`
|
||||
* `alt`
|
||||
* `caption`
|
||||
|
||||
Here's an example that passes all the parameters to this include (the include file is named `image.html`):
|
||||
|
||||
```liquid
|
||||
{% raw %}{% include image.html url="http://jekyllrb.com"
|
||||
max-width="200px" file="logo.png" alt="Jekyll logo"
|
||||
caption="This is the Jekyll logo." %} {% endraw %}
|
||||
```
|
||||
|
||||
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://help.shopify.com/themes/liquid/filters/additional-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:
|
||||
|
||||
```liquid
|
||||
{% raw %}{% 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):
|
||||
|
||||
```liquid
|
||||
{% raw %}{% 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:
|
||||
|
||||
```liquid
|
||||
{% raw %}{% 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 %}{% 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`.
|
||||
@@ -1,28 +0,0 @@
|
||||
---
|
||||
title: Affinity Team Captains
|
||||
---
|
||||
|
||||
**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:
|
||||
|
||||
[affinity teams]: https://teams.jekyllrb.com/
|
||||
@@ -1,30 +0,0 @@
|
||||
---
|
||||
title: "Avoiding Burnout"
|
||||
---
|
||||
|
||||
**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 decide to stop using Jekyll and at that point you should also decide not to be 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 a job). We may still ask for your help with questions after you leave but you are under no obligation to answer them. Like a job, 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). Like a job, 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.
|
||||
@@ -1,38 +0,0 @@
|
||||
---
|
||||
title: "Becoming a Maintainer"
|
||||
---
|
||||
|
||||
**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.
|
||||
@@ -1,20 +0,0 @@
|
||||
---
|
||||
title: Maintaining Jekyll
|
||||
permalink: /docs/maintaining/
|
||||
---
|
||||
|
||||
**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.
|
||||
|
||||
1. [Affinity teams & their captains](affinity-team-captain/)
|
||||
2. [Triaging and issue](triaging-an-issue/)
|
||||
3. [Reviewing a pull request](reviewing-a-pull-request/)
|
||||
4. [Merging a pull request](merging-a-pull-request/)
|
||||
5. [Avoiding burnout](avoiding-burnout/)
|
||||
6. [Special Labels](special-labels/)
|
||||
|
||||
Interested in becoming a maintainer? Here is some documentation for **contributors**:
|
||||
|
||||
1. [Becoming a maintainer](becoming-a-maintainer/)
|
||||
@@ -1,55 +0,0 @@
|
||||
---
|
||||
title: "Merging a Pull Request"
|
||||
---
|
||||
|
||||
**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. 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 H3's in the history/changelog 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 (feature, 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:
|
||||
@@ -1,46 +0,0 @@
|
||||
---
|
||||
title: "Reviewing a Pull Request"
|
||||
---
|
||||
|
||||
**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.
|
||||
@@ -1,24 +0,0 @@
|
||||
---
|
||||
title: "Special Labels"
|
||||
---
|
||||
|
||||
**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)
|
||||
@@ -1,54 +0,0 @@
|
||||
---
|
||||
title: "Triaging an Issue"
|
||||
---
|
||||
|
||||
**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).
|
||||
@@ -1,74 +0,0 @@
|
||||
---
|
||||
title: Creating pages
|
||||
permalink: /docs/pages/
|
||||
---
|
||||
|
||||
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
|
||||
and associated URLs might look like:
|
||||
|
||||
```sh
|
||||
.
|
||||
|-- _config.yml
|
||||
|-- _includes/
|
||||
|-- _layouts/
|
||||
|-- _posts/
|
||||
|-- _site/
|
||||
|-- about.html # => http://example.com/about.html
|
||||
|-- index.html # => http://example.com/
|
||||
|-- other.md # => http://example.com/other.html
|
||||
└── contact.html # => http://example.com/contact.html
|
||||
```
|
||||
|
||||
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:
|
||||
|
||||
```
|
||||
---
|
||||
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.
|
||||
@@ -1,367 +0,0 @@
|
||||
---
|
||||
title: Permalinks
|
||||
permalink: /docs/permalinks/
|
||||
---
|
||||
|
||||
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.html`. 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:
|
||||
|
||||
```yaml
|
||||
permalink: /:categories/:year/:month/:day/:title.html
|
||||
```
|
||||
|
||||
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.html`, 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</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
<p><code>month</code></p>
|
||||
</td>
|
||||
<td>
|
||||
<p>Month from the post's filename</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
<p><code>i_month</code></p>
|
||||
</td>
|
||||
<td>
|
||||
<p>Month from the post's filename without leading zeros.</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
<p><code>day</code></p>
|
||||
</td>
|
||||
<td>
|
||||
<p>Day from the post's filename</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
<p><code>i_day</code></p>
|
||||
</td>
|
||||
<td>
|
||||
<p>Day from the post's filename without leading zeros.</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
<p><code>short_year</code></p>
|
||||
</td>
|
||||
<td>
|
||||
<p>Year from the post's filename without the century.</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.
|
||||
|
||||
## Built-in permalink styles {#builtinpermalinkstyles}
|
||||
|
||||
Although you can specify a custom permalink pattern using [template variables](#template-variables), Jekyll also provides the following built-in styles for convenience.
|
||||
|
||||
<div class="mobile-side-scroller">
|
||||
<table>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Permalink Style</th>
|
||||
<th>URL Template</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>
|
||||
<p><code>date</code></p>
|
||||
</td>
|
||||
<td>
|
||||
<p><code>/:categories/:year/:month/:day/:title.html</code></p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
<p><code>pretty</code></p>
|
||||
</td>
|
||||
<td>
|
||||
<p><code>/:categories/:year/:month/:day/:title/</code></p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
<p><code>ordinal</code></p>
|
||||
</td>
|
||||
<td>
|
||||
<p><code>/:categories/:year/:y_day/:title.html</code></p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
<p><code>none</code></p>
|
||||
</td>
|
||||
<td>
|
||||
<p><code>/:categories/:title.html</code></p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</div>
|
||||
|
||||
Rather than typing `permalink: /:categories/:year/:month/:day/:title/`, you can just type `permalink: pretty`.
|
||||
|
||||
<div class="note info">
|
||||
<h5>Specifying permalinks through the YAML Front Matter</h5>
|
||||
<p>Built-in permalink styles are not recognized in YAML Front Matter. As a result, <code>permalink: pretty</code> will not work.</p>
|
||||
</div>
|
||||
|
||||
## Permalink style examples with posts {#permalink-style-examples}
|
||||
|
||||
Here are a few examples to clarify how permalink styles get applied with posts.
|
||||
|
||||
Given a post named: `/2009-04-29-slap-chop.md`
|
||||
|
||||
<div class="mobile-side-scroller">
|
||||
<table>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>URL Template</th>
|
||||
<th>Resulting Permalink URL</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>
|
||||
<p>None specified, or <code>permalink: date</code></p>
|
||||
</td>
|
||||
<td>
|
||||
<p><code>/2009/04/29/slap-chop.html</code></p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
<p><code>pretty</code></p>
|
||||
</td>
|
||||
<td>
|
||||
<p><code>/2009/04/29/slap-chop/</code></p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
<p><code>/:month-:day-:year/:title.html</code></p>
|
||||
</td>
|
||||
<td>
|
||||
<p><code>/04-29-2009/slap-chop.html</code></p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
<p><code>/blog/:year/:month/:day/:title/</code></p>
|
||||
</td>
|
||||
<td>
|
||||
<p><code>/blog/2009/04/29/slap-chop/</code></p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
<p><code>/:year/:month/:title</code></p>
|
||||
<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.html` 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 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:
|
||||
|
||||
```
|
||||
---
|
||||
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.
|
||||
@@ -1,51 +0,0 @@
|
||||
---
|
||||
title: Quick-start guide
|
||||
permalink: /docs/quickstart/
|
||||
---
|
||||
|
||||
|
||||
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
|
||||
~/myblog $ 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 jekyll bundler` installs the [jekyll](https://rubygems.org/gems/jekyll/) and [bundler](https://rubygems.org/gems/bundler) gems through [RubyGems](https://rubygems.org/). You need only to install the gems one time — 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.
|
||||
|
||||
## 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.
|
||||
@@ -1,98 +0,0 @@
|
||||
---
|
||||
title: Static Files
|
||||
permalink: /docs/static-files/
|
||||
---
|
||||
|
||||
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:
|
||||
|
||||
```liquid
|
||||
{% raw %}{% assign image_files = site.static_files | where: "image", true %}
|
||||
{% for myimage in image_files %}
|
||||
{{ myimage.path }}
|
||||
{% endfor %}{% endraw %}
|
||||
```
|
||||
|
||||
When you build your site, the output will list the path to each file that meets this front matter condition.
|
||||
@@ -1,260 +0,0 @@
|
||||
---
|
||||
title: Themes
|
||||
permalink: /docs/themes/
|
||||
---
|
||||
|
||||
Jekyll has an extensive theme system that allows you to leverage community-maintained templates and styles to customize your site's presentation. Jekyll themes package up 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.md
|
||||
└── index.md
|
||||
```
|
||||
|
||||
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:
|
||||
|
||||
```shell
|
||||
# On MacOS
|
||||
open $(bundle show minima)
|
||||
# On Windows
|
||||
explorer /usr/local/lib/ruby/gems/2.3.0/gems/minima-2.1.0
|
||||
```
|
||||
|
||||
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 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 to your site's `Gemfile`:
|
||||
|
||||
```sh
|
||||
gem "jekyll-theme-awesome"
|
||||
```
|
||||
|
||||
2. Install the theme:
|
||||
|
||||
```sh
|
||||
bundle install
|
||||
```
|
||||
|
||||
3. Add the following to your site's `_config.yml` to activate the theme:
|
||||
|
||||
```sh
|
||||
theme: jekyll-theme-awesome
|
||||
```
|
||||
|
||||
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. See [Supported Themes](https://pages.github.com/themes/) in GitHub's documentation to see which themes are supported.
|
||||
|
||||
## 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.
|
||||
|
||||
Here is an example:
|
||||
|
||||
```sh
|
||||
jekyll new-theme jekyll-theme-awesome
|
||||
create /path/to/jekyll-theme-awesome/_layouts
|
||||
create /path/to/jekyll-theme-awesome/_includes
|
||||
create /path/to/jekyll-theme-awesome/_sass
|
||||
create /path/to/jekyll-theme-awesome/_layouts/page.html
|
||||
create /path/to/jekyll-theme-awesome/_layouts/post.html
|
||||
create /path/to/jekyll-theme-awesome/_layouts/default.html
|
||||
create /path/to/jekyll-theme-awesome/Gemfile
|
||||
create /path/to/jekyll-theme-awesome/jekyll-theme-awesome.gemspec
|
||||
create /path/to/jekyll-theme-awesome/README.md
|
||||
create /path/to/jekyll-theme-awesome/LICENSE.txt
|
||||
initialize /path/to/jekyll-theme-awesome/.git
|
||||
create /path/to/jekyll-theme-awesome/.gitignore
|
||||
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.
|
||||
|
||||
```css
|
||||
{% raw %}@import "{{ site.theme }}";{% endraw %}
|
||||
```
|
||||
|
||||
### Theme-gem dependencies
|
||||
|
||||
From `v3.5`, Jekyll will automatically require all whitelisted `runtime_dependencies` of your theme-gem even if they're not explicitly included under the `gems` 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 programatically. 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.
|
||||
@@ -1,218 +0,0 @@
|
||||
---
|
||||
title: Jekyll on Windows
|
||||
permalink: /docs/windows/
|
||||
---
|
||||
|
||||
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
|
||||
|
||||
If you are using Windows 10 Anniversary Update, the easiest way to run Jekyll is by [installing][WSL-Guide] the new Bash on Ubuntu on Windows.
|
||||
|
||||
|
||||
### Installation via Bash on Windows 10
|
||||
|
||||
*Note:* You must have [Bash on Ubuntu on Windows][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:
|
||||
|
||||
```
|
||||
bash
|
||||
```
|
||||
Your Command Prompt instance should now be a Bash instance. Now we must update our repo lists and packages.
|
||||
|
||||
```
|
||||
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.
|
||||
|
||||
```
|
||||
sudo apt-add-repository ppa:brightbox/ruby-ng
|
||||
sudo apt-get update
|
||||
sudo apt-get install ruby2.3 ruby2.3-dev build-essential
|
||||
```
|
||||
|
||||
Next let's update our Ruby gems:
|
||||
|
||||
```
|
||||
sudo gem update
|
||||
```
|
||||
|
||||
Now all that is left to do is install Jekyll.
|
||||
|
||||
```
|
||||
sudo gem install jekyll bundler
|
||||
```
|
||||
|
||||
Check if Jekyll installed properly by running:
|
||||
|
||||
```
|
||||
jekyll -v
|
||||
```
|
||||
|
||||
**And that's it!**
|
||||
|
||||
To start a new project named `my_blog`, just run:
|
||||
|
||||
```
|
||||
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.
|
||||
|
||||
**Note:** Bash on Ubuntu on Windows is still under development, so you may run into issues.
|
||||
|
||||
|
||||
[WSL-Guide]: https://msdn.microsoft.com/en-us/commandline/wsl/install_guide
|
||||
[BASH-WSL]: https://msdn.microsoft.com/en-us/commandline/wsl/about
|
||||
|
||||
|
||||
### Installation via RubyInstaller
|
||||
|
||||
[RubyInstaller][] is a self-contained Windows-based installer that includes the Ruby language, an execution environment, important documentation, and more.
|
||||
|
||||
1. Download and Install a package manager version from [RubyInstaller Downloads][RubyInstaller-downloads].
|
||||
2. Install Jekyll and Bundler via a command prompt window: `gem install jekyll bundler`
|
||||
3. Check if Jekyll installed properly: `jekyll -v`
|
||||
|
||||
[RubyInstaller]: https://rubyinstaller.org/
|
||||
[RubyInstaller-downloads]: https://rubyinstaller.org/downloads/
|
||||
|
||||
|
||||
### Installation via Chocolatey
|
||||
|
||||
A quick way to install Jekyll using Chocolatey is to follow the [installation instructions by David Burela](https://davidburela.wordpress.com/2015/11/28/easily-install-jekyll-on-windows-with-3-command-prompt-entries-and-chocolatey/):
|
||||
|
||||
1. Install a package manager for Windows called [Chocolatey][]
|
||||
2. Install Ruby via Chocolatey: `choco install ruby -y`
|
||||
3. Reopen a command prompt and install Jekyll: `gem install jekyll`
|
||||
|
||||
Updates in the infrastructure of Ruby may cause SSL errors when attempting to use `gem install` with versions of the RubyGems package older than 2.6. (The RubyGems package installed via the Chocolatey tool is version 2.3) If you have installed an older version, you can update the RubyGems package using the directions [here][ssl-certificate-update].
|
||||
|
||||
[ssl-certificate-update]: http://guides.rubygems.org/ssl-certificate-update/#installing-using-update-packages
|
||||
|
||||
|
||||
### Installing *github-pages* via Chocolatey
|
||||
|
||||
This section is part of an article written by [Jens Willmer][jwillmerPost]. To follow the instructions you need to have [Chocolatey][] installed on your system. If you already have a version of Ruby installed you need to uninstall it before you can continue.
|
||||
|
||||
|
||||
#### Install Ruby and Ruby development kit
|
||||
|
||||
Open a command prompt and execute the following commands:
|
||||
|
||||
* `choco install ruby -version 2.2.4`
|
||||
* `choco install ruby2.devkit` - _needed for compilation of json gem_
|
||||
|
||||
|
||||
#### Configure Ruby development kit
|
||||
|
||||
The development kit did not set the environment path for Ruby so we need to do it.
|
||||
|
||||
* Open command prompt in `C:\tools\DevKit2`
|
||||
* Execute `ruby dk.rb init` to create a file called `config.yml`
|
||||
* Edit the `config.yml` file and include the path to Ruby `- C:/tools/ruby22`
|
||||
* Execute the following command to set the path: `ruby dk.rb install`
|
||||
|
||||
|
||||
#### Nokogiri gem installation
|
||||
|
||||
This gem is also needed in the github-pages and to get it running on Windows x64 we have to install a few things.
|
||||
|
||||
**Note:** In the current [pre release][nokogiriFails] it works out of the box with Windows x64 but this version is not referenced in the github-pages.
|
||||
|
||||
`choco install libxml2 -Source "https://www.nuget.org/api/v2/"`{:.language-ruby}
|
||||
|
||||
`choco install libxslt -Source "https://www.nuget.org/api/v2/"`{:.language-ruby}
|
||||
|
||||
`choco install libiconv -Source "https://www.nuget.org/api/v2/"`{:.language-ruby}
|
||||
|
||||
```ruby
|
||||
gem install nokogiri --^
|
||||
--with-xml2-include=C:\Chocolatey\lib\libxml2.2.7.8.7\build\native\include^
|
||||
--with-xml2-lib=C:\Chocolatey\lib\libxml2.redist.2.7.8.7\build\native\bin\v110\x64\Release\dynamic\cdecl^
|
||||
--with-iconv-include=C:\Chocolatey\lib\libiconv.1.14.0.11\build\native\include^
|
||||
--with-iconv-lib=C:\Chocolatey\lib\libiconv.redist.1.14.0.11\build\native\bin\v110\x64\Release\dynamic\cdecl^
|
||||
--with-xslt-include=C:\Chocolatey\lib\libxslt.1.1.28.0\build\native\include^
|
||||
--with-xslt-lib=C:\Chocolatey\lib\libxslt.redist.1.1.28.0\build\native\bin\v110\x64\Release\dynamic
|
||||
```
|
||||
|
||||
#### Install github-pages
|
||||
|
||||
* Open command prompt and install [Bundler][]: `gem install bundler`
|
||||
* Create a file called `Gemfile` without any extension in your root directory of your blog
|
||||
* Copy & paste the two lines into the file:
|
||||
|
||||
|
||||
```ruby
|
||||
source 'https://rubygems.org'
|
||||
gem 'github-pages', group: :jekyll_plugins
|
||||
```
|
||||
|
||||
* **Note:** We use an unsecure connection because SSL throws exceptions in the version of Ruby
|
||||
* Open a command prompt, target your local blog repository root, and install github-pages: `bundle install`
|
||||
|
||||
|
||||
After this process you should have github-pages installed on your system and you can host your blog again with `jekyll s`.
|
||||
There will be a warning on startup that you should include `gem 'wdm', '>= 0.1.0' if Gem.win_platform?` to your `Gemfile` but I could not get `jekyll s` working if I include that line so for the moment I ignore that warning.
|
||||
|
||||
In the future the installation process of the github-pages should be as simple as the setup of the blog. But as long as the new version of the Nokogiri ([v1.6.8][nokogiriReleases]) is not stable and referenced, it is work to get it up and running on Windows.
|
||||
|
||||
[jwillmerPost]: https://jwillmer.de/blog/tutorial/how-to-install-jekyll-and-pages-gem-on-windows-10-x46 "Installation instructions by Jens Willmer"
|
||||
[Chocolatey]: https://chocolatey.org/install "Package manager for Windows"
|
||||
[nokogiriFails]: https://github.com/sparklemotion/nokogiri/issues/1456#issuecomment-206481794 "Nokogiri fails to install on Ruby 2.3 for Windows"
|
||||
[Bundler]: http://bundler.io/ "Ruby Dependencie Manager"
|
||||
[nokogiriReleases]: https://github.com/sparklemotion/nokogiri/releases "Nokogiri Releases"
|
||||
|
||||
---
|
||||
|
||||
For a more conventional way of installing Jekyll you can follow this [complete guide to install Jekyll 3 on Windows by Sverrir Sigmundarson][windows-installjekyll3].
|
||||
|
||||
Optionally you can use [Autoinstall Jekyll for Windows][fastjekyll-autoinstall].
|
||||
|
||||
---
|
||||
|
||||
[windows-installjekyll3]: https://labs.sverrirs.com/jekyll/
|
||||
[fastjekyll-autoinstall]: https://github.com/KeJunMao/fastjekyll#autoinstall-jekyll-for-windows
|
||||
|
||||
|
||||
## Encoding
|
||||
|
||||
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
|
||||
gem 'tzinfo-data', platforms: [:mingw, :mswin, :x64_mingw, :jruby]
|
||||
```
|
||||
|
||||
[IANA-database]: https://en.wikipedia.org/wiki/List_of_tz_database_time_zones
|
||||
|
||||
|
||||
## Auto Regeneration
|
||||
|
||||
As of v1.3.0, 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' if Gem.win_platform?
|
||||
```
|
||||
|
||||
You may first have to download and install the [Ruby DevKit](https://rubyinstaller.org/downloads/) by following [the instructions here](https://github.com/oneclick/rubyinstaller/wiki/Development-Kit).
|
||||
@@ -1,5 +0,0 @@
|
||||
{% for item in include.items %}
|
||||
{% assign item_url = item | prepend:"/docs/" | append:"/" %}
|
||||
{% assign doc = site.docs | where: "url", item_url | first %}
|
||||
<option value="{{ doc.url }}">{{ doc.title }}</option>
|
||||
{% endfor %}
|
||||
@@ -1,7 +0,0 @@
|
||||
<ul>
|
||||
{% for item in include.items %}
|
||||
{% assign item_url = item | prepend:"/docs/" | append:"/" %}
|
||||
{% assign p = site.docs | where:"url", item_url | first %}
|
||||
<li class="{% if item_url == page.url %}current{% endif %}"><a href="{{ p.url }}">{{ p.title }}</a></li>
|
||||
{% endfor %}
|
||||
</ul>
|
||||
@@ -1,39 +0,0 @@
|
||||
{% comment %}
|
||||
Map grabs the tutorials sections, giving us an array of arrays. Join, flattens all
|
||||
the items to a comma delimited string. Split turns it into an array again.
|
||||
{% endcomment %}
|
||||
{% assign tutorials = site.data.tutorials | map: 'tutorials' | join: ',' | split: ',' %}
|
||||
|
||||
{% comment %}
|
||||
Because this is built for every page, lets find where we are in the ordered
|
||||
document list by comparing url strings. Then if there's something previous or
|
||||
next, lets build a link to it.
|
||||
{% endcomment %}
|
||||
|
||||
{% for tutorial in tutorials %}
|
||||
{% assign tutorial_url = tutorial | prepend:"/tutorials/" | append:"/" %}
|
||||
{% if tutorial_url == page.url %}
|
||||
<div class="section-nav">
|
||||
<div class="left align-right">
|
||||
{% if forloop.first %}
|
||||
<span class="prev disabled">Back</span>
|
||||
{% else %}
|
||||
{% assign previous = forloop.index0 | minus: 1 %}
|
||||
{% assign previous_page = tutorials[previous] | prepend:"/tutorials/" | append:"/" %}
|
||||
<a href="{{ previous_page }}" class="prev">Back</a>
|
||||
{% endif %}
|
||||
</div>
|
||||
<div class="right align-left">
|
||||
{% if forloop.last %}
|
||||
<span class="next disabled">Next</span>
|
||||
{% else %}
|
||||
{% assign next = forloop.index0 | plus: 1 %}
|
||||
{% assign next_page = tutorials[next] | prepend:"/tutorials/" | append:"/" %}
|
||||
<a href="{{ next_page }}" class="next">Next</a>
|
||||
{% endif %}
|
||||
</div>
|
||||
</div>
|
||||
<div class="clear"></div>
|
||||
{% break %}
|
||||
{% endif %}
|
||||
{% endfor %}
|
||||
@@ -1,10 +0,0 @@
|
||||
<div class="unit one-fifth hide-on-mobiles">
|
||||
<aside>
|
||||
{% for section in site.data.tutorials %}
|
||||
<h4>{{ section.title }}</h4>
|
||||
|
||||
{% include tutorials_ul.html items=section.tutorials %}
|
||||
|
||||
{% endfor %}
|
||||
</aside>
|
||||
</div>
|
||||
@@ -1,10 +0,0 @@
|
||||
<div class="docs-nav-mobile unit whole show-on-mobiles">
|
||||
<select onchange="if (this.value) window.location.href=this.value">
|
||||
<option value="">Navigate the tutorials…</option>
|
||||
{% for section in site.data.tutorials %}
|
||||
<optgroup label="{{ section.title }}">
|
||||
{% include tutorials_option.html items=section.tutorials %}
|
||||
</optgroup>
|
||||
{% endfor %}
|
||||
</select>
|
||||
</div>
|
||||
@@ -1,5 +0,0 @@
|
||||
{% for item in include.items %}
|
||||
{% assign item_url = item | prepend:"/tutorials/" | append:"/" %}
|
||||
{% assign tutorial = site.tutorials | where: "url", item_url | first %}
|
||||
<option value="{{ tutorial.url }}">{{ tutorial.title }}</option>
|
||||
{% endfor %}
|
||||
@@ -1,7 +0,0 @@
|
||||
<ul>
|
||||
{% for item in include.items %}
|
||||
{% assign item_url = item | prepend:"/tutorials/" | append:"/" %}
|
||||
{% assign p = site.tutorials | where:"url", item_url | first %}
|
||||
<li class="{% if item_url == page.url %}current{% endif %}"><a href="{{ p.url }}">{{ p.title }}</a></li>
|
||||
{% endfor %}
|
||||
</ul>
|
||||
@@ -1,23 +0,0 @@
|
||||
{% include top.html %}
|
||||
|
||||
<body class="wrap">
|
||||
<header>
|
||||
<div class="grid">
|
||||
<div class="unit whole align-center">
|
||||
<h1>
|
||||
<a href="/">
|
||||
<span class="sr-only">Jekyll</span>
|
||||
<img src="/img/logo-2x.png" width="249" height="115" alt="Jekyll Logo">
|
||||
</a>
|
||||
</h1>
|
||||
</div>
|
||||
</div>
|
||||
</header>
|
||||
|
||||
{{ content }}
|
||||
|
||||
{% include anchor_links.html %}
|
||||
{% include analytics.html %}
|
||||
|
||||
</body>
|
||||
</html>
|
||||
@@ -1,27 +0,0 @@
|
||||
---
|
||||
layout: default
|
||||
---
|
||||
|
||||
<section class="docs">
|
||||
<div class="grid">
|
||||
|
||||
{% include tutorials_contents_mobile.html %}
|
||||
|
||||
<div class="unit four-fifths">
|
||||
<article>
|
||||
<div class="improve right hide-on-mobiles">
|
||||
<a href="https://github.com/jekyll/jekyll/edit/master/docs/{{ page.path }}"><i
|
||||
class="fa fa-pencil"></i> Improve this page</a>
|
||||
</div>
|
||||
<h1>{{ page.title }}</h1>
|
||||
{{ content }}
|
||||
{% include section_nav_tutorials.html %}
|
||||
</article>
|
||||
</div>
|
||||
|
||||
{% include tutorials_contents.html %}
|
||||
|
||||
<div class="clear"></div>
|
||||
|
||||
</div>
|
||||
</section>
|
||||
@@ -1,23 +0,0 @@
|
||||
---
|
||||
title: 'Jekyll 3.0.4 Released'
|
||||
date: 2016-04-19 10:26:12 -0700
|
||||
author: parkr
|
||||
version: 3.0.4
|
||||
categories: [release]
|
||||
---
|
||||
|
||||
v3.0.4 is a patch release which fixes the follow two issues:
|
||||
|
||||
- Front matter defaults may not have worked for collection documents and posts due to a problem where they were looked up by their URL rather than their path relative to the site source
|
||||
- Configuration for the posts permalink might be borked when a user specified a value for `collections.posts.permalink` directly. This forced the use of `permalink` at the top level, which also affected pages. To configure a permalink _just for posts_, you can do so with:
|
||||
|
||||
{% highlight yaml %}
|
||||
collections:
|
||||
posts:
|
||||
output: true
|
||||
permalink: /blog/:year/:title/
|
||||
{% endhighlight %}
|
||||
|
||||
Both of these issues have been resolved. For more information, check out [the full history](/docs/history/#v3-0-4).
|
||||
|
||||
Happy Jekylling!
|
||||
@@ -1,16 +0,0 @@
|
||||
---
|
||||
title: 'Jekyll 3.1.3 Released'
|
||||
date: 2016-04-19 10:26:16 -0700
|
||||
author: parkr
|
||||
version: 3.1.3
|
||||
categories: [release]
|
||||
---
|
||||
|
||||
v3.1.3 is a patch release which fixes the follow two issues:
|
||||
|
||||
- Front matter defaults may not have worked for collection documents and posts due to a problem where they were looked up by their URL rather than their path relative to the site source
|
||||
- Running `jekyll serve` with SSL enabled was broken due to a bad configuration.
|
||||
|
||||
Both of these issues have been resolved. For more information, check out [the full history](/docs/history/#v3-1-3).
|
||||
|
||||
Happy Jekylling!
|
||||
@@ -1,24 +0,0 @@
|
||||
---
|
||||
title: 'Jekyll 3.0.5 Released'
|
||||
date: 2016-04-26 17:40:44 -0700
|
||||
author: parkr
|
||||
version: 3.0.5
|
||||
categories: [release]
|
||||
---
|
||||
|
||||
This version fixes a bug affecting only v3.0.4 where autoregeneration was
|
||||
*always* disabled when running Jekyll locally. This feature is a huge
|
||||
reason why Jekyll (or any static site generator, for that matter) is a joy
|
||||
to use. Sorry for the regression!
|
||||
|
||||
If you're using GitHub Pages, [you can follow the progress of the upgrade
|
||||
on the github/pages-gem repo](https://github.com/github/pages-gem/pull/285).
|
||||
|
||||
As always, our [history doc](/docs/history/#v3-0-5) has links to the pull
|
||||
requests and issues associated with the release for your perusal.
|
||||
|
||||
We're looking forward to the upcoming release of v3.2 which [has some
|
||||
excellent goodies](https://github.com/jekyll/jekyll/blob/master/History.markdown#head)
|
||||
we think you'll love.
|
||||
|
||||
Happy Jekylling!
|
||||
@@ -1,25 +0,0 @@
|
||||
---
|
||||
title: 'Jekyll 3.1.4 "Stability Sam" Released'
|
||||
date: 2016-05-18 16:50:37 -0700
|
||||
author: parkr
|
||||
version: 3.1.4
|
||||
categories: [release]
|
||||
---
|
||||
|
||||
Hey Jekyllites!
|
||||
|
||||
Today, we released v3.1.4 in an effort to bring more stability to the v3.1.x series. This bugfix release consists of:
|
||||
|
||||
* A fix for `layout` in Liquid where values would carry over from one document to the next
|
||||
* A fix for `layout` in Liquid where a parent layout (e.g. `default` or `base`) would overwrite the metadata of the child layout (e.g. `post` or `special`).
|
||||
* A fix where `page.excerpt` referencing its excerpt would cause an infinite loop of recursive horror.
|
||||
* We added `Configuration.from` and the great permalink fix from [v3.0.4](/news/2016/04/19/jekyll-3-0-4-released/) to the v3.1.x series
|
||||
* `site.collections` in Liquid is now sorted alphabetically by label, so `docs` shows up before `posts` reliably.
|
||||
|
||||
The fixes for `layout` may not be seamless for everyone, but we believe they will be the "right thing to do" going forward.
|
||||
|
||||
We are alwawys striving to make Jekyll more straight-forward to use. Please do open an issue if you believe an aspect of Jekyll's user experience isn't up to par.
|
||||
|
||||
For a full history of our changes, [see the changelog](/docs/history/#v3-1-4).
|
||||
|
||||
As always, Happy Jekylling!
|
||||
@@ -1,16 +0,0 @@
|
||||
---
|
||||
title: 'Jekyll 3.1.5 Released'
|
||||
date: 2016-05-18 21:35:27 -0700
|
||||
author: parkr
|
||||
version: 3.1.5
|
||||
categories: [release]
|
||||
---
|
||||
|
||||
There's always at least one bug, right? :)
|
||||
|
||||
Hot on the trails of [v3.1.4](/news/2016/05/18/jekyll-3-1-4-released/), we
|
||||
bring you v3.1.5! It fixes one bug around requiring the `ExcerptDrop`,
|
||||
which only affects Linux. For the gory details, see [the pull
|
||||
request for the fix](https://github.com/jekyll/jekyll/pull/4912).
|
||||
|
||||
Happy Jekylling!
|
||||
@@ -1,18 +0,0 @@
|
||||
---
|
||||
title: 'Jekyll 3.1.6 Released'
|
||||
date: 2016-05-19 12:48:14 -0700
|
||||
author: parkr
|
||||
version: 3.1.6
|
||||
categories: [release]
|
||||
---
|
||||
|
||||
Upon releasing 3.1.5 and kicking the tires, we noticed a glaring bug: our
|
||||
beloved `jsonify` filter doesn't work! With that, our work was cut out for
|
||||
us and we decided a 3.1.6 was necessary. This release restores sanity to
|
||||
our object-to-JSON generation in Liquid and we hope you enjoy.
|
||||
|
||||
For the gory details, see [the pull
|
||||
request](https://github.com/jekyll/jekyll/pull/4914) or [the
|
||||
changelog](/docs/history/#v3-1-6).
|
||||
|
||||
Happy Jekylling!
|
||||
@@ -1,18 +0,0 @@
|
||||
---
|
||||
title: "Jekyll's Google Summer of Code Project: The CMS You Always Wanted"
|
||||
date: "2016-06-03 13:21:02 -0700"
|
||||
author: parkr
|
||||
categories: [community]
|
||||
---
|
||||
|
||||
This year, Jekyll applied to be a part of [Google Summer of Code](https://summerofcode.withgoogle.com/how-it-works/). Students were able to propose any project related to Jekyll. With a gracious sponsorship from GitHub and the participation of myself, @benbalter and @jldec, Jekyll was able to accept two students for the 2016 season, @mertkahyaoglu and @rush-skills.
|
||||
|
||||
These students are working on a project that fills a huge need for the community: _a graphical solution for managing your site's content._ Current plans include a fully-integrated admin which spins up when you run jekyll serve and provides a friendly web interface for creating and editing your content. The server and web interface will speak a common HTTP interface so either piece could be switched out for, e.g. a server which writes directly to a repository on GitHub.
|
||||
|
||||
The strength of text files as the storage medium for content has been part of Jekyll's success. [Our homepage](/) lauds the absence of a traditional SQL database when using Jekyll – your content should be what demands your time, not pesky database downtime. Unfortunately, understanding of the structure of a Jekyll site takes some work, enough that for some users, it's prohibitive to using Jekyll to accomplish their publishing goals.
|
||||
|
||||
Mert and Ankur both applied to take on this challenge and agreed to split the project, one taking on the web interface and the other taking on the backend. We're very excited to see a fully-functional CMS for Jekyll at the end of the summer produced by these excellent community members, and we hope you'll join us in cheering them on and sharing our gratitude for all their hard work.
|
||||
|
||||
Thanks, as always, for being part of such a wonderful community that made this all possible. I'm honored to work with each of you to create something folks all around the globe find a joy to use. I look forward to our continued work to move Jekyll forward.
|
||||
|
||||
As always, Happy Jekylling!
|
||||
@@ -1,124 +0,0 @@
|
||||
---
|
||||
title: 'Jekyll turns 3.2'
|
||||
date: 2016-07-26 15:06:49 -0700
|
||||
author: parkr
|
||||
version: 3.2.0
|
||||
categories: [release]
|
||||
---
|
||||
|
||||
Happy Day! Jekyll v3.2.0 is out, and packed full of goodies.
|
||||
|
||||
Our flagship feature for this release has been **themes**. _Themes?!_, you
|
||||
say? Yes, proper, versionable, releasable, first-class themes. We're pretty
|
||||
stoked about it and we hope you like building and using them. For now, it
|
||||
only supports layouts, includes, and sass, but we have plans to include
|
||||
static assets like images and CSS/JS in a future release. [Read more about
|
||||
it in the docs.](/docs/themes/) Our site template generated by `jekyll new`
|
||||
now dogfoods this feature, using the [minima](https://github.com/jekyll/minima) theme.
|
||||
|
||||
Some other notable changes:
|
||||
|
||||
- Symlinks are allowed as long as they target a file in the site source
|
||||
- Explicit support for Ruby 2.0.x was dropped
|
||||
- Added an `:after_init` Hook
|
||||
- Added a `where_exp` filter to provide more powerful filtering
|
||||
- Added a `link` liquid tag which can be used to generate URLs for any
|
||||
post or document based on its path relative to the site source
|
||||
- ... and lots more!
|
||||
|
||||
As always, there is [a full list of changes](/docs/history/#v3-2-0) for
|
||||
your perusal.
|
||||
|
||||
Every release is made possible by the countless hours of hard work that our
|
||||
fellow community members put into sending patches, filing thoughtful
|
||||
patches, and so on. These release took the work of over 80 people:
|
||||
|
||||
- Aaron Sky
|
||||
- Adam Hollett
|
||||
- ajhit406
|
||||
- Aki
|
||||
- Alex Hanselka
|
||||
- Alex Hoyau
|
||||
- Alex Ivkin
|
||||
- Alex Kitchens
|
||||
- Alex Plescan
|
||||
- Alex Wood
|
||||
- Anatoliy Yastreb
|
||||
- Andrew Artajos
|
||||
- Andrew Munsell
|
||||
- AndrewCz
|
||||
- Ankush Menat
|
||||
- Anthony Smith
|
||||
- Ben Balter
|
||||
- Brian Jones
|
||||
- Brint O'Hearn
|
||||
- Chayoung You
|
||||
- Chris Wells
|
||||
- chrisfinazzo
|
||||
- Clark Winkelmann
|
||||
- Dan Allen
|
||||
- David Von Lehman
|
||||
- David Zhang
|
||||
- Derek Gottlieb
|
||||
- Enes Gönültaş
|
||||
- EricH
|
||||
- Erick Sasse
|
||||
- Eugênio Cabral
|
||||
- Florian Thomas
|
||||
- Frank Taillandier
|
||||
- Henry Goodman
|
||||
- Henry Wright
|
||||
- Hugo Duksis
|
||||
- Hugo Giraudel
|
||||
- Jack Reed
|
||||
- Jamie Bilinski
|
||||
- Jeff Kolesky
|
||||
- Jens Willmer
|
||||
- Jordon Bedwell
|
||||
- Josh Waller
|
||||
- Joshua Barnett
|
||||
- Keegan Mullaney
|
||||
- Kevin Miller
|
||||
- Krzysztof Jurewicz
|
||||
- Loren Rogers
|
||||
- Marcos Brito
|
||||
- Marcus Stollsteimer
|
||||
- Matt Rogers
|
||||
- Michaël Guitton
|
||||
- Mike Linksvayer
|
||||
- Mike Neumegen
|
||||
- Nathan Hazout
|
||||
- Nick
|
||||
- No
|
||||
- nscyclone
|
||||
- Parker Moore
|
||||
- Pat Hawks
|
||||
- Pierre Fenoll
|
||||
- Praveen Kumar
|
||||
- Rares Vernica
|
||||
- Saleem Rashid
|
||||
- Sam Dutton
|
||||
- Shengbin Meng
|
||||
- Shinn Kondo
|
||||
- Shinnosuke Kondo
|
||||
- skim
|
||||
- Sondre Nilsen
|
||||
- Spencer A. Bywater
|
||||
- Stephen Checkoway
|
||||
- Suriyaa Kudo
|
||||
- surrim
|
||||
- TheLucasMoore
|
||||
- Thomas Wood
|
||||
- Tim Wisniewski
|
||||
- Tom Fejfar
|
||||
- Tony Garnock-Jones
|
||||
- Vincent Wochnik
|
||||
- XhmikosR
|
||||
- Yanis Vieilly
|
||||
- Yordis Prieto
|
||||
- Zack Spencer
|
||||
|
||||
We are so grateful to all of you for helping to put together a terrific
|
||||
release. Thank you!
|
||||
|
||||
Happy Jekylling!
|
||||
@@ -1,23 +0,0 @@
|
||||
---
|
||||
title: 'Jekyll 3.2.1 Released with Fix for Windows'
|
||||
date: 2016-08-02 13:20:11 -0700
|
||||
author: parkr
|
||||
version: 3.2.1
|
||||
categories: [release]
|
||||
---
|
||||
|
||||
Well, 3.2.0 has been a success, but with one fatal flaw: it doesn't work on
|
||||
Windows! Sorry, Windows users. Hot on the trail of 3.2.0, this release
|
||||
should squash that :bug:. Sorry about that!
|
||||
|
||||
This release also fixes an issue when using [gem-based themes](/docs/themes/)
|
||||
where the theme was rejected if it existed behind a symlink. This is a
|
||||
common setup for the various ruby version managers, and for Ruby installed
|
||||
via Homebrew. Props to @benbalter for fixing that up.
|
||||
|
||||
Thanks to the contributors for this release: Adam Petrie, Ben Balter,
|
||||
Daniel Chapman, DirtyF, Gary Ewan Park, Jordon Bedwell, and Parker Moore.
|
||||
|
||||
As always, you can see our full changelog on [the History page](/docs/history/).
|
||||
|
||||
Happy Jekylling!
|
||||
@@ -1,17 +0,0 @@
|
||||
---
|
||||
title: "Jekyll Admin Initial Release"
|
||||
date: "2016-08-25 09:50:00 +0300"
|
||||
author: mertkahyaoglu
|
||||
categories: [community]
|
||||
---
|
||||
|
||||
[Jekyll's Google Summer of Code Project](https://jekyllrb.com/news/2016/06/03/update-on-jekyll-s-google-summer-of-code-projects/) has concluded. After three months of hard (but fun) work with my mentors @benbalter, @jldec, and @parkr, I'm proud to announce [Jekyll Admin](https://github.com/jekyll/jekyll-admin)'s [initial release](https://github.com/jekyll/jekyll-admin/releases/tag/v0.1.0). Jekyll admin is a Jekyll plugin that provides users with a traditional CMS-style graphical interface to author content and administer Jekyll sites. You can start to use it right away by following [these instructions](https://github.com/jekyll/jekyll-admin#installation).
|
||||
|
||||
As a Google Summer of Code student, I feel very lucky to be part of a project that the community has been wanting for such a long time. The three-month Google Summer of Code period was a great journey. It was a lot of fun developing the project and seeing how it could help the community, and going forward, we are really excited to see where the project goes with the help of the amazing Jekyll community.
|
||||
|
||||
I would like to thank my mentors who embraced me as their teammate and guided me throughout the process. They have put a lot of work and time to mentor me and helped me with everything. It was a great pleasure to work with them. I also would like to thank the wonderful Jekyll community for making Jekyll what it is today. It was amazing to see the community contribute to the project and give their feedback
|
||||
prior to its release. I'm sure that they will support Jekyll Admin as much as they can and move Jekyll even further.
|
||||
|
||||
Please let us know what you think about [Jekyll Admin](https://github.com/jekyll/jekyll-admin) and feel free to [contribute](https://github.com/jekyll/jekyll-admin/blob/master/.github/CONTRIBUTING.md). Your feedback and contributions are greatly appreciated.
|
||||
|
||||
Happy (graphical) Jekylling!
|
||||
@@ -1,109 +0,0 @@
|
||||
---
|
||||
title: 'Jekyll 3.3 is here with better theme support, new URL filters, and tons more'
|
||||
date: 2016-10-06 11:10:38 -0700
|
||||
author: parkr
|
||||
version: 3.3.0
|
||||
categories: [release]
|
||||
---
|
||||
|
||||
There are tons of great new quality-of-life features you can use in 3.3.
|
||||
Three key things you might want to try:
|
||||
|
||||
### 1. Themes can now ship static & dynamic assets in an `/assets` directory
|
||||
|
||||
In Jekyll 3.2, we shipped the ability to use a theme that was packaged as a
|
||||
[gem](http://guides.rubygems.org/). 3.2 included support for includes,
|
||||
layouts, and sass partials. In 3.3, we're adding assets to that list.
|
||||
|
||||
In an effort to make theme management a bit easier, any files you put into
|
||||
`/assets` in your theme will be read in as though they were part of the
|
||||
user's site. This means you can ship SCSS and CoffeeScript, images and
|
||||
webfonts, and so on -- anything you'd consider a part of the
|
||||
*presentation*. Same rules apply here as in a Jekyll site: if it has YAML
|
||||
front matter, it will be converted and rendered. No YAML front matter, and
|
||||
it will simply be copied over like a static asset.
|
||||
|
||||
Note that if a user has a file of the same path, the theme content will not
|
||||
be included in the site, i.e. a user's `/assets/main.scss` will be read and
|
||||
processed if present instead of a theme's `/assets/main.scss`.
|
||||
|
||||
See our [documentation on the subject]({{ "/docs/themes/#assets" | relative_url }})
|
||||
for more info.
|
||||
|
||||
### 2. `relative_url` and `absolute_url` filters
|
||||
|
||||
Want a clean way to prepend the `baseurl` or `url` in your config? These
|
||||
new filters have you covered. When working locally, if you set your
|
||||
`baseurl` to match your deployment environment, say `baseurl: "/myproject"`,
|
||||
then `relative_url` will ensure that this baseurl is prepended to anything
|
||||
you pass it:
|
||||
|
||||
{% highlight liquid %}
|
||||
{% raw %}
|
||||
{{ "/docs/assets/" | relative_url }} => /myproject/docs/assets
|
||||
{% endraw %}
|
||||
{% endhighlight %}
|
||||
|
||||
By default, `baseurl` is set to `""` and therefore yields (never set to
|
||||
`"/"`):
|
||||
|
||||
{% highlight liquid %}
|
||||
{% raw %}
|
||||
{{ "/docs/assets/" | relative_url }} => /docs/assets
|
||||
{% endraw %}
|
||||
{% endhighlight %}
|
||||
|
||||
A result of `relative_url` will safely always produce a URL which is
|
||||
relative to the domain root. A similar principle applies to `absolute_url`.
|
||||
It prepends your `baseurl` and `url` values, making absolute URLs all the
|
||||
easier to make:
|
||||
|
||||
{% highlight liquid %}
|
||||
{% raw %}
|
||||
{{ "/docs/assets/" | absolute_url }} => https://jekyllrb.com/myproject/docs/assets
|
||||
{% endraw %}
|
||||
{% endhighlight %}
|
||||
|
||||
### 3. `site.url` is set by the development server
|
||||
|
||||
When you run `jekyll serve` locally, it starts a web server, usually at
|
||||
`http://localhost:4000`, that you use to preview your site during
|
||||
development. If you are using the new `absolute_url` filter, or using
|
||||
`site.url` anywhere, you have probably had to create a development config
|
||||
which resets the `url` value to point to `http://localhost:4000`.
|
||||
|
||||
No longer! When you run `jekyll serve`, Jekyll will build your site with
|
||||
the value of the `host`, `port`, and SSL-related options. This defaults to
|
||||
`url: http://localhost:4000`. When you are developing locally, `site.url`
|
||||
will yield `http://localhost:4000`.
|
||||
|
||||
This happens by default when running Jekyll locally. It will not be set if
|
||||
you set `JEKYLL_ENV=production` and run `jekyll serve`. If `JEKYLL_ENV` is
|
||||
any value except `development` (its default value), Jekyll will not
|
||||
overwrite the value of `url` in your config. And again, this only applies
|
||||
to serving, not to building.
|
||||
|
||||
## A *lot* more!
|
||||
|
||||
There are dozens of bug fixes and minor improvements to make your Jekyll
|
||||
experience better than ever. With every Jekyll release, we strive to bring
|
||||
greater stability and reliability to your everyday development workflow.
|
||||
|
||||
As always, thanks to our many contributors who contributed countless hours
|
||||
of their free time to making this release happen:
|
||||
|
||||
Anatoliy Yastreb, Anthony Gaudino, Antonio, Ashwin Maroli, Ben Balter,
|
||||
Charles Horn, Chris Finazzo, Daniel Chapman, David Zhang, Eduardo
|
||||
Bouças, Edward Thomson, Eloy Espinaco, Florian Thomas, Frank Taillandier,
|
||||
Gerardo, Heng Kwokfu, Heng, K. (Stephen), Jeff Kolesky, Jonathan Thornton,
|
||||
Jordon Bedwell, Jussi Kinnula, Júnior Messias, Kyle O'Brien, Manmeet Gill,
|
||||
Mark H. Wilkinson, Marko Locher, Mertcan GÖKGÖZ, Michal Švácha, Mike
|
||||
Kasberg, Nadjib Amar, Nicolas Hoizey, Nicolas Porcel, Parker Moore, Pat
|
||||
Hawks, Patrick Marsceill, Stephen Checkoway, Stuart Kent, XhmikosR, Zlatan
|
||||
Vasović, mertkahyaoglu, shingo-nakanishi, and vohedge.
|
||||
|
||||
[Full release notes]({{ "/docs/history/#v3-3-0" | relative_url }}) are available
|
||||
for your perusal. If you notice any issues, please don't hesitate to file a
|
||||
bug report.
|
||||
|
||||
Happy Jekylling!
|
||||
@@ -1,18 +0,0 @@
|
||||
---
|
||||
title: 'Jekyll 3.3.1 Released'
|
||||
date: 2016-11-14 14:29:59 -0800
|
||||
author: parkr
|
||||
version: 3.3.1
|
||||
categories: [release]
|
||||
---
|
||||
|
||||
Hello! We have a bugfix release of Jekyll hot off the presses for you. Key
|
||||
fixes to call out:
|
||||
|
||||
1. Only warn about auto-regeneration issues on Windows instead of disabling
|
||||
2. Exclude very specific `vendor/` subdirectories instead of all of `vendor/`
|
||||
3. Allow permalink templates to have plaintext underscores
|
||||
|
||||
..and lots more! Check out the [full history for more](/docs/history/#v3-3-1).
|
||||
|
||||
Happy Jekylling!
|
||||
@@ -1,42 +0,0 @@
|
||||
---
|
||||
title: 'Jekyll turns 3.4.0'
|
||||
date: 2017-01-18 14:19:13 -0500
|
||||
author: parkr
|
||||
version: 3.4.0
|
||||
categories: [release]
|
||||
---
|
||||
|
||||
Hey there! We have a quick update of Jekyll for you to enjoy this January.
|
||||
Packed full of bug fixes as usual, thanks to the tireless efforts of our
|
||||
exceptional Jekyll community. Three changes to call out:
|
||||
|
||||
1. If you're a big fan of [`where_by_exp`](/docs/templates/#filters), you'll be an
|
||||
even bigger fan of [`group_by_exp`](/docs/templates/#filters).
|
||||
2. Using a custom timezone in Jekyll on Windows? Yeah, sorry that hasn't ever worked
|
||||
properly. We made it possible to accurately [set the timezone using IANA
|
||||
timezone codes](https://jekyllrb.com/docs/windows/#timezone-management).
|
||||
3. Documentation has been improved, notably on themes, includes and permalinks.
|
||||
|
||||
And [lots and lots more!](/docs/history/#v3-4-0)
|
||||
|
||||
This update was made possible by the dedicated efforts of our excellent
|
||||
contributors: Ajay Karwal, Alexey Rogachev, Ashwin Maroli,
|
||||
BlueberryFoxtrot, Chase, Chayoung You, Dean Attali, Dmitrii Evdokimov, Don
|
||||
Denton, Eldritch Cheese, Fabrice Laporte, Florian Thomas, Frank
|
||||
Taillandier, Hugo, Ivan Dmitrievsky, Joel Meyer-Hamme, Josh Habdas, Kenton
|
||||
Hansen, Kevin Wojniak, Kurt Anderson, Longwelwind, Max Chadwick, Nicolas
|
||||
Hoizey, Nursen, Parker Moore, Pat Hawks, Purplecarrot, Ricardo N Feliciano,
|
||||
Rob Crocombe, Roger Ogden, Skylar Challand, Thiago Arrais, Tim Banks, Tom
|
||||
Johnson, Tunghsiao Liu, XhmikosR, Zlatan Vasović, alexmalik, brainscript,
|
||||
kimbaudi, muratayusuke, penny, and yoostk.
|
||||
|
||||
As always, if you encounter bugs, please do [search the issues]({{ site.repository }}/issues)
|
||||
and [file an issue]({{ site.repository }}/issues/new) if you aren't able to
|
||||
find a resolution. We also have [our Jekyll Talk
|
||||
forum](https://talk.jekyllrb.com) for those of you with general questions
|
||||
about how to accomplish certain tasks with Jekyll.
|
||||
|
||||
We have some exciting updates in store for v3.5, and we're hard at work on
|
||||
those already.
|
||||
|
||||
Happy Jekylling!
|
||||
@@ -1,106 +0,0 @@
|
||||
---
|
||||
title: 'Jekyll 3.4.1, or "Unintended Consequences"'
|
||||
date: 2017-03-02 14:20:26 -0500
|
||||
author: parkr
|
||||
version: 3.4.1
|
||||
categories: [release]
|
||||
---
|
||||
|
||||
Conformity is a confounding thing.
|
||||
|
||||
We write tests to ensure that a piece of functionality that works today
|
||||
will work tomorrow, as further modifications are made to the codebase. This
|
||||
is a principle of modern software development: every change must have a
|
||||
test to guard against regressions to the functionality implemented by that
|
||||
change.
|
||||
|
||||
And yet, occasionally, our very best efforts to test functionality will be
|
||||
thwarted. This is because of how our code produces unintended
|
||||
functionality, which naturally goes untested.
|
||||
|
||||
In our documentation, we tell users to name their posts with the following
|
||||
format:
|
||||
|
||||
```text
|
||||
YYYY-MM-DD-title.extension
|
||||
```
|
||||
|
||||
That format specifies exactly four numbers for the year, e.g. 2017, two
|
||||
letters for the month, e.g. 03, and two letters for the day, e.g. 02. To
|
||||
match this, we had the following regular expression:
|
||||
|
||||
```ruby
|
||||
%r!^(?:.+/)*(\d+-\d+-\d+)-(.*)(\.[^.]+)$!
|
||||
```
|
||||
|
||||
You might already see the punchline. While our documentation specifies the
|
||||
exact number of numbers that is required for each section of the date, our
|
||||
regular expression does not enforce this precision. What happens if a user
|
||||
doesn't conform to our documentation?
|
||||
|
||||
We recently [received a bug report](https://github.com/jekyll/jekyll/issues/5603)
|
||||
that detailed how the following file was considered a post:
|
||||
|
||||
```text
|
||||
84093135-42842323-42000001-b890-136270f7e5f1.md
|
||||
```
|
||||
|
||||
Of course! It matches the above regular expression, but doesn't satisfy
|
||||
other requirements about those numbers being a valid date (unless you're
|
||||
living in a world that has 43 million months, and 42 million (and one)
|
||||
days). So, we [modified the regular expression to match our
|
||||
documentation](https://github.com/jekyll/jekyll/pull/5609):
|
||||
|
||||
```ruby
|
||||
%r!^(?:.+/)*(\d{4}-\d{2}-\d{2})-(.*)(\.[^.]+)$!
|
||||
```
|
||||
|
||||
Our tests all passed and we were properly excluding this crazy date with 43
|
||||
million months and days. This change shipped in Jekyll v3.4.0 and all was
|
||||
well.
|
||||
|
||||
Well, not so much.
|
||||
|
||||
A very common way to specify the month of February is `2`. This is true for
|
||||
all single-digit months and days of the month. Notice anything about our
|
||||
first regular expression versus our second? The second regular expression
|
||||
imposes a **minimum**, as well as maximum, number of digits. This change
|
||||
made Jekyll ignore dates with single-digit days and months.
|
||||
|
||||
The first eight years of Jekyll's existence had allowed single-digit days
|
||||
and months due to an imprecise regular expression. For some people, their
|
||||
entire blog was missing, and there were no errors that told them why.
|
||||
|
||||
After receiving a few bug reports, it became clear what had happened.
|
||||
Unintended functionality of the last eight years had been broken. Thus,
|
||||
v3.4.0 was broken for a non-negligible number of sites. With a test site
|
||||
in-hand from @andrewbanchich, I tracked it down to this regular expression
|
||||
and [reintroduced](https://github.com/jekyll/jekyll/pull/5920) a proper
|
||||
minimum number of digits for each segment:
|
||||
|
||||
```ruby
|
||||
%r!^(?:.+/)*(\d{2,4}-\d{1,2}-\d{1,2})-(.*)(\.[^.]+)$!
|
||||
```
|
||||
|
||||
And, I wrote a test.
|
||||
|
||||
This change was quickly backported to v3.4.0 and here we are: releasing
|
||||
v3.4.1. It will fix the problem for all users who were using single-digit
|
||||
months and days.
|
||||
|
||||
With this, I encourage all of you to look at your code for *unintended*
|
||||
functionality and make a judgement call: if it's allowed, *should it be*?
|
||||
If it should be allowed, make it *intended* functionality and test it! I
|
||||
know I'll be looking at my code with much greater scrutiny going forward,
|
||||
looking for unintended consequences.
|
||||
|
||||
Many thanks to our Jekyll affinity team captains who helped out, including
|
||||
@pathawks, @pnn, and @DirtyF. Thanks, too, to @ashmaroli for reviewing my
|
||||
change with an eye for consistency and precision. This was certainly a team
|
||||
effort.
|
||||
|
||||
We hope Jekyll v3.4.1 brings your variable-digit dates back to their
|
||||
previous glory. We certainly won't let that unintended functionality be
|
||||
unintended any longer.
|
||||
|
||||
As always, Happy Jekylling!
|
||||
@@ -1,51 +0,0 @@
|
||||
---
|
||||
title: 'Jekyll 3.4.2 Released'
|
||||
date: 2017-03-09 15:41:57 -0500
|
||||
author: parkr
|
||||
version: 3.4.2
|
||||
categories: [release]
|
||||
---
|
||||
|
||||
Another one-PR patch update, though without the same [lessons as for the
|
||||
previous release]({% link _posts/2017-03-02-jekyll-3-4-1-released.markdown %}).
|
||||
|
||||
This release includes a beneficial change for a number of plugins:
|
||||
**static files now respect front matter defaults**.
|
||||
|
||||
You might be asking yourself: "why would static files, files that are
|
||||
static files explicitly because they *don't* have YAML front matter, want
|
||||
to respect YAML front matter?" That's a great question. Let me illustrate
|
||||
with an example.
|
||||
|
||||
Let's look at `jekyll-sitemap`. This plugin generates a list of documents,
|
||||
pages, and static files, and some metadata for them in an XML file for a
|
||||
Google/Yahoo/Bing/DuckDuckGo crawler to consume. If you don't want a given
|
||||
file in this list, you set `sitemap: false` in the YAML front matter. But
|
||||
what about static files, which don't have YAML front matter? Before this
|
||||
release, they could not be excluded because they had no properties in YAML
|
||||
other than [the ones we explicitly assigned](https://github.com/jekyll/jekyll/blob/v3.4.1/lib/jekyll/static_file.rb#L98-L106).
|
||||
So if you had a PDF you didn't want to be in your sitemap, you couldn't use
|
||||
`jekyll-sitemap`.
|
||||
|
||||
With this release, you can now set [front matter
|
||||
defaults](/docs/configuration/#front-matter-defaults) for static files:
|
||||
|
||||
```yaml
|
||||
defaults:
|
||||
-
|
||||
scope:
|
||||
path: "pdfs/"
|
||||
values:
|
||||
sitemap: false
|
||||
```
|
||||
|
||||
Now, for every file in the Liquid `site.static_files` loop which is in the
|
||||
folder `pdfs/`, you'll see `sitemap` equal to `false`.
|
||||
|
||||
Many thanks to @benbalter for coming up with the solution and ensuring
|
||||
sitemaps everywhere are filled with just the right content.
|
||||
|
||||
As always, if you notice any bugs, please search the issues and file one if
|
||||
you can't find another related to your issue.
|
||||
|
||||
Happy Jekylling!
|
||||
@@ -1,49 +0,0 @@
|
||||
---
|
||||
title: 'Jekyll 3.4.3 Released'
|
||||
date: 2017-03-21 08:52:53 -0500
|
||||
author: pathawks
|
||||
version: 3.4.3
|
||||
categories: [release]
|
||||
---
|
||||
|
||||
Another one-PR patch update as we continue our quest to destroy all bugs. A
|
||||
fairly technical debriefing follows, but the TLDR is that we have updated the
|
||||
`uri_escape` filter to more closely follow the pre-v3.4.0 behavior.
|
||||
|
||||
In [v3.4.0]({% link _posts/2017-01-18-jekyll-3-4-0-released.markdown %}), we
|
||||
moved away from using the deprecated
|
||||
[`URI.escape`](https://ruby-doc.org/stdlib-2.3.0/libdoc/uri/rdoc/URI/Escape.html#method-i-encode)
|
||||
in favor of
|
||||
[`Addressable::URI.encode`](http://www.rubydoc.info/gems/addressable/Addressable/URI#encode-class_method).
|
||||
This is what powers our [`uri_escape`
|
||||
filter](https://jekyllrb.com/docs/templates/).
|
||||
|
||||
While this transition was mostly a smooth one, the two methods are not
|
||||
identical. While `URI.escape` was happy to escape any string,
|
||||
`Addressable::URI.encode` first turns the string into an `Addressable::URI`
|
||||
object, and will then escape each component of that object. In most cases, this
|
||||
difference was insignificant, but there were a few cases where this caused some
|
||||
unintended regressions when encoding colons.
|
||||
|
||||
While **Addressable** can understand that something like `"/example :page"` is a
|
||||
relative URI, without the slash it cannot figure out how to turn
|
||||
`"example :page"` into an `Addressable::URI` object. `URI.escape` had no such
|
||||
objection. This lead to the following Liquid code working fine in Jekyll 3.3.x
|
||||
but breaking in 3.4.0:
|
||||
|
||||
{% raw %}
|
||||
```liquid
|
||||
{{ "example :page" | uri_escape }}
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
This was not an intended consequence of switching to **Addressable**.
|
||||
|
||||
Fortunately, the solution was not complicated. **Addressable** has a method
|
||||
[`Addressable::URI.normalize_component`](http://www.rubydoc.info/gems/addressable/Addressable/URI#normalize_component-class_method)
|
||||
which will simply escape the characters in a string, much like `URI.escape`.
|
||||
|
||||
Thanks to @cameronmcefee and @FriesFlorian for reporting
|
||||
[this issue](https://github.com/jekyll/jekyll/issues/5954).
|
||||
|
||||
Happy Jekylling!
|
||||
@@ -1,38 +0,0 @@
|
||||
---
|
||||
title: 'Jekyll turns 3.5, oh my!'
|
||||
date: 2017-06-15 17:32:32 -0400
|
||||
author: parkr
|
||||
version: 3.5.0
|
||||
categories: [release]
|
||||
---
|
||||
|
||||
Good news! Nearly 400 commits later, Jekyll 3.5.0 has been released into
|
||||
the wild. Some new shiny things you might want to test out:
|
||||
|
||||
- Jekyll now uses Liquid 4, the latest! It comes with whitespace control, new filters `concat` annd `compact`, loop performance improvements and [many fixes](https://github.com/Shopify/liquid/blob/master/History.md#400--2016-12-14--branch-4-0-stable)
|
||||
- Themes can specify runtime dependencies (in their gemspecs) and we'll require those. This makes it easier for theme writers to use plugins.
|
||||
- Speaking of themes, we'll properly handle the discrepancy between a convertible file in the local site and a static file in the theme. Overriding a file locally now doesn't matter if it's convertible or static.
|
||||
- Pages, posts, and other documents can now access layout variables via `{% raw %}{{ layout }}{% endraw %}`.
|
||||
- The `gems` key in the `_config.yml` is now `plugins`. This is backwards-compatible, as Jekyll will gracefully upgrade `gems` to `plugins` if you use the former.
|
||||
- Filters like `sort` now allow you to sort based on a subvalue, e.g. `{% raw %}{% assign sorted = site.posts | sort: "image.alt_text" %}{% endraw %}`.
|
||||
- You can now create tab-separated data files.
|
||||
- Using `layout: none` will now produce a file with no layout. Equivalent to `layout: null`, with the exception that `none` is a truthy value and won't be overwritten by front matter defaults.
|
||||
- No more pesky errors if your URL contains a colon (sorry about those!)
|
||||
- We now automatically exclude the `Gemfile` from the site manifest when compiling your site. No more `_site/Gemfile`!
|
||||
- We fixed a bug where abbreviated post dates were ignored, e.g. `_posts/2016-4-4-april-fourth.md`.
|
||||
|
||||
And [so much more!](/docs/history/)
|
||||
|
||||
There was a huge amount of effort put into this release by our maintainers,
|
||||
especially @pathawks, @DirtyF, and @pup. Huge thanks to them for ushering
|
||||
this release along and keeping the contributions flowing! Jekyll wouldn't
|
||||
work without the tireless dedication of our team captains & maintainers.
|
||||
Thank you, all!
|
||||
|
||||
A huge thanks as well to our contributors to this release: Adam Hollett, Aleksander Kuś, Alfred Myers, Anatoliy Yastreb, Antonio Argote, Ashton Hellwig, Ashwin Maroli, Ben Balter, BlueberryFoxtrot, Brent Yi, Chris Finazzo, Christoph Päper, Christopher League, Chun Fei Lung, Colin, David Zhang, Eric Leong, Finn Ellis, Florian Thomas, Frank Taillandier, Hendrik Schneider, Henry Kobin, Ivan Storck, Jakub Klímek, Jan Pobořil, Jeff Puckett, Jonathan Hooper, Kaligule, Kevin Funk, Krzysztof Szafranek, Liu Cheng, Lukasz Brodowski, Marc Bruins, Marcelo Canina, Martin Desrumaux, Mer, Nate, Oreonax, Parker Moore, Pat Hawks, Pedro Lamas, Phil Nash, Ricardo N Feliciano, Ricky Han, Roger Sheen, Ryan Lue, Ryan Streur, Shane Neuville, Sven Meyer, Tom Johnson, William Entriken, Yury V. Zaytsev, Zarino Zappia, dyang, jekylltools, sean delaney, zenHeart
|
||||
|
||||
Please file any bugs with detailed replication instructions if you find any
|
||||
bugs. Better yet, submit a patch if you find the bug in the code and know
|
||||
how to fix it! :heart:
|
||||
|
||||
Happy Jekylling! :tada:
|
||||
@@ -1,19 +0,0 @@
|
||||
---
|
||||
title: 'Jekyll 3.5.1 Released'
|
||||
date: 2017-07-17 12:40:37 -0400
|
||||
author: parkr
|
||||
version: 3.5.1
|
||||
categories: [release]
|
||||
---
|
||||
|
||||
We've released a few bugfixes in the form of v3.5.1 today:
|
||||
|
||||
- Some plugins stopped functioning properly due to a NoMethodError for `registers` on NilClass. That's been fixed.
|
||||
- A bug in `relative_url` when `baseurl` is `nil` caused URL's to come out wrong. Squashed.
|
||||
- Static files' liquid representations should now have all the keys you were expecting when serialized into JSON.
|
||||
|
||||
We apologize for the breakages! We're working diligently to improve how we test our plugins with Jekyll core to prevent breakages in the future.
|
||||
|
||||
More details in [the history](/docs/history/#v3-5-1). Many thanks to all the contributors to Jekyll v3.5.1: Adam Voss, ashmaroli, Ben Balter, Coby Chapple, Doug Beney, Fadhil, Florian Thomas, Frank Taillandier, James, jaybe, Joshua Byrd, Kevin Plattret, & Robert Jäschke.
|
||||
|
||||
Happy Jekylling!
|
||||
@@ -1,24 +0,0 @@
|
||||
@font-face {
|
||||
font-family: 'FontAwesome';
|
||||
src: url('../fonts/FontAwesome.eot?9h6hxj');
|
||||
src: url('../fonts/FontAwesome.eot?9h6hxj#iefix') format('embedded-opentype'),
|
||||
url('../fonts/FontAwesome.woff?9h6hxj') format('woff'),
|
||||
url('../fonts/FontAwesome.ttf?9h6hxj') format('truetype'),
|
||||
url('../fonts/FontAwesome.svg?9h6hxj#FontAwesome') format('svg');
|
||||
font-weight: normal;
|
||||
font-style: normal;
|
||||
}
|
||||
.fa {
|
||||
display: inline-block;
|
||||
font: normal normal normal 14px/1 FontAwesome;
|
||||
font-size: inherit;
|
||||
text-rendering: auto;
|
||||
-webkit-font-smoothing: antialiased;
|
||||
-moz-osx-font-smoothing: grayscale;
|
||||
}
|
||||
.fa-link:before {
|
||||
content: "\f0c1";
|
||||
}
|
||||
.fa-pencil:before {
|
||||
content: "\f040";
|
||||
}
|
||||
@@ -1,427 +0,0 @@
|
||||
/*! normalize.css v6.0.0 | MIT License | github.com/necolas/normalize.css */
|
||||
|
||||
/* Document
|
||||
========================================================================== */
|
||||
|
||||
/**
|
||||
* 1. Correct the line height in all browsers.
|
||||
* 2. Prevent adjustments of font size after orientation changes in
|
||||
* IE on Windows Phone and in iOS.
|
||||
*/
|
||||
|
||||
html {
|
||||
line-height: 1.15; /* 1 */
|
||||
-ms-text-size-adjust: 100%; /* 2 */
|
||||
-webkit-text-size-adjust: 100%; /* 2 */
|
||||
}
|
||||
|
||||
/* Sections
|
||||
========================================================================== */
|
||||
|
||||
/**
|
||||
* Add the correct display in IE 9-.
|
||||
*/
|
||||
|
||||
article,
|
||||
aside,
|
||||
footer,
|
||||
header,
|
||||
nav,
|
||||
section {
|
||||
display: block;
|
||||
}
|
||||
|
||||
/**
|
||||
* Correct the font size and margin on `h1` elements within `section` and
|
||||
* `article` contexts in Chrome, Firefox, and Safari.
|
||||
*/
|
||||
|
||||
h1 {
|
||||
font-size: 2em;
|
||||
margin: 0.67em 0;
|
||||
}
|
||||
|
||||
/* Grouping content
|
||||
========================================================================== */
|
||||
|
||||
/**
|
||||
* Add the correct display in IE 9-.
|
||||
* 1. Add the correct display in IE.
|
||||
*/
|
||||
|
||||
figcaption,
|
||||
figure,
|
||||
main { /* 1 */
|
||||
display: block;
|
||||
}
|
||||
|
||||
/**
|
||||
* Add the correct margin in IE 8.
|
||||
*/
|
||||
|
||||
figure {
|
||||
margin: 1em 40px;
|
||||
}
|
||||
|
||||
/**
|
||||
* 1. Add the correct box sizing in Firefox.
|
||||
* 2. Show the overflow in Edge and IE.
|
||||
*/
|
||||
|
||||
hr {
|
||||
box-sizing: content-box; /* 1 */
|
||||
height: 0; /* 1 */
|
||||
overflow: visible; /* 2 */
|
||||
}
|
||||
|
||||
/**
|
||||
* 1. Correct the inheritance and scaling of font size in all browsers.
|
||||
* 2. Correct the odd `em` font sizing in all browsers.
|
||||
*/
|
||||
|
||||
pre {
|
||||
font-family: monospace, monospace; /* 1 */
|
||||
font-size: 1em; /* 2 */
|
||||
}
|
||||
|
||||
/* Text-level semantics
|
||||
========================================================================== */
|
||||
|
||||
/**
|
||||
* 1. Remove the gray background on active links in IE 10.
|
||||
* 2. Remove gaps in links underline in iOS 8+ and Safari 8+.
|
||||
*/
|
||||
|
||||
a {
|
||||
background-color: transparent; /* 1 */
|
||||
-webkit-text-decoration-skip: objects; /* 2 */
|
||||
}
|
||||
|
||||
/**
|
||||
* 1. Remove the bottom border in Chrome 57- and Firefox 39-.
|
||||
* 2. Add the correct text decoration in Chrome, Edge, IE, Opera, and Safari.
|
||||
*/
|
||||
|
||||
abbr[title] {
|
||||
border-bottom: none; /* 1 */
|
||||
text-decoration: underline; /* 2 */
|
||||
text-decoration: underline dotted; /* 2 */
|
||||
}
|
||||
|
||||
/**
|
||||
* Prevent the duplicate application of `bolder` by the next rule in Safari 6.
|
||||
*/
|
||||
|
||||
b,
|
||||
strong {
|
||||
font-weight: inherit;
|
||||
}
|
||||
|
||||
/**
|
||||
* Add the correct font weight in Chrome, Edge, and Safari.
|
||||
*/
|
||||
|
||||
b,
|
||||
strong {
|
||||
font-weight: bolder;
|
||||
}
|
||||
|
||||
/**
|
||||
* 1. Correct the inheritance and scaling of font size in all browsers.
|
||||
* 2. Correct the odd `em` font sizing in all browsers.
|
||||
*/
|
||||
|
||||
code,
|
||||
kbd,
|
||||
samp {
|
||||
font-family: monospace, monospace; /* 1 */
|
||||
font-size: 1em; /* 2 */
|
||||
}
|
||||
|
||||
/**
|
||||
* Add the correct font style in Android 4.3-.
|
||||
*/
|
||||
|
||||
dfn {
|
||||
font-style: italic;
|
||||
}
|
||||
|
||||
/**
|
||||
* Add the correct background and color in IE 9-.
|
||||
*/
|
||||
|
||||
mark {
|
||||
background-color: #ff0;
|
||||
color: #000;
|
||||
}
|
||||
|
||||
/**
|
||||
* Add the correct font size in all browsers.
|
||||
*/
|
||||
|
||||
small {
|
||||
font-size: 80%;
|
||||
}
|
||||
|
||||
/**
|
||||
* Prevent `sub` and `sup` elements from affecting the line height in
|
||||
* all browsers.
|
||||
*/
|
||||
|
||||
sub,
|
||||
sup {
|
||||
font-size: 75%;
|
||||
line-height: 0;
|
||||
position: relative;
|
||||
vertical-align: baseline;
|
||||
}
|
||||
|
||||
sub {
|
||||
bottom: -0.25em;
|
||||
}
|
||||
|
||||
sup {
|
||||
top: -0.5em;
|
||||
}
|
||||
|
||||
/* Embedded content
|
||||
========================================================================== */
|
||||
|
||||
/**
|
||||
* Add the correct display in IE 9-.
|
||||
*/
|
||||
|
||||
audio,
|
||||
video {
|
||||
display: inline-block;
|
||||
}
|
||||
|
||||
/**
|
||||
* Add the correct display in iOS 4-7.
|
||||
*/
|
||||
|
||||
audio:not([controls]) {
|
||||
display: none;
|
||||
height: 0;
|
||||
}
|
||||
|
||||
/**
|
||||
* Remove the border on images inside links in IE 10-.
|
||||
*/
|
||||
|
||||
img {
|
||||
border-style: none;
|
||||
}
|
||||
|
||||
/**
|
||||
* Hide the overflow in IE.
|
||||
*/
|
||||
|
||||
svg:not(:root) {
|
||||
overflow: hidden;
|
||||
}
|
||||
|
||||
/* Forms
|
||||
========================================================================== */
|
||||
|
||||
/**
|
||||
* Remove the margin in Firefox and Safari.
|
||||
*/
|
||||
|
||||
button,
|
||||
input,
|
||||
optgroup,
|
||||
select,
|
||||
textarea {
|
||||
margin: 0;
|
||||
}
|
||||
|
||||
/**
|
||||
* Show the overflow in IE.
|
||||
* 1. Show the overflow in Edge.
|
||||
*/
|
||||
|
||||
button,
|
||||
input { /* 1 */
|
||||
overflow: visible;
|
||||
}
|
||||
|
||||
/**
|
||||
* Remove the inheritance of text transform in Edge, Firefox, and IE.
|
||||
* 1. Remove the inheritance of text transform in Firefox.
|
||||
*/
|
||||
|
||||
button,
|
||||
select { /* 1 */
|
||||
text-transform: none;
|
||||
}
|
||||
|
||||
/**
|
||||
* 1. Prevent a WebKit bug where (2) destroys native `audio` and `video`
|
||||
* controls in Android 4.
|
||||
* 2. Correct the inability to style clickable types in iOS and Safari.
|
||||
*/
|
||||
|
||||
button,
|
||||
html [type="button"], /* 1 */
|
||||
[type="reset"],
|
||||
[type="submit"] {
|
||||
-webkit-appearance: button; /* 2 */
|
||||
}
|
||||
|
||||
/**
|
||||
* Remove the inner border and padding in Firefox.
|
||||
*/
|
||||
|
||||
button::-moz-focus-inner,
|
||||
[type="button"]::-moz-focus-inner,
|
||||
[type="reset"]::-moz-focus-inner,
|
||||
[type="submit"]::-moz-focus-inner {
|
||||
border-style: none;
|
||||
padding: 0;
|
||||
}
|
||||
|
||||
/**
|
||||
* Restore the focus styles unset by the previous rule.
|
||||
*/
|
||||
|
||||
button:-moz-focusring,
|
||||
[type="button"]:-moz-focusring,
|
||||
[type="reset"]:-moz-focusring,
|
||||
[type="submit"]:-moz-focusring {
|
||||
outline: 1px dotted ButtonText;
|
||||
}
|
||||
|
||||
/**
|
||||
* 1. Correct the text wrapping in Edge and IE.
|
||||
* 2. Correct the color inheritance from `fieldset` elements in IE.
|
||||
* 3. Remove the padding so developers are not caught out when they zero out
|
||||
* `fieldset` elements in all browsers.
|
||||
*/
|
||||
|
||||
legend {
|
||||
box-sizing: border-box; /* 1 */
|
||||
color: inherit; /* 2 */
|
||||
display: table; /* 1 */
|
||||
max-width: 100%; /* 1 */
|
||||
padding: 0; /* 3 */
|
||||
white-space: normal; /* 1 */
|
||||
}
|
||||
|
||||
/**
|
||||
* 1. Add the correct display in IE 9-.
|
||||
* 2. Add the correct vertical alignment in Chrome, Firefox, and Opera.
|
||||
*/
|
||||
|
||||
progress {
|
||||
display: inline-block; /* 1 */
|
||||
vertical-align: baseline; /* 2 */
|
||||
}
|
||||
|
||||
/**
|
||||
* Remove the default vertical scrollbar in IE.
|
||||
*/
|
||||
|
||||
textarea {
|
||||
overflow: auto;
|
||||
}
|
||||
|
||||
/**
|
||||
* 1. Add the correct box sizing in IE 10-.
|
||||
* 2. Remove the padding in IE 10-.
|
||||
*/
|
||||
|
||||
[type="checkbox"],
|
||||
[type="radio"] {
|
||||
box-sizing: border-box; /* 1 */
|
||||
padding: 0; /* 2 */
|
||||
}
|
||||
|
||||
/**
|
||||
* Correct the cursor style of increment and decrement buttons in Chrome.
|
||||
*/
|
||||
|
||||
[type="number"]::-webkit-inner-spin-button,
|
||||
[type="number"]::-webkit-outer-spin-button {
|
||||
height: auto;
|
||||
}
|
||||
|
||||
/**
|
||||
* 1. Correct the odd appearance in Chrome and Safari.
|
||||
* 2. Correct the outline style in Safari.
|
||||
*/
|
||||
|
||||
[type="search"] {
|
||||
-webkit-appearance: textfield; /* 1 */
|
||||
outline-offset: -2px; /* 2 */
|
||||
}
|
||||
|
||||
/**
|
||||
* Remove the inner padding and cancel buttons in Chrome and Safari on macOS.
|
||||
*/
|
||||
|
||||
[type="search"]::-webkit-search-cancel-button,
|
||||
[type="search"]::-webkit-search-decoration {
|
||||
-webkit-appearance: none;
|
||||
}
|
||||
|
||||
/**
|
||||
* 1. Correct the inability to style clickable types in iOS and Safari.
|
||||
* 2. Change font properties to `inherit` in Safari.
|
||||
*/
|
||||
|
||||
::-webkit-file-upload-button {
|
||||
-webkit-appearance: button; /* 1 */
|
||||
font: inherit; /* 2 */
|
||||
}
|
||||
|
||||
/* Interactive
|
||||
========================================================================== */
|
||||
|
||||
/*
|
||||
* Add the correct display in IE 9-.
|
||||
* 1. Add the correct display in Edge, IE, and Firefox.
|
||||
*/
|
||||
|
||||
details, /* 1 */
|
||||
menu {
|
||||
display: block;
|
||||
}
|
||||
|
||||
/*
|
||||
* Add the correct display in all browsers.
|
||||
*/
|
||||
|
||||
summary {
|
||||
display: list-item;
|
||||
}
|
||||
|
||||
/* Scripting
|
||||
========================================================================== */
|
||||
|
||||
/**
|
||||
* Add the correct display in IE 9-.
|
||||
*/
|
||||
|
||||
canvas {
|
||||
display: inline-block;
|
||||
}
|
||||
|
||||
/**
|
||||
* Add the correct display in IE.
|
||||
*/
|
||||
|
||||
template {
|
||||
display: none;
|
||||
}
|
||||
|
||||
/* Hidden
|
||||
========================================================================== */
|
||||
|
||||
/**
|
||||
* Add the correct display in IE 10-.
|
||||
*/
|
||||
|
||||
[hidden] {
|
||||
display: none;
|
||||
}
|
||||
@@ -1,521 +0,0 @@
|
||||
---
|
||||
layout: tutorials
|
||||
permalink: /tutorials/convert-site-to-jekyll/
|
||||
title: Convert an HTML site to Jekyll
|
||||
---
|
||||
|
||||
If you're looking for themes for your Jekyll site, you don't have to restrict yourself to existing Jekyll themes. It's pretty easy to convert almost any static HTML files into a Jekyll website.
|
||||
|
||||
In many ways, any site that is currently a static site is *already* a Jekyll website. Jekyll just allows you to automate parts of the site (like inserting pages into templates, rendering lists for navigation, generating feeds and sitemaps, and more) as it processes the files.
|
||||
|
||||
Understanding how to convert any HTML site into Jekyll templates will open your world to many more options for Jekyll themes. Instead of [searching online for *Jekyll themes*](https://duckduckgo.com/?q=Jekyll+themes), you can choose from the large variety of HTML templates for your site, quickly Jekyll-ize the HTML templates as you need to, and build the output with Jekyll.
|
||||
|
||||
Although websites can have sophisticated features and controls, we'll keep things simple in this tutorial.
|
||||
|
||||
## What is a Jekyll Website?
|
||||
|
||||
First, let's start with a grounding in the basics. Stripping a Jekyll site down to an extremely basic level will help clarify what happens in a Jekyll site. If you haven't already installed the jekyll gem, [install it]({% link _docs/installation.md %}).
|
||||
|
||||
We'll start with a *basic Jekyll site* consisting of three files:
|
||||
|
||||
```
|
||||
├── _config.yml
|
||||
├── _layouts
|
||||
│ └── default.html
|
||||
└── index.md
|
||||
```
|
||||
|
||||
Manually create these three files in a folder called `my_jekyll_site` or whatever suits you the most, and place `default.html` inside a folder named `_layouts`.
|
||||
|
||||
```sh
|
||||
$ touch _config.yml index.md default.html
|
||||
$ mkdir _layouts && mv default.html _layouts
|
||||
```
|
||||
|
||||
Fire up your favorite editor, and populate the contents of the `default.html` and `index.md` files as follows:
|
||||
|
||||
**_config.yml**
|
||||
|
||||
```yaml
|
||||
name: My Jekyll Website
|
||||
```
|
||||
|
||||
**_layouts/default.html**
|
||||
|
||||
```html
|
||||
<!DOCTYPE html>
|
||||
<html>
|
||||
<body>
|
||||
{% raw %}{{ content }}{% endraw %}
|
||||
</body>
|
||||
</html>
|
||||
```
|
||||
|
||||
**index.md**
|
||||
|
||||
```yaml
|
||||
---
|
||||
title: My page
|
||||
layout: default
|
||||
---
|
||||
|
||||
# {% raw %}{{ page.title }}{% endraw %}
|
||||
|
||||
Content is written in [Markdown](https://learnxinyminutes.com/docs/markdown/). Plain text format allows you to focus on your **content**.
|
||||
|
||||
<!--
|
||||
You can use HTML elements in Markdown, such as the comment element, and they won't be affected by a markdown parser. However, if you create an HTML element in your markdown file, you cannot use markdown syntax within that element's contents.
|
||||
-->
|
||||
```
|
||||
|
||||
Now `cd` to `my_jekyll_site` and serve the site with the built-in server:
|
||||
|
||||
```
|
||||
cd my_jekyll_site
|
||||
jekyll serve
|
||||
```
|
||||
|
||||
If you have a Gemfile, [use Bundler]({% link _docs/quickstart.md %}#about-bundler) by typing `bundle exec jekyll serve` instead.
|
||||
{: .note .info}
|
||||
|
||||
When you serve the site, you get a preview URL such as `http://127.0.0.1:4000/` (which is the same as `http://localhost:4000/`). The site's files are built into the `_site` folder by default.
|
||||
|
||||
This is a Jekyll site at the most basic functional level. Here's what is happening:
|
||||
|
||||
* The `_config.yml` file contains settings that Jekyll uses as it processes your site. An empty config file will use default values for building a Jekyll site. For example, to convert [Markdown](https://learnxinyminutes.com/docs/markdown/) to HTML, Jekyll will automatically use the [kramdown Markdown filter](https://rubygems.org/gems/kramdown/), without any need to specify it.
|
||||
* Jekyll looks for files with [front matter tags]({% link _docs/frontmatter.md %}) (the two sets of dashed lines `---` like those in `index.md`) and processes the files (populating site variables, rendering any [Liquid](https://shopify.github.io/liquid/), and converting Markdown to HTML).
|
||||
* Jekyll pushes the content from all pages and posts into the `{% raw %}{{ content }}{% endraw %}` variable in the layout specified (`default`) in the front matter tags.
|
||||
* The processed files get written as `.html` files in the `_site` directory.
|
||||
|
||||
You can read more about how Jekyll processes the files in [order of Interpretation]({% link _tutorials/orderofinterpretation.md %}).
|
||||
|
||||
With this basic understanding of how a Jekyll site works, you can convert almost any HTML theme for Jekyll. The following sections will take you through a step-by-step tutorial to do so.
|
||||
|
||||
## 1. Create a template for your default layout
|
||||
|
||||
Find your HTML theme and save it as a `default` layout. If you're converting or cloning an existing site, you can right-click the page and view the source code.
|
||||
|
||||
For example, suppose you're cloning your company site to create a documentation site with the same branding. Or suppose you have a personal site that you built with HTML and now want to make it a Jekyll site. Get the HTML source code for your site.
|
||||
|
||||
{: .note .info}
|
||||
Regardless of the site, do check the license and make sure you have permission to copy and use the code.
|
||||
|
||||
Copy and paste the source code into a file called `default.html`. Put the `default.html` file inside the `_layouts` folder. This will be the default layout template for your pages and posts — that is, each page or post will use this layout when Jekyll builds the site.
|
||||
|
||||
Note that in looking for templates, you want the HTML output of the template. If the template has PHP tags or other dynamic scripts, these dynamic elements will need to be converted to HTML or to [Liquid](https://shopify.github.io/liquid/). Liquid is [Jekyll templating system]({% link _docs/templates.md %}) to retrieve dynamic content.
|
||||
|
||||
Open `default.html` into your browser locally to ensure the site looks and behaves like it does online. You will likely need to adjust CSS, JS, and image paths so they work.
|
||||
|
||||
For example, if the paths were relative on the site you copied, you'll need to either download the same assets into your Jekyll site or use absolute paths to the same assets in the cloud. (Syntax such as `src="//` requires a prefix such as `src="http://` to work in your local browser.)
|
||||
|
||||
Jekyll provides some [filters]({% link _docs/templates.md %}#filters) to prepend a site URL before path. For example, you could preface your stylesheet like this:
|
||||
|
||||
```liquid
|
||||
{% raw %}{{ "/assets/style.css" | relative_url }}{% endraw %}
|
||||
```
|
||||
|
||||
The `relative_url` filter will prepend the [`baseurl`](https://byparker.com/blog/2014/clearing-up-confusion-around-baseurl/) value from your config file (as`blog` for instance) to the input. This is useful if your site is hosted at a subpath rather than at the root of the domain (for example, `http://mysite.com/blog/`).
|
||||
|
||||
You can also use an `absolute_url` filter. This filter will prepend the `url` *and* `baseurl` value to the input:
|
||||
|
||||
```liquid
|
||||
{% raw %}{{ "/assets/style.css" | absolute_url }}{% endraw %}
|
||||
```
|
||||
|
||||
Again, both `url` and `baseurl` can be defined in your site's config file, like this:
|
||||
|
||||
```
|
||||
url: http://mysite.com
|
||||
baseurl: /blog
|
||||
```
|
||||
|
||||
The result in the output will be `http://mysite.com/blog/assets/style.css`.
|
||||
|
||||
Note that the `url` property of any page begins with a forward slash (`/`), so omit this at the end of your `url` or `baseurl` property.
|
||||
|
||||
You don't have to prepend filters to link paths like this. You could also use relative links across your entire site. However you decide to code the paths to your assets, make sure they render correctly.
|
||||
|
||||
Does your local `default.html` page look good in your browser? Are all images, styles, and other elements showing up correctly? If so, great. Keep going. You can use this template as the layout for all your pages and posts or create as many templates as you need.
|
||||
|
||||
In the next section, you'll blank out the content of the layout and replace it with placeholder tags that get populated dynamically with your Jekyll pages.
|
||||
|
||||
## 2. Identify the content part of the layout
|
||||
|
||||
In `default.html`, find where the page content begins (usually at `h1` or `h2` tags). Replace the title that appears inside these tags with `{% raw %}{{ page.title }}{% endraw %}`.
|
||||
|
||||
Remove the content part (keep everything else: navigation menu, sidebar, footer, etc.) and replace it with `{% raw %}{{ content }}{% endraw %}`.
|
||||
|
||||
Check the layout again in your browser and make sure you didn't corrupt or alter it up by inadvertently removing a crucial `div` tag or other element. The only change should be to the title and page content, which are now blanked out or showing the placeholder tag.
|
||||
|
||||
## 3. Create a couple of files with front matter tags
|
||||
|
||||
Create a couple of files (`index.md` and `about.md`) in your root directory.
|
||||
|
||||
In your `index.md` file, add some front matter tags containing a `title` and `layout` property, like this:
|
||||
|
||||
```yaml
|
||||
---
|
||||
title: Home
|
||||
layout: default
|
||||
---
|
||||
|
||||
Some page content here...
|
||||
```
|
||||
|
||||
Create another page for testing called `about.md` with similar front matter tags.
|
||||
|
||||
{: .note .info}
|
||||
If you don't specify a layout in your pages, Jekyll will simply render that page as an unstyled basic HTML page.
|
||||
|
||||
## 4. Add a configuration file
|
||||
|
||||
Add a `_config.yml` file in your root directory. In `_config.yml`, you can optionally specify the markdown filter you want. By default, [kramdown](https://kramdown.gettalong.org/) is used (without the need to specify it). If no other filter is specified, your config file will automatically apply the following as a default setting:
|
||||
|
||||
```
|
||||
markdown: kramdown
|
||||
```
|
||||
|
||||
You can also specify [some options](https://kramdown.gettalong.org/converter/html.html) for kramdown to make it behave more like [GitHub Flavored Markdown (GFM)](https://github.github.com/gfm/):
|
||||
|
||||
```
|
||||
kramdown:
|
||||
input: GFM
|
||||
auto_ids: true
|
||||
hard_wrap: false
|
||||
syntax_highlighter: rouge
|
||||
```
|
||||
|
||||
## 5. Test your pages
|
||||
|
||||
Now run `jekyll serve` and toggle between your `index.html` and `about.html` pages. The default layout should load for both pages.
|
||||
|
||||
You've now extracted your content out into separate files and defined a common layout for pages.
|
||||
|
||||
You could define any number of layouts you want for pages. Then just identify the layout you want that particular page to use. For example:
|
||||
|
||||
```
|
||||
---
|
||||
title: Sample page
|
||||
layout: homepage
|
||||
---
|
||||
```
|
||||
|
||||
This page would then use the `homepage.html` template in the `_layouts` folder.
|
||||
|
||||
You can even set [default front matter tags]({% link _docs/configuration.md %}#front-matter-defaults) for pages, posts, or [collections]({% link _docs/collections.md %}) in your `_config.yml` file so that you don't have to specify the layout in the front matter variables. Anywayd, setting defaults is beyond the scope of this tutorial, let's get back to work.
|
||||
|
||||
## 6. Configure site variables
|
||||
|
||||
You already configured the page title using `{% raw %}{{ page.title }}{% endraw %}` tags. But there are more `title` tags to populate. Pages also have a [`title`](https://moz.com/learn/seo/title-tag) tag that appears in the browser tab or window. Typically you put the page title followed by the site title here.
|
||||
|
||||
In your `default.html` layout, look for the `title` tags below your `head` tags:
|
||||
|
||||
```
|
||||
<title>ACME Website</title>
|
||||
```
|
||||
|
||||
Insert the following site variables:
|
||||
|
||||
```
|
||||
{% raw %}<title>{{ page.title }} | {{ site.title }}</title>{% endraw %}
|
||||
```
|
||||
|
||||
Open `_config.yml` and add a `title` property for your site's name.
|
||||
|
||||
```
|
||||
title: ACME Website
|
||||
```
|
||||
|
||||
Any properties you add in your `_config.yml` file are accessible through the `site` namespace. Similarly, any properties in your page's front matter are accessible through the `page` namespace. Use dot notation after `site` or `page` to access the value.
|
||||
|
||||
Stop your Jekyll server with <kbd>Ctrl</kbd> + <kbd>C</kbd> and restart it. Verify that the `title` tags are populating correctly.
|
||||
|
||||
{: .note .info}
|
||||
Every time you modify your config file, you have to restart Jekyll for the changes to take effect. When you modify other files, Jekyll automatically picks up the changes when it rebuilds.
|
||||
|
||||
If you have other variables to populate in your site, rinse and repeat.
|
||||
|
||||
## 7. Show posts on a page
|
||||
|
||||
It's common to show a list of posts on the homepage. First, let's create some posts so that we have something to showcase.
|
||||
|
||||
Add some posts in a `_posts` folder following the standard `YYYY-MM-DD-title.md` post format:
|
||||
|
||||
* `2017-01-02-my-first-post.md`
|
||||
* `2017-01-15-my-second-post.md`
|
||||
* `2017-02-08-my-third-post.md`
|
||||
|
||||
In each post, add some basic content:
|
||||
|
||||
```
|
||||
---
|
||||
title: My First Post
|
||||
layout: default
|
||||
---
|
||||
|
||||
Some sample content...
|
||||
```
|
||||
|
||||
Now let's create a layout that will display the posts. Create a new file in `_layouts` called `home.html` and add the following logic:
|
||||
|
||||
```
|
||||
---
|
||||
layout: default
|
||||
---
|
||||
|
||||
{% raw %}{{ content }}
|
||||
<ul class="myposts">
|
||||
{% for post in site.posts %}
|
||||
<li><a href="{{ post.url }}">{{ post.title}}</a>
|
||||
<span class="postDate">{{ post.date | date: "%b %-d, %Y" }}</span>
|
||||
</li>
|
||||
{% endfor %}
|
||||
</ul>{% endraw %}
|
||||
```
|
||||
|
||||
Create a file called `blog.md` in your root directory and specify the `home` layout:
|
||||
|
||||
```
|
||||
---
|
||||
title: Blog
|
||||
layout: home
|
||||
---
|
||||
```
|
||||
|
||||
In this case, contents of `blog.md` will be pushed into the `{% raw %}{{ content }}{% endraw %}` tag in the `home` layout. Then the `home` layout will be pushed into the `{% raw %}{{ content }}{% endraw %}` tag of the `default` layout.
|
||||
|
||||
|
||||
### How layouts work
|
||||
|
||||
When a layout specifies another layout, it means the content of the first layout will be stuffed into the `{% raw %}{{ content }}{% endraw %}` tag of the second layout. As an analogy, think of Russian dolls that fit into each other. Each layout fits into another layout that it specifies.
|
||||
|
||||
The following diagram shows how layouts work in Jekyll:
|
||||
|
||||
<img src="../../img/jekylllayoutconcept.png" alt="Concept of Jekyll layouts" />
|
||||
|
||||
{: .image-description}
|
||||
In this example, the content from a Markdown document `document.md` that specifies `layout: docs` gets pushed into the `{% raw %}{{ content }}{% endraw %}` tag of the layout file `docs.html`. Because the `docs` layout itself specifies `layout: page`, the content from `docs.html` gets pushed into the `{% raw %}{{ content }}{% endraw %}` tag in the layout file `page.html`. Finally because the `page` layout specifies `layout: default`, the content from `page.html` gets pushed into the `{% raw %}{{ content }}{% endraw %}` tag of the layout file `default.html`.
|
||||
|
||||
You don't need multiple layouts. You could just use one: `default`. You have options for how you design your site. In general, it's common to define one layout for pages and another layout for posts, but for both of these layouts to inherit the `default` template (which usually defines the top and bottom parts of the site).
|
||||
|
||||
In your browser, go to `blog.html` and see the list of posts.
|
||||
Note that you don't have to use the method described here. You could have simply added the `for` loop to any page, such as `index.md`, to display these posts. But given that you may have more complex logic for other features, it can be helpful to store your logic in templates separate from the page area where you frequently type your content.
|
||||
|
||||
{: .note .info}
|
||||
At minimum, a layout should contain `{% raw %}{{ content }}{% endraw %}`, which acts as a receiver for the *content* to be rendered.
|
||||
|
||||
### For loops
|
||||
|
||||
By the way, let's pause here to look at the `for` loop logic a little more closely. [For loops in Liquid](https://help.shopify.com/themes/liquid/tags/iteration-tags#for) are one of the most commonly used Liquid tags. *For loops* let you iterate through content in your Jekyll site and build out a result. The `for` loop also has [certain properties available](https://help.shopify.com/themes/liquid/objects/for-loops) (like first or last iteration) based on the loop's position in the loop as well.
|
||||
|
||||
We've only scratched the surface of what you can do with `for` loops in retrieving posts. For example, if you wanted to display posts from a specific category, you could do so by adding a `categories` property to your post's front matter and then look in those categories. Further, you could limit the number of results by adding a `limit` property. Here's an example:
|
||||
|
||||
```liquid
|
||||
{% raw %}<ul class="myposts">
|
||||
{% for post in site.categories.podcasts limit:3 %}
|
||||
<li><a href="{{ post.url }}">{{ post.title}}</a>
|
||||
<span class="postDate">{{ post.date | date: "%b %-d, %Y" }}</span>
|
||||
</li>
|
||||
{% endfor %}{% endraw %}
|
||||
```
|
||||
|
||||
This loop would get the latest three posts that have a category called `podcasts` in the front matter.
|
||||
|
||||
## 8. Configure navigation
|
||||
|
||||
Now that you've configured posts, let's configure page navigation. Most websites have some navigation either in the sidebar or header area.
|
||||
|
||||
In this tutorial, we'll assume you've got a simple list of pages you want to generate. If you only have a handful of pages, you could list them by using a `for` loop to iterate through the `site.pages` object and then order them by a front matter property.
|
||||
|
||||
Identify the part of your code where the list of pages appears. Usually this is a `<ul>` element with various child `<li>` elements. Replace the code with the following:
|
||||
|
||||
```html
|
||||
{% raw %}<ul>
|
||||
{% assign mypages = site.pages | sort: "order" %}
|
||||
{% for page in mypages %}
|
||||
<li><a href="{{ page.url | absolute_url }}">{{ page.title }}</a></li>
|
||||
{% endfor %}
|
||||
</ul>{% endraw %}
|
||||
```
|
||||
|
||||
This example assumes each page would have front matter containing both a `title` and `order` property like this:
|
||||
|
||||
```
|
||||
---
|
||||
title: My page
|
||||
order: 2
|
||||
---
|
||||
```
|
||||
|
||||
Here the `order` property will define how the pages get sorted, with `1` appearing first in the list.
|
||||
|
||||
You could also iterate through a list of pages that you maintain in a separate data file. This might be more appropriate if you have a lot of pages, or you have other properties about the pages you want to store.
|
||||
|
||||
To manage page links this way, create a folder in your Jekyll project called `_data`. In this folder, create a file called e.g. `navigation.yml` with this content:
|
||||
|
||||
```yaml
|
||||
- title: Sample page 1
|
||||
url: /page-1-permalink/
|
||||
|
||||
- title: Sample page 2
|
||||
url: /page-2-permalink/
|
||||
|
||||
- title: Sample page 3
|
||||
url: /page-3-permalink/
|
||||
```
|
||||
|
||||
{: .note .info}
|
||||
If you never wrote any YAML before, you'll get quickly familiar with it. Take a look at [what you can do with YAML](https://learnxinyminutes.com/docs/yaml/).
|
||||
|
||||
You can store additional properties for each item in this data file as desired. Arrange the list items in the order you want them to appear.
|
||||
|
||||
To print the list of pages from the data file, use code like this:
|
||||
|
||||
```html
|
||||
{% raw %}<ul>
|
||||
{% for link in site.data.navigation %}
|
||||
<li><a href="{{ link.url }}">{{ link.title }}</a></li>
|
||||
{% endfor %}
|
||||
</ul>{% endraw %}
|
||||
```
|
||||
|
||||
If you have more sophisticated requirements around navigation, such as when building a documentation site, see the [detailed tutorial on navigation](/tutorials/navigation/).
|
||||
|
||||
## 9. Simplify your site with includes
|
||||
|
||||
Let's suppose your `default.html` file is massive and hard to work with. You can break up your layout by putting some of the HTML code in *include* files.
|
||||
|
||||
Add a folder called `_includes` in your root directory. In that folder, add a file there called `sidebar.html`.
|
||||
|
||||
Remove your sidebar code from your `default.html` layout and insert it into the `sidebar.html` file.
|
||||
|
||||
Where the sidebar code previously existed in `default.html`, pull in your "include" like this:
|
||||
|
||||
```liquid
|
||||
{% raw %}{% include sidebar.html %}{% endraw %}
|
||||
```
|
||||
|
||||
You can break up other elements of your theme like this, such as your header or footer. Then you can apply these common elements to other layout files. This way you won't have duplicate code.
|
||||
|
||||
## 10. RSS feed
|
||||
|
||||
Your Jekyll site needs an RSS feed. Here's the [basic RSS feed syntax](http://www.w3schools.com/xml/xml_rss.asp). To create an RSS file in Jekyll, create a file called `feed.xml` in your root directory and add the following:
|
||||
|
||||
```xml
|
||||
---
|
||||
layout: null
|
||||
---
|
||||
|
||||
{% raw %}<?xml version="1.0" encoding="UTF-8" ?>
|
||||
<rss version="2.0">
|
||||
|
||||
<channel>
|
||||
<title>{{ site.title }}</title>
|
||||
<link>{{ site.url }}</link>
|
||||
<description>{{ site.description }}</description>
|
||||
<lastBuildDate>{{ site.time | date_to_rfc822 }}</lastBuildDate>
|
||||
{% for post in site.posts %}
|
||||
<item>
|
||||
<description>
|
||||
{{ post.content | escape | truncate: '400' }}
|
||||
</description>
|
||||
<pubDate>{{ post.date | date_to_rfc822 }}</pubDate>
|
||||
<guid>
|
||||
{{ post.url | prepend: site.url }}
|
||||
</guid>
|
||||
</item>
|
||||
{% endfor %}
|
||||
</channel>
|
||||
</rss>{% endraw %}
|
||||
```
|
||||
|
||||
Make sure your `_config.yml` file has properties for `title`, `url`, and `description`.
|
||||
|
||||
This code uses a `for` loop to look through your last 20 posts. The content from the posts gets escaped and truncated to the last 400 characters using [Liquid filters](https://help.shopify.com/themes/liquid/filters).
|
||||
|
||||
In your `default.html` layout, look for a reference to the RSS or Atom feed in your header, and replace it with a reference to the file you just created. For example:
|
||||
|
||||
```html
|
||||
<link rel="alternate" type="application/rss+xml" href="{% raw %}{{ site.url }}{% endraw %}/feed.xml" title="{% raw %}{{ site.title }}{% endraw %}">
|
||||
```
|
||||
|
||||
You can also auto-generate your posts feed by adding a gem called [`jekyll-feed`][jekyll-feed]. This gem will also work on GitHub Pages.
|
||||
|
||||
## 11. Add a sitemap
|
||||
|
||||
Finally, add a [site map](https://www.sitemaps.org/protocol.html). Create a `sitemap.xml` file in your root directory and add this code:
|
||||
|
||||
```xml
|
||||
---
|
||||
layout: null
|
||||
search: exclude
|
||||
---
|
||||
|
||||
{% raw %}<?xml version="1.0" encoding="UTF-8"?>
|
||||
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
|
||||
|
||||
{% for page in site.pages %}
|
||||
<url>
|
||||
<loc>{{page.url}}</loc>
|
||||
<lastmod>{{site.time | date: '%Y-%m-%d' }}</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
<priority>0.5</priority>
|
||||
</url>
|
||||
{% endfor %}
|
||||
|
||||
{% for post in site.posts %}
|
||||
<url>
|
||||
<loc>{{post.url}}</loc>
|
||||
<lastmod>{{site.time | date: '%Y-%m-%d' }}</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
<priority>0.5</priority>
|
||||
</url>
|
||||
{% endfor %}
|
||||
|
||||
</urlset>{% endraw %}
|
||||
```
|
||||
|
||||
Again, we're using a `for` loop here to iterate through all posts and pages to add them to the sitemap.
|
||||
|
||||
You can also auto-generate your sitemap by adding a gem called [`jekyll-sitemap`][jekyll-sitemap]. This gem will also work on GitHub Pages.
|
||||
|
||||
## 12. Add external services
|
||||
|
||||
For other services you might need (such as contact forms, search, comments, and more), look for third-party services. For example, you might use the following:
|
||||
|
||||
* For comments: [Disqus](https://disqus.com/)
|
||||
* For a newsletter: [Tinyletter](https://tinyletter.com/)
|
||||
* For contact forms: [Wufoo](https://www.wufoo.com/)
|
||||
* For search: [Algolia Docsearch](https://community.algolia.com/docsearch/)
|
||||
|
||||
For more details on services for static sites, see the [Third Parties](https://learn.cloudcannon.com/jekyll-third-parties/) list and tutorials from CloudCannon.
|
||||
|
||||
Your Jekyll pages consist of HTML, CSS, and JavaScript, so pretty much any code you need to embed will work without a problem.
|
||||
|
||||
As you integrate code for these services, note that **if a page in your Jekyll site doesn't have front matter tags, Jekyll won't process any of the content in that page.** The page will just be passed to the `_site` folder when you build your site.
|
||||
|
||||
If you do want Jekyll to process some page content (for example, to populate a variable that you define in your site's config file), just add front matter tags to the page. If you don't want any layout applied to the page, specify `layout: null` like this:
|
||||
|
||||
```
|
||||
---
|
||||
layout: null
|
||||
---
|
||||
```
|
||||
|
||||
## 13. Conclusion
|
||||
|
||||
Although websites can implement more sophisticated features and functionality, we've covered the basics in this tutorial. You now have a fully functional Jekyll site.
|
||||
|
||||
To deploy your site, consider using [GitHub Pages](https://pages.github.com/), [Netlify](https://www.netlify.com/), [Amazon AWS S3](https://aws.amazon.com/s3/) using the [s3_website plugin](https://github.com/laurilehmijoki/s3_website), or just FTP your files to your web server.
|
||||
|
||||
You can also package your layouts, includes and assets into a Ruby `gem` and [make it a Jekyll theme]({% link _docs/themes.md %}#creating-a-theme).
|
||||
|
||||
## Additional resources
|
||||
|
||||
Here are some additional tutorials on creating Jekyll sites:
|
||||
|
||||
* [Convert a static site to Jekyll](http://jekyll.tips/jekyll-casts/converting-a-static-site-to-jekyll/)
|
||||
* [Building a Jekyll Site – Part 1 of 3: Converting a Static Website To Jekyll](https://css-tricks.com/building-a-jekyll-site-part-1-of-3/)
|
||||
|
||||
[jekyll-sitemap]: https://help.github.com/articles/sitemaps-for-github-pages/
|
||||
[jekyll-feed]: https://help.github.com/articles/atom-rss-feeds-for-github-pages/
|
||||
@@ -1,66 +0,0 @@
|
||||
---
|
||||
layout: tutorials
|
||||
permalink: /tutorials/custom-404-page/
|
||||
title: Custom 404 Page
|
||||
---
|
||||
|
||||
You can easily serve custom 404 error pages with Jekyll to replace the default **Error 404 -- File Not Found** page displayed when one tries to access a broken link on your site.
|
||||
|
||||
|
||||
## On GitHub Pages
|
||||
|
||||
Any `404.html` at the **root of your `_site` directory** will be served automatically by GitHub Pages and the local WEBrick development server.
|
||||
|
||||
Simply add a `404.md` or `404.html` at the root of your site's source directory and include the YAML Front Matter data to use the theme's base layout.
|
||||
|
||||
If you plan to organize your files under subdirectories, the error page should have the following Front Matter Data, set: `permalink: /404.html`. This is to ensure that the compiled `404.html` resides at the root of your processed site, where it'll be picked by the server.
|
||||
|
||||
```
|
||||
---
|
||||
# example 404.md
|
||||
|
||||
layout: default
|
||||
permalink: /404.html
|
||||
---
|
||||
|
||||
# 404
|
||||
|
||||
Page not found! :(
|
||||
```
|
||||
|
||||
## Hosting on Apache Web Servers
|
||||
|
||||
Apache Web Servers load a configuration file named [`.htaccess`](http://www.htaccess-guide.com/) that modifies the functionality of these servers.
|
||||
|
||||
Simply add the following to your `.htaccess` file.
|
||||
|
||||
```
|
||||
ErrorDocument 404 /404.html
|
||||
```
|
||||
|
||||
With an `.htaccess` file, you have the freedom to place your error page within a subdirectory.
|
||||
|
||||
```
|
||||
ErrorDocument 404 /error_pages/404.html
|
||||
```
|
||||
|
||||
Where the path is relative to your site's domain.
|
||||
|
||||
More info on configuring Apache Error Pages can found in [official documentation](https://httpd.apache.org/docs/current/mod/core.html#errordocument).
|
||||
|
||||
|
||||
## Hosting on Nginx server
|
||||
|
||||
The procedure is just as simple as configuring Apache servers, but slightly different.
|
||||
|
||||
Add the following to the nginx configuration file, `nginx.conf`, which is usually located inside `/etc/nginx/` or `/etc/nginx/conf/`:
|
||||
|
||||
```
|
||||
server {
|
||||
error_page 404 /404.html;
|
||||
location /404.html {
|
||||
internal;
|
||||
}
|
||||
}
|
||||
```
|
||||
The `location` directive prevents users from directly browsing the 404.html page.
|
||||
@@ -1,35 +0,0 @@
|
||||
---
|
||||
layout: tutorials
|
||||
title: Tutorials
|
||||
permalink: /tutorials/home/
|
||||
redirect_from: /tutorials/index.html
|
||||
---
|
||||
|
||||
In contrast to [Docs](/docs/home/), Tutorials provide more detailed, narrative instruction that cover a variety of Jekyll topics and scenarios. Tutorials might contain the following:
|
||||
|
||||
* Step-by-step processes through particular scenarios or challenges
|
||||
* Full walk-throughs using sample data, showing inputs and results from the sample data
|
||||
* Detailed explanation about the pros and cons for different Jekyll strategies
|
||||
* End-to-end instruction in developing a complete feature on a Jekyll site
|
||||
* Instruction that combines various techniques from across the docs
|
||||
|
||||
In short, tutorials aren't the core reference information in docs. They walk users through processes from beginning to end.
|
||||
|
||||
{: .info .note}
|
||||
**Note:** The Tutorials section is new, so there aren't many tutorials yet. You can add a tutorial here to help populate this section.
|
||||
|
||||
Some of these techniques might even guide you through a supporting tool, script, service, or other hack used with your Jekyll site. Feel free to include tutorials involving external services with Jekyll as well. However, note that Jekyll in no way endorses any third-party tools mentioned in tutorials.
|
||||
|
||||
## How to contribute a tutorial
|
||||
|
||||
We welcome your tutorial contributions. To add your tutorial:
|
||||
|
||||
1. Fork the Jekyll project by clicking the **Fork** button in the upper-right corner of the [jekyll/jekyll project Github repo](https://github.com/jekyll/jekyll/).
|
||||
2. Add your tutorial in the `_tutorials` collection.
|
||||
3. Make sure your tutorial has the same front matter items as other tutorial items.
|
||||
5. Add a reference to your tutorial filename in `_data/tutorials.yml`. This allows your tutorial to appear in the Tutorials sidebar.
|
||||
6. Follow the regular git workflow to submit the pull request.
|
||||
|
||||
When you submit your pull request, the Jekyll documentation team will review your contribution and either merge it or suggest edits.
|
||||
|
||||
|
||||
@@ -1,579 +0,0 @@
|
||||
---
|
||||
layout: tutorials
|
||||
permalink: /tutorials/navigation/
|
||||
title: Navigation
|
||||
---
|
||||
|
||||
If your Jekyll site has a lot of pages, you might want to create navigation for the pages. Instead of hard-coding navigation links, you can programmatically retrieve a list of pages to build the navigation for your site.
|
||||
|
||||
Although there's already information about [interacting with data files]({% link _docs/datafiles.md %}) in other Jekyll docs, this tutorial dives into building more robust navigation for your site.
|
||||
|
||||
There are two primary ways of retrieving pages on a Jekyll site:
|
||||
|
||||
* **Retrieve pages listed in a YAML data source**. Store the page data in a YAML (or JSON or CSV) file in the `_data` folder, loop through the YAML properties, and insert the values into your theme.
|
||||
* **Retrieve pages by looping through the page front matter**. Look through the front matter of your pages to identify certain properties, return those pages, and insert the pages' front matter values into your theme.
|
||||
|
||||
The examples that follow start with a basic navigation scenario and add more sophisticated elements to demonstrate different ways of returning the pages. In every scenario, you'll see 3 elements:
|
||||
|
||||
* YAML
|
||||
* Liquid
|
||||
* Result
|
||||
|
||||
The YAML file in the `_data` directory is called `samplelist.yml`.
|
||||
|
||||
The scenarios are as follows:
|
||||
|
||||
* TOC
|
||||
{:toc}
|
||||
|
||||
## Scenario 1: Basic List
|
||||
|
||||
You want to return a basic list of pages.
|
||||
|
||||
**YAML**
|
||||
|
||||
```yaml
|
||||
docs_list_title: ACME Documentation
|
||||
docs:
|
||||
|
||||
- title: Introduction
|
||||
url: introduction.html
|
||||
|
||||
- title: Configuration
|
||||
url: configuration.html
|
||||
|
||||
- title: Deployment
|
||||
url: deployment.html
|
||||
```
|
||||
|
||||
**Liquid**
|
||||
|
||||
```liquid
|
||||
{% raw %}<h2>{{ site.data.samplelist.docs_list_title }}</h2>
|
||||
<ul>
|
||||
{% for item in site.data.samplelist.docs %}
|
||||
<li><a href="{{ item.url }}" alt="{{ item.title }}">{{ item.title }}</a></li>
|
||||
{% endfor %}
|
||||
</ul>{% endraw %}
|
||||
```
|
||||
|
||||
**Result**
|
||||
<div class="highlight result">
|
||||
<h2>ACME Documentation</h2>
|
||||
<ul>
|
||||
<li><a href="#" alt="Introduction">Introduction</a></li>
|
||||
<li><a href="#" alt="Configuration">Configuration</a></li>
|
||||
<li><a href="#" alt="Deployment">Deployment</a></li>
|
||||
</ul>
|
||||
</div>
|
||||
|
||||
{: .note .info }
|
||||
For the results in these fictitious samples, `#` is manually substituted for the actual link value to avoid 404 errors.)
|
||||
|
||||
When you use a `for` loop, you choose how you want to refer to the items you're looping through. The variable you choose (in this case, `item`) becomes how you access the properties of each item in the list. Dot notation is used to get a property of the item (for example, `item.url`).
|
||||
|
||||
The YAML content has two main types of formats that are relevant here:
|
||||
|
||||
* mapping
|
||||
* list
|
||||
|
||||
`docs_list_title: ACME Documentation` is a mapping. You access the value with `site.data.samplelist.docs_list_title`.
|
||||
|
||||
`docs:` is a list. The list begins each item with a hyphen. Unlike with mappings, you usually don't access list properties directly as you do with mappings. If you want to access a specific item in the list, you must identify the position in the list you want, following typical array notation. For example, `site.data.samplelist.docs[0]` would access the first item in the list. However, this is rarely done.
|
||||
|
||||
With lists, you usually use `for` loops to cycle through the list of items and do something with each item. With navigation menus, you usually insert each list item into `li` tags based on the navigation structure you're using in your HTML theme.
|
||||
|
||||
Each hyphen (`-`) indicates another item in the list. This example just has two properties with each list item: `title` and `url`. You can include as many properties as you want for each item. The order of properties at each position in the list doesn't matter.
|
||||
|
||||
## Scenario 2: Sorted list
|
||||
|
||||
Suppose you wanted to sort the list by the `title`. To do this, convert the reference to the `docs` collection to a variable, and then apply Liquid's `sort` filter to the variable:
|
||||
|
||||
**Liquid**
|
||||
|
||||
```liquid
|
||||
{% raw %}{% assign doclist = site.data.samplelist.docs | sort: 'title' %}
|
||||
{% for item in doclist %}
|
||||
<li><a href="{{ item.url }}" alt="{{ item.title }}">{{ item.title }}</a></li>
|
||||
{% endfor %}{% endraw %}
|
||||
```
|
||||
|
||||
**Result**
|
||||
|
||||
<div class="highlight result">
|
||||
<li><a href="#" alt="Configuration">Configuration</a></li>
|
||||
<li><a href="#" alt="Deployment">Deployment</a></li>
|
||||
<li><a href="#" alt="Introduction">Introduction</a></li>
|
||||
</div>
|
||||
|
||||
The items now appear in alphabetical order. The `sort` property in the Liquid filter applies to the `title`, which is an actual property in the list. If `title` weren't a property, we would need to sort by another property.
|
||||
|
||||
See the [Liquid array filter](https://help.shopify.com/themes/liquid/filters/array-filters) for more filter options. Note that you can't simply use this syntax:
|
||||
|
||||
```liquid
|
||||
{% raw %}{% for item in site.data.samplelist.docs | sort: "title" %}{% endfor %}{% endraw %}
|
||||
```
|
||||
|
||||
You have to convert `site.data.samplelist.docs` to a variable first using either `assign` or `capture` tags.
|
||||
|
||||
## Scenario 3: Two-level navigation list
|
||||
|
||||
Suppose you want a more robust list that incorporates multiple sections of heading titles and subitems. To do this, add an additional level to each list item to store this information:
|
||||
|
||||
**YAML**
|
||||
|
||||
```yaml
|
||||
toc:
|
||||
- title: Group 1
|
||||
subfolderitems:
|
||||
- page: Thing 1
|
||||
url: /thing1.html
|
||||
- page: Thing 2
|
||||
url: /thing2.html
|
||||
- page: Thing 3
|
||||
url: /thing3.html
|
||||
- title: Group 2
|
||||
subfolderitems:
|
||||
- page: Piece 1
|
||||
url: /piece1.html
|
||||
- page: Piece 2
|
||||
url: /piece2.html
|
||||
- page: Piece 3
|
||||
url: /piece3.html
|
||||
- title: Group 3
|
||||
subfolderitems:
|
||||
- page: Widget 1
|
||||
url: /widget1.html
|
||||
- page: Widget 2
|
||||
url: /widget2.html
|
||||
- page: Widget 3
|
||||
url: /widget3.html
|
||||
```
|
||||
|
||||
**Liquid**
|
||||
|
||||
```liquid
|
||||
{% raw %}{% for item in site.data.samplelist.toc %}
|
||||
<h3>{{ item.title }}</h3>
|
||||
<ul>
|
||||
{% for entry in item.subfolderitems %}
|
||||
<li><a href="{{ entry.url }}">{{ entry.page }}</a></li>
|
||||
{% endfor %}
|
||||
</ul>
|
||||
{% endfor %}{% endraw %}
|
||||
```
|
||||
|
||||
**Result**
|
||||
<div class="highlight result">
|
||||
<h3>Group 1</h3>
|
||||
<ul>
|
||||
<li><a href="#">Thing 1</a></li>
|
||||
<li><a href="#">Thing 2</a></li>
|
||||
<li><a href="#">Thing 3</a></li>
|
||||
</ul>
|
||||
|
||||
<h3>Group 2</h3>
|
||||
<ul>
|
||||
<li><a href="#">Piece 1</a></li>
|
||||
<li><a href="#">Piece 2</a></li>
|
||||
<li><a href="#">Piece 3</a></li>
|
||||
</ul>
|
||||
|
||||
<h3>Group 3</h3>
|
||||
<ul>
|
||||
<li><a href="#">Widget 1</a></li>
|
||||
<li><a href="#">Widget 2</a></li>
|
||||
<li><a href="#">Widget 3</a></li>
|
||||
</ul>
|
||||
</div>
|
||||
|
||||
In this example, `Group 1` is the first list item. Within that list item, its subpages are included as a property that itself contains a list (`subfolderitems`).
|
||||
|
||||
The Liquid code looks through the first level with `for item in site.data.samplelist.toc`, and then looks through the second-level property with `for entry in item.subfolderitems`. Just as `item` is an arbitrary name for the items we're looping through, so is `entry`.
|
||||
|
||||
## Scenario 4: Three-level navigation list
|
||||
|
||||
Building on the previous section, let's add one more level of depth (`subsubfolderitems`) to the list. The formatting will get more complex here, but the principles are the same.
|
||||
|
||||
**YAML**
|
||||
|
||||
```yaml
|
||||
toc2:
|
||||
- title: Group 1
|
||||
subfolderitems:
|
||||
- page: Thing 1
|
||||
url: /thing1.html
|
||||
- page: Thing 2
|
||||
url: /thing2.html
|
||||
subsubfolderitems:
|
||||
- page: Subthing 1
|
||||
url: /subthing1.html
|
||||
- page: Subthing 2
|
||||
url: /subthing2.html
|
||||
- page: Thing 3
|
||||
url: /thing3.html
|
||||
- title: Group 2
|
||||
subfolderitems:
|
||||
- page: Piece 1
|
||||
url: /piece1.html
|
||||
- page: Piece 2
|
||||
url: /piece2.html
|
||||
- page: Piece 3
|
||||
url: /piece3.html
|
||||
subsubfolderitems:
|
||||
- page: Subpiece 1
|
||||
url: /subpiece1.html
|
||||
- page: Subpiece2
|
||||
url: /subpiece2.html
|
||||
- title: Group 3
|
||||
subfolderitems:
|
||||
- page: Widget 1
|
||||
url: /widget1.html
|
||||
subsubfolderitems:
|
||||
- page: Subwidget 1
|
||||
url: /subwidget1.html
|
||||
- page: Subwidget 2
|
||||
url: /subwidget2.html
|
||||
- page: Widget 2
|
||||
url: /widget2.html
|
||||
- page: Widget 3
|
||||
url: /widget3.html
|
||||
```
|
||||
|
||||
**Liquid**
|
||||
|
||||
```liquid
|
||||
{% raw %}<div>
|
||||
{% if site.data.samplelist.toc2[0] %}
|
||||
{% for item in site.data.samplelist.toc2 %}
|
||||
<h3>{{ item.title }}</h3>
|
||||
{% if item.subfolderitems[0] %}
|
||||
<ul>
|
||||
{% for entry in item.subfolderitems %}
|
||||
<li><a href="{{ entry.url }}">{{ entry.page }}</a></li>
|
||||
{% if entry.subsubfolderitems[0] %}
|
||||
<ul>
|
||||
{% for subentry in entry.subsubfolderitems %}
|
||||
<li><a href="{{ subentry.url }}">{{ subentry.page }}</a></li>
|
||||
{% endfor %}
|
||||
</ul>
|
||||
{% endif %}
|
||||
{% endfor %}
|
||||
</ul>
|
||||
{% endif %}
|
||||
{% endfor %}
|
||||
{% endif %}
|
||||
</div>{% endraw %}
|
||||
```
|
||||
|
||||
**Result**
|
||||
|
||||
<div class="highlight result">
|
||||
<div>
|
||||
<h3>Group 1</h3>
|
||||
<ul>
|
||||
<li><a href="#">Thing 1</a></li>
|
||||
<li><a href="#">Thing 2</a></li>
|
||||
<ul>
|
||||
<li><a href="#">Subthing 1</a></li>
|
||||
<li><a href="#">Subthing 2</a></li>
|
||||
</ul>
|
||||
<li><a href="#">Thing 3</a></li>
|
||||
</ul>
|
||||
<h3>Group 2</h3>
|
||||
<ul>
|
||||
<li><a href="#">Piece 1</a></li>
|
||||
<li><a href="#">Piece 2</a></li>
|
||||
<li><a href="#">Piece 3</a></li>
|
||||
<ul>
|
||||
<li><a href="#">Subpiece 1</a></li>
|
||||
<li><a href="#">Subpiece2</a></li>
|
||||
</ul>
|
||||
</ul>
|
||||
<h3>Group 3</h3>
|
||||
<ul>
|
||||
<li><a href="#">Widget 1</a></li>
|
||||
<ul>
|
||||
<li><a href="#">Subwidget 1</a></li>
|
||||
<li><a href="#">Subwidget 2</a></li>
|
||||
</ul>
|
||||
<li><a href="#">Widget 2</a></li>
|
||||
<li><a href="#">Widget 3</a></li>
|
||||
</ul>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
In this example, `if site.data.samplelist.toc2[0]` is used to ensure that the YAML level actually contains items. If there isn't anything at the `[0]` position, we can skip looking in this level.
|
||||
|
||||
<div class="note">
|
||||
<h5>ProTip: Line up <code>for</code> loops and <code>if</code> statements</h5>
|
||||
<p>To keep the code clear, line up the beginning and ending Liquid tags, such as the <code>for</code> loops and <code>if</code> statements. This way you know when the open tags have been closed. If the code will appear in a Markdown page, keep the opening and closing HTML tags flush against the left edge so that the Markdown filter won't treat the content as a code sample. If necessary, you can wrap the entire code sample in a <code>div</code> tag to ensure the code has HTML tags that bookend the code.</p>
|
||||
</div>
|
||||
|
||||
## Scenario 5: Using a page variable to select the YAML list
|
||||
|
||||
Suppose your sidebar will differ based on various documentation sets. You might have 3 different products on your site, and so you want 3 different sidebars — each unique for that product.
|
||||
|
||||
You can store the name of the sidebar list in your page front matter and then pass that value into the list dynamically.
|
||||
|
||||
**Page front matter**
|
||||
|
||||
```yaml
|
||||
---
|
||||
title: My page
|
||||
sidebar: toc
|
||||
---
|
||||
```
|
||||
|
||||
**Liquid**
|
||||
|
||||
```liquid
|
||||
{% raw %}<ul>
|
||||
{% for item in site.data.samplelist[page.sidebar] %}
|
||||
<li><a href="{{ item.url }}">{{ item.title }}</a></li>
|
||||
{% endfor %}
|
||||
</ul>{% endraw %}
|
||||
```
|
||||
**Result**
|
||||
|
||||
<div class="highlight result">
|
||||
<ul>
|
||||
<li><a href="#">Introduction</a></li>
|
||||
<li><a href="#">Configuration</a></li>
|
||||
<li><a href="#">Deployment</a></li>
|
||||
</ul>
|
||||
</div>
|
||||
|
||||
In this scenario, we want to pass values from the page's front matter into a `for` loop that contains a variable. When the assigned variable isn't a string but rather a data reference, you must use brackets (instead of curly braces) to refer to the front matter's value.
|
||||
|
||||
For more information, see [Expressions and Variables](https://github.com/Shopify/liquid/wiki/Liquid-for-Designers#expressions-and-variables) in Liquid's documentation. Brackets are used in places where dot notation can't be used. You can also read more details in this [Stack Overflow answer](http://stackoverflow.com/questions/4968406/javascript-property-access-dot-notation-vs-brackets/4968448#4968448).
|
||||
|
||||
## Scenario 6: Applying the active class for the current page
|
||||
|
||||
In addition to inserting items from the YAML data file into your list, you also usually want to highlight the current link if the user is viewing that page. You do this by inserting an `active` class for items that match the current page URL.
|
||||
|
||||
**CSS**
|
||||
```css
|
||||
.result li.active a {
|
||||
color: lightgray;
|
||||
cursor: default;
|
||||
}
|
||||
```
|
||||
**Liquid**
|
||||
|
||||
```liquid
|
||||
{% raw %}{% for item in site.data.samplelist.docs %}
|
||||
<li class="{% if item.url == page.url %}active{% endif %}">
|
||||
<a href="{{ item.url }}">{{ item.title }}</a>
|
||||
</li>
|
||||
{% endfor %}{% endraw %}
|
||||
```
|
||||
|
||||
**Result**
|
||||
|
||||
<style>
|
||||
.result li.active a {
|
||||
color: lightgray;
|
||||
cursor: default;
|
||||
}
|
||||
</style>
|
||||
|
||||
<div class="highlight result">
|
||||
<li class=""><a href="#">Introduction</a></li>
|
||||
<li class=""><a href="#">Configuration</a></li>
|
||||
<li class="active"><a href="#">Deployment</a></li>
|
||||
</div>
|
||||
|
||||
In this case, assume `Deployment` is the current page.
|
||||
|
||||
To make sure the `item.url` (stored in the YAML file) matches the `page.url`, it can be helpful to print the `{% raw %}{{ page.url }}{% endraw %}` to the page.
|
||||
|
||||
## Scenario 6: Including items conditionally
|
||||
|
||||
You might want to include items conditionally in your list. For example, maybe you have multiple site outputs and only want to include the sidebar item for certain outputs. You can add properties in each list item and then use those properties to conditionally include the content.
|
||||
|
||||
**YAML**
|
||||
```yaml
|
||||
docs2_list_title: ACME Documentation
|
||||
docs2:
|
||||
|
||||
- title: Introduction
|
||||
url: introduction.html
|
||||
version: 1
|
||||
|
||||
- title: Configuration
|
||||
url: configuration.html
|
||||
version: 1
|
||||
|
||||
- title: Deployment
|
||||
url: deployment.html
|
||||
version: 2
|
||||
```
|
||||
|
||||
**Liquid**
|
||||
|
||||
```liquid
|
||||
{% raw %}<ul>
|
||||
{% for item in site.data.samplelist.docs2 %}
|
||||
{% if item.version == 1 %}
|
||||
<li><a href="{{ item.url }}">{{ item.title }}</a></li>
|
||||
{% endif %}
|
||||
{% endfor %}
|
||||
</ul>{% endraw %}
|
||||
```
|
||||
|
||||
**Result**
|
||||
|
||||
<div class="highlight result">
|
||||
<ul>
|
||||
<li><a href="#">Introduction</a></li>
|
||||
<li><a href="#">Configuration</a></li>
|
||||
</ul>
|
||||
</div>
|
||||
|
||||
The `Deployment` page is excluded because its `version` is `2`.
|
||||
|
||||
## Scenario 7: Retrieving items based on front matter properties
|
||||
|
||||
If you don't want to store your navigation items in a YAML file in your `_data` folder, you can use `for` loops to look through the YAML front matter of each page or collection and get the content based on properties in the front matter.
|
||||
|
||||
In this scenario, suppose we have a collection called `_docs`. Collections are often better than pages because they allow you to narrow the list of what you're looping through. (Try to avoid scenarios where you loop through large numbers of items, since it will increase your build time. [Collections]({% link _docs/collections.md %}) help you narrow the scope.)
|
||||
|
||||
In our scenario, there are 6 docs in the `docs` collection: Sample 1, Sample 2, Topic 1, Topic 2, Widget 1, and Widget 2.
|
||||
|
||||
Each doc in the collection contains at least 3 properties in the front matter:
|
||||
|
||||
* `title`
|
||||
* `category`
|
||||
* `order`
|
||||
|
||||
The front matter for each page is as follows (consolidated here for brevity):
|
||||
|
||||
```yaml
|
||||
---
|
||||
Title: Sample 1
|
||||
category: getting-started
|
||||
order: 1
|
||||
---
|
||||
|
||||
---
|
||||
Title: Sample 2
|
||||
category: getting-started
|
||||
order: 2
|
||||
---
|
||||
|
||||
---
|
||||
Title: Topic 1
|
||||
category: configuration
|
||||
order: 1
|
||||
---
|
||||
|
||||
---
|
||||
Title: Topic 2
|
||||
category: configuration
|
||||
order: 2
|
||||
---
|
||||
|
||||
---
|
||||
Title: Widget 1
|
||||
category: deployment
|
||||
order: 1
|
||||
---
|
||||
|
||||
---
|
||||
Title: Widget 2
|
||||
category: deployment
|
||||
order: 2
|
||||
---
|
||||
```
|
||||
|
||||
Note that even though `category` is used in the doc front matter, `category` is not a built-in variable like it is with posts. In other words, you cannot look directly inside `category` with `site.docs.category`.
|
||||
|
||||
If you wanted to simply get all docs in the collection for a specific category, you could use a `for` loop with an `if` condition to check for a specific category:
|
||||
|
||||
```liquid
|
||||
{% raw %}<h3>Getting Started</h3>
|
||||
<ul>
|
||||
{% for doc in site.docs %}
|
||||
{% if doc.category == "getting-started" %}
|
||||
<li><a href="{{ doc.url }}">{{ doc.title }}</a></li>
|
||||
{% endif %}
|
||||
{% endfor %}
|
||||
</ul>{% endraw %}
|
||||
```
|
||||
|
||||
The result would be as follows:
|
||||
|
||||
<div class="highlight result">
|
||||
<h3>Getting Started</h3>
|
||||
<ul>
|
||||
<li><a href="#">Sample1</a></li>
|
||||
<li><a href="#">Sample2</a></li>
|
||||
</ul>
|
||||
</div>
|
||||
|
||||
This might be useful if you're setting up a knowledge base and have dozens of topics in each category, with each category displaying on its own page.
|
||||
|
||||
But let's say you want to sort the items by category and group them under the category name, without hard-coding the category names. To achieve this, you could use two filters:
|
||||
|
||||
* `group_by`
|
||||
* `sort`
|
||||
|
||||
Here's the code for getting lists of pages grouped under their corresponding category headers:
|
||||
|
||||
**Liquid**
|
||||
|
||||
```liquid
|
||||
{% raw %}{% assign mydocs = site.docs | group_by: 'category' %}
|
||||
{% for cat in mydocs %}
|
||||
<h2>{{ cat.name | capitalize }}</h2>
|
||||
<ul>
|
||||
{% assign items = cat.items | sort: 'order' %}
|
||||
{% for item in items %}
|
||||
<li><a href="{{ item.url }}">{{ item.title }}</a></li>
|
||||
{% endfor %}
|
||||
</ul>
|
||||
{% endfor %}{% endraw %}
|
||||
```
|
||||
|
||||
**Result**
|
||||
|
||||
<div class="highlight result">
|
||||
<h2>Getting-started</h2>
|
||||
<ul>
|
||||
<li><a href="#">Sample2</a></li>
|
||||
<li><a href="#">Sample1</a></li>
|
||||
</ul>
|
||||
<h2>Configuration</h2>
|
||||
<ul>
|
||||
<li><a href="#">Topic2</a></li>
|
||||
<li><a href="#">Topic1</a></li>
|
||||
</ul>
|
||||
<h2>Deployment</h2>
|
||||
<ul>
|
||||
<li><a href="#">Widget2</a></li>
|
||||
<li><a href="#">Widget1</a></li>
|
||||
</ul>
|
||||
</div>
|
||||
|
||||
Let's walk through the code. First, we assign a variable (`mydocs`) to the collection content (`site.docs`).
|
||||
|
||||
The `group_by` filter groups the collection content by `category`. More specifically, the `group_by` filter converts `mydocs` into an array with `name`, `items`, and `size` properties, somewhat like this:
|
||||
|
||||
```yaml
|
||||
[
|
||||
{"name": "getting-started", "items": [Sample 1, Sample 2],"size": 2},
|
||||
{"name": "configuration", "items": [Topic 1, Topic 2], "size": 2},
|
||||
{"name": "deployment", "items": [Widget 1, Widget 2, "size": 2}
|
||||
]
|
||||
```
|
||||
|
||||
Using `for cat in mydocs`, we look through each item in the `mydocs` array and print the category `name`.
|
||||
|
||||
After getting the category name, we assign the variable `items` for the docs and use the `sort` filter to arrange the docs by their `order` property. The dot notation `cat.items` is used because we're accessing the content in the `items` array. The `sort` filter orders the items by their numbers in ascending order.
|
||||
|
||||
The `for item in items` loop looks through each `item` and gets the `title` and `url` to form the list item link.
|
||||
|
||||
For more details on the `group_by` filter, see [Jekyll's Templates documentation](https://jekyllrb.com/docs/templates/) as well as [this Siteleaf tutorial](https://www.siteleaf.com/blog/advanced-liquid-group-by/). For more details on the `sort` filter, see [sort](https://help.shopify.com/themes/liquid/filters/array-filters#sort) in Liquid's documentation.
|
||||
|
||||
Whether you use properties in your doc's front matter to retrieve your pages or a YAML data file, in both cases you can programmatically build a more robust navigation for your site.
|
||||
@@ -1,143 +0,0 @@
|
||||
---
|
||||
layout: tutorials
|
||||
permalink: /tutorials/orderofinterpretation/
|
||||
title: Order of interpretation
|
||||
---
|
||||
|
||||
Jekyll's main job is to convert your raw text files into a static website. It does this by rendering Liquid, Markdown, and other transforms as it generates the static HTML output.
|
||||
|
||||
In this conversion process, it's important to understand Jekyll's order of interpretation. By "order of interpretation," we mean what gets rendered, in what order, and what rules get applied in converting content.
|
||||
|
||||
If an element isn't converting, you can troubleshoot the problem by analyzing the order of interpretation.
|
||||
|
||||
## Order of interpretations
|
||||
|
||||
Jekyll converts your site in the following order:
|
||||
|
||||
1. **Site variables**. Jekyll looks across your files and populates [site variables]({% link _docs/variables.md %}), such as `site`, `page`, `post`, and collection objects. (From these objects, Jekyll determines the values for permalinks, tags, categories, and other details.)
|
||||
|
||||
2. **Liquid**. Jekyll processes any [Liquid](https://github.com/Shopify/liquid) formatting in pages that contain [front matter]({% link _docs/frontmatter.md %}). You can identify Liquid as follows:
|
||||
* **Liquid tags** start with `{% raw %}{%{% endraw %}` and end with a `{% raw %}%}{% endraw %}`. For example: `{% raw %}{% highlight %}{% endraw %}` or `{% raw %}{% seo %}{% endraw %}`. Tags can define blocks or be inline. Block-defining tags will also come with a corresponding end tag — for example, `{% raw %}{% endhighlight %}{% endraw %}`.
|
||||
* **Liquid variables** start and end with double curly braces. For example: `{% raw %}{{ site.myvariable }}{% endraw %}` or `{% raw %}{{ content }}{% endraw %}`.
|
||||
* **Liquid filters** start with a pipe character (`|`) and can only be used within **Liquid variables** after the variable string. For example: the `relative_url` filter in `{% raw %}{{ "css/main.css" | relative_url }}{% endraw %}`.
|
||||
|
||||
3. **Markdown**. Jekyll converts Markdown to HTML using the Markdown filter specified in your config file. Files must have a Markdown file extension and front matter in order for Jekyll to convert them.
|
||||
|
||||
4. **Layout**. Jekyll pushes content into the layouts specified by the page's front matter (or as specified in the config file). The content from each page gets pushed into the `{% raw %}{{ content }}{% endraw %}` tags within the layouts.
|
||||
|
||||
5. **Files**. Jekyll writes the generated content into files in the [directory structure]({% link _docs/structure.md %}) in `_site`. Pages, posts, and collections get structured based on their [permalink]({% link _docs/permalinks.md %}) setting. Directories that begin with `_` (such as `_includes` and `_data`) are usually hidden in the output.
|
||||
|
||||
## Scenarios where incorrect configurations create problems
|
||||
|
||||
For the most part, you don't have to think about the order of interpretation when building your Jekyll site. These details only become important to know when something isn't rendering.
|
||||
|
||||
The following scenarios highlight potential problems you might encounter. These problems come from misunderstanding the order of interpretation and can be easily fixed.
|
||||
|
||||
### Variable on page not rendered because variable is assigned in layout
|
||||
|
||||
In your layout file (`_layouts/default.html`), suppose you have a variable assigned:
|
||||
|
||||
```
|
||||
{% raw %}{% assign myvar = "joe" %}{% endraw %}
|
||||
```
|
||||
|
||||
On a page that uses the layout, you reference that variable:
|
||||
|
||||
```
|
||||
{% raw %}{{ myvar }}{% endraw %}
|
||||
```
|
||||
|
||||
The variable won't render because the page's order of interpretation is to render Liquid first and later process the Layout. When the Liquid rendering happens, the variable assignment isn't available.
|
||||
|
||||
To make the code work, you could put the variable assignment into the page's front matter.
|
||||
|
||||
### Markdown in include file not processed
|
||||
|
||||
Suppose you have a Markdown file at `_includes/mycontent.md`. In the Markdown file, you have some Markdown formatting:
|
||||
|
||||
```markdown
|
||||
This is a list:
|
||||
* first item
|
||||
* second item
|
||||
```
|
||||
|
||||
You include the file into an HTML file as follows:
|
||||
|
||||
```liquid
|
||||
{% raw %}{% include mycontent.md %}{% endraw %}
|
||||
```
|
||||
|
||||
The Markdown is not processed because first the Liquid (`include` tag) gets processed, inserting `mycontent.md` into the HTML file. *Then* the Markdown would get processed.
|
||||
|
||||
But because the content is included into an *HTML* page, the Markdown isn't rendered. The Markdown filter processes content only in Markdown files.
|
||||
|
||||
To make the code work, use HTML formatting in includes that are inserted into HTML files.
|
||||
|
||||
Note that `highlight` tags don't require Markdown to process. Suppose your include contains the following:
|
||||
|
||||
```liquid
|
||||
{% raw %}{% highlight javascript %}
|
||||
console.log('alert');
|
||||
{% endhighlight %}{% endraw %}
|
||||
```
|
||||
|
||||
The `highlight` tag *is* Liquid. (Liquid passes the content to Rouge or Pygments for syntax highlighting.) As a result, this code will actually convert to HTML with syntax highlighting. Jekyll does not need the Markdown filter to process `highlight` tags.
|
||||
|
||||
### Liquid mixed with JavaScript isn't rendered
|
||||
|
||||
Suppose you try to mix Liquid's `assign` tag with JavaScript, like this:
|
||||
|
||||
```javascript
|
||||
{% raw %}<button onclick="someFunction()">Click me</button>
|
||||
|
||||
<p id="intro"></p>
|
||||
|
||||
<script>
|
||||
{% assign someContent = "This is some content" %}
|
||||
function someFunction() {
|
||||
document.getElementById("intro").innerHTML = someContent;
|
||||
}
|
||||
</script>{% endraw %}
|
||||
```
|
||||
|
||||
This won't work because the `assign` tag is only available during the Liquid rendering phase of the site. In this JavaScript example, the script executes when a user clicks a button ("Click me") on the HTML page. At that time, the Liquid logic is no longer available, so the `assign` tag wouldn't return anything.
|
||||
|
||||
However, you can use Jekyll's site variables or Liquid to *populate* a script that is executed at a later time. For example, suppose you have the following property in your front matter: `someContent: "This is some content"`. You could do this:
|
||||
|
||||
```js
|
||||
{% raw %}<button onclick="someFunction()">Click me</button>
|
||||
|
||||
<p id="intro"></p>
|
||||
|
||||
<script>
|
||||
|
||||
function someFunction() {
|
||||
document.getElementById("intro").innerHTML = "{{ page.someContent }}";
|
||||
}
|
||||
</script>{% endraw %}
|
||||
```
|
||||
|
||||
When Jekyll builds the site, this `someContent` property populates the script's values, converting `{% raw %}{{ page.someContent }}{% endraw %}` to `"This is some content"`.
|
||||
|
||||
The key to remember is that Liquid renders when Jekyll builds your site. Liquid is not available at run-time in the browser when a user executes an event.
|
||||
|
||||
## Note about using Liquid in YAML
|
||||
|
||||
There's one more detail to remember: Liquid does not render when embedded in YAML files or front matter. (This isn't related to order of interpretation, but it's worth mentioning because it's a common question about element rendering.)
|
||||
|
||||
For example, suppose you have a `highlight` tag in your `_data/mydata.yml` file:
|
||||
|
||||
```
|
||||
{% raw %}myvalue: >
|
||||
{% highlight javascript %}
|
||||
console.log('alert');
|
||||
{% endhighlight %}{% endraw %}
|
||||
```
|
||||
|
||||
On a page, you try to insert the value:
|
||||
|
||||
```
|
||||
{% raw %}{{ site.data.mydata.myvalue }}{% endraw %}
|
||||
```
|
||||
|
||||
This would render only as a string rather than a code sample with syntax highlighting. To make the code render, consider using an include instead.
|
||||
@@ -1,24 +0,0 @@
|
||||
---
|
||||
layout: page
|
||||
title: Community
|
||||
permalink: /community/
|
||||
---
|
||||
|
||||
[JekyllConf](http://jekyllconf.com) is a free, online conference for all things Jekyll hosted by [CloudCannon](http://cloudcannon.com). Each year members of the Jekyll community speak about interesting use cases, tricks they've learned, or meta Jekyll topics.
|
||||
|
||||
## Featured
|
||||
{% assign random = site.time | date: "%s%N" | modulo: site.data.jekyllconf-talks.size %}
|
||||
{% assign featured = site.data.jekyllconf-talks[random] %}
|
||||
|
||||
{{ featured.topic }} - [{{ featured.speaker }}](https://twitter.com/{{ featured.twitter_handle }})
|
||||
<div class="videoWrapper">
|
||||
<iframe width="420" height="315" src="https://www.youtube.com/embed/{{ featured.youtube_id }}" frameborder="0" allowfullscreen></iframe>
|
||||
</div>
|
||||
|
||||
{% assign talks = site.data.jekyllconf-talks | group_by: 'year' %}
|
||||
{% for year in talks reversed %}
|
||||
## {{ year.name }}
|
||||
{% for talk in year.items %}
|
||||
* [{{ talk.topic }}](https://youtu.be/{{ talk.youtube_id }}) - [{{ talk.speaker }}](https://twitter.com/{{ talk.twitter_handle }})
|
||||
{% endfor %}
|
||||
{% endfor %}
|
||||
Binary file not shown.
@@ -1,12 +0,0 @@
|
||||
<?xml version="1.0" standalone="no"?>
|
||||
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd" >
|
||||
<svg xmlns="http://www.w3.org/2000/svg">
|
||||
<metadata>Generated by IcoMoon</metadata>
|
||||
<defs>
|
||||
<font id="FontAwesome" horiz-adv-x="1024">
|
||||
<font-face units-per-em="1024" ascent="960" descent="-64" />
|
||||
<missing-glyph horiz-adv-x="1024" />
|
||||
<glyph unicode=" " horiz-adv-x="512" d="" />
|
||||
<glyph unicode="" glyph-name="pencil" horiz-adv-x="866" d="M207.429 73.143l52 52-134.286 134.286-52-52v-61.143h73.143v-73.143h61.143zM506.286 603.428c0 7.429-5.143 12.571-12.571 12.571-3.429 0-6.857-1.143-9.714-4l-309.714-309.714c-2.857-2.857-4-6.286-4-9.714 0-7.429 5.143-12.571 12.571-12.571 3.429 0 6.857 1.143 9.714 4l309.714 309.714c2.857 2.857 4 6.286 4 9.714zM475.429 713.143l237.714-237.714-475.429-475.429h-237.714v237.714zM865.714 658.286c0-19.429-8-38.286-21.143-51.429l-94.857-94.857-237.714 237.714 94.857 94.286c13.143 13.714 32 21.714 51.429 21.714s38.286-8 52-21.714l134.286-133.714c13.143-13.714 21.143-32.571 21.143-52z" />
|
||||
<glyph unicode="" glyph-name="chain, link" horiz-adv-x="951" d="M832 256c0 14.857-5.714 28.571-16 38.857l-118.857 118.857c-10.286 10.286-24.571 16-38.857 16-16.571 0-29.714-6.286-41.143-18.286 18.857-18.857 41.143-34.857 41.143-64 0-30.286-24.571-54.857-54.857-54.857-29.143 0-45.143 22.286-64 41.143-12-11.429-18.857-24.571-18.857-41.714 0-14.286 5.714-28.571 16-38.857l117.714-118.286c10.286-10.286 24.571-15.429 38.857-15.429s28.571 5.143 38.857 14.857l84 83.429c10.286 10.286 16 24 16 38.286zM430.286 658.857c0 14.286-5.714 28.571-16 38.857l-117.714 118.286c-10.286 10.286-24.571 16-38.857 16s-28.571-5.714-38.857-15.429l-84-83.429c-10.286-10.286-16-24-16-38.286 0-14.857 5.714-28.571 16-38.857l118.857-118.857c10.286-10.286 24.571-15.429 38.857-15.429 16.571 0 29.714 5.714 41.143 17.714-18.857 18.857-41.143 34.857-41.143 64 0 30.286 24.571 54.857 54.857 54.857 29.143 0 45.143-22.286 64-41.143 12 11.429 18.857 24.571 18.857 41.714zM941.714 256c0-43.429-17.714-85.714-48.571-116l-84-83.429c-30.857-30.857-72.571-47.429-116-47.429-44 0-85.714 17.143-116.571 48.571l-117.714 118.286c-30.857 30.857-47.429 72.571-47.429 116 0 45.143 18.286 88 50.286 119.429l-50.286 50.286c-31.429-32-73.714-50.286-118.857-50.286-43.429 0-85.714 17.143-116.571 48l-118.857 118.857c-31.429 31.429-48 72.571-48 116.571 0 43.429 17.714 85.714 48.571 116l84 83.429c30.857 30.857 72.571 47.429 116 47.429 44 0 85.714-17.143 116.571-48.571l117.714-118.286c30.857-30.857 47.429-72.571 47.429-116 0-45.143-18.286-88-50.286-119.429l50.286-50.286c31.429 32 73.714 50.286 118.857 50.286 43.429 0 85.714-17.143 116.571-48l118.857-118.857c31.429-31.429 48-72.571 48-116.571z" />
|
||||
</font></defs></svg>
|
||||
|
Before Width: | Height: | Size: 2.7 KiB |
Binary file not shown.
Binary file not shown.
@@ -1,96 +0,0 @@
|
||||
{
|
||||
"IcoMoonType": "selection",
|
||||
"icons": [
|
||||
{
|
||||
"icon": {
|
||||
"paths": [
|
||||
"M207.429 877.714l52-52-134.286-134.286-52 52v61.143h73.143v73.143h61.143zM506.286 347.429c0-7.429-5.143-12.571-12.571-12.571-3.429 0-6.857 1.143-9.714 4l-309.714 309.714c-2.857 2.857-4 6.286-4 9.714 0 7.429 5.143 12.571 12.571 12.571 3.429 0 6.857-1.143 9.714-4l309.714-309.714c2.857-2.857 4-6.286 4-9.714zM475.429 237.714l237.714 237.714-475.429 475.429h-237.714v-237.714zM865.714 292.571c0 19.429-8 38.286-21.143 51.429l-94.857 94.857-237.714-237.714 94.857-94.286c13.143-13.714 32-21.714 51.429-21.714s38.286 8 52 21.714l134.286 133.714c13.143 13.714 21.143 32.571 21.143 52z"
|
||||
],
|
||||
"width": 865.7188571428571,
|
||||
"attrs": [],
|
||||
"isMulticolor": false,
|
||||
"isMulticolor2": false,
|
||||
"tags": [
|
||||
"pencil"
|
||||
],
|
||||
"defaultCode": 61504,
|
||||
"grid": 14
|
||||
},
|
||||
"attrs": [],
|
||||
"properties": {
|
||||
"name": "pencil",
|
||||
"id": 64,
|
||||
"order": 3,
|
||||
"prevSize": 28,
|
||||
"code": 61504
|
||||
},
|
||||
"setIdx": 0,
|
||||
"setId": 0,
|
||||
"iconIdx": 64
|
||||
},
|
||||
{
|
||||
"icon": {
|
||||
"paths": [
|
||||
"M832 694.857c0-14.857-5.714-28.571-16-38.857l-118.857-118.857c-10.286-10.286-24.571-16-38.857-16-16.571 0-29.714 6.286-41.143 18.286 18.857 18.857 41.143 34.857 41.143 64 0 30.286-24.571 54.857-54.857 54.857-29.143 0-45.143-22.286-64-41.143-12 11.429-18.857 24.571-18.857 41.714 0 14.286 5.714 28.571 16 38.857l117.714 118.286c10.286 10.286 24.571 15.429 38.857 15.429s28.571-5.143 38.857-14.857l84-83.429c10.286-10.286 16-24 16-38.286zM430.286 292c0-14.286-5.714-28.571-16-38.857l-117.714-118.286c-10.286-10.286-24.571-16-38.857-16s-28.571 5.714-38.857 15.429l-84 83.429c-10.286 10.286-16 24-16 38.286 0 14.857 5.714 28.571 16 38.857l118.857 118.857c10.286 10.286 24.571 15.429 38.857 15.429 16.571 0 29.714-5.714 41.143-17.714-18.857-18.857-41.143-34.857-41.143-64 0-30.286 24.571-54.857 54.857-54.857 29.143 0 45.143 22.286 64 41.143 12-11.429 18.857-24.571 18.857-41.714zM941.714 694.857c0 43.429-17.714 85.714-48.571 116l-84 83.429c-30.857 30.857-72.571 47.429-116 47.429-44 0-85.714-17.143-116.571-48.571l-117.714-118.286c-30.857-30.857-47.429-72.571-47.429-116 0-45.143 18.286-88 50.286-119.429l-50.286-50.286c-31.429 32-73.714 50.286-118.857 50.286-43.429 0-85.714-17.143-116.571-48l-118.857-118.857c-31.429-31.429-48-72.571-48-116.571 0-43.429 17.714-85.714 48.571-116l84-83.429c30.857-30.857 72.571-47.429 116-47.429 44 0 85.714 17.143 116.571 48.571l117.714 118.286c30.857 30.857 47.429 72.571 47.429 116 0 45.143-18.286 88-50.286 119.429l50.286 50.286c31.429-32 73.714-50.286 118.857-50.286 43.429 0 85.714 17.143 116.571 48l118.857 118.857c31.429 31.429 48 72.571 48 116.571z"
|
||||
],
|
||||
"width": 950.8571428571428,
|
||||
"attrs": [],
|
||||
"isMulticolor": false,
|
||||
"isMulticolor2": false,
|
||||
"tags": [
|
||||
"chain",
|
||||
"link"
|
||||
],
|
||||
"defaultCode": 61633,
|
||||
"grid": 14
|
||||
},
|
||||
"attrs": [],
|
||||
"properties": {
|
||||
"name": "chain, link",
|
||||
"id": 170,
|
||||
"order": 2,
|
||||
"prevSize": 28,
|
||||
"code": 61633
|
||||
},
|
||||
"setIdx": 0,
|
||||
"setId": 0,
|
||||
"iconIdx": 170
|
||||
}
|
||||
],
|
||||
"height": 1024,
|
||||
"metadata": {
|
||||
"name": "FontAwesome"
|
||||
},
|
||||
"preferences": {
|
||||
"showGlyphs": true,
|
||||
"showCodes": true,
|
||||
"showQuickUse": true,
|
||||
"showQuickUse2": true,
|
||||
"showSVGs": true,
|
||||
"fontPref": {
|
||||
"prefix": "fa-",
|
||||
"metadata": {
|
||||
"fontFamily": "FontAwesome",
|
||||
"majorVersion": 1,
|
||||
"minorVersion": 0
|
||||
},
|
||||
"metrics": {
|
||||
"emSize": 1024,
|
||||
"baseline": 6.25,
|
||||
"whitespace": 50
|
||||
},
|
||||
"embed": false,
|
||||
"showSelector": true,
|
||||
"selector": "class",
|
||||
"classSelector": ".fa"
|
||||
},
|
||||
"imagePref": {
|
||||
"prefix": "icon-",
|
||||
"png": true,
|
||||
"useClassSelector": true,
|
||||
"color": 0,
|
||||
"bgColor": 16777215
|
||||
},
|
||||
"historySize": 100
|
||||
}
|
||||
}
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 1.5 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 3.6 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 39 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 45 KiB |
@@ -1 +0,0 @@
|
||||
3.5.1
|
||||
@@ -1,50 +0,0 @@
|
||||
---
|
||||
title: Philosophy
|
||||
---
|
||||
|
||||
Jekyll offers a unique philosophy when approaching the problem of static
|
||||
site generation. This core philosophy drives development and product
|
||||
decisions. When a contributor, maintainer, or user asks herself what Jekyll
|
||||
is about, the following principles should come to mind:
|
||||
|
||||
### 1. No Magic
|
||||
|
||||
Jekyll is not magic. A user should be able to understand the underlying
|
||||
processes that make up the Jekyll build without much reading. It should
|
||||
do only what you ask it to and nothing more. When a user takes a certain
|
||||
action, the outcome should be easily understandable and focused.
|
||||
|
||||
### 2. It "Just Works"
|
||||
|
||||
The out-of-the-box experience should be that it "just works." Run
|
||||
`gem install jekyll` and it should build any Jekyll site that it's given.
|
||||
Features like auto-regeneration and settings like the markdown renderer
|
||||
should represent sane defaults that work perfectly for the vast majority of
|
||||
cases. The burden of initial configuration should not be placed on the user.
|
||||
|
||||
### 3. Content is King
|
||||
|
||||
Why is Jekyll so loved by content creators? It focuses on content first and
|
||||
foremost, making the process of publishing content on the Web easy. Users
|
||||
should find the management of their content enjoyable and simple.
|
||||
|
||||
### 4. Stability
|
||||
|
||||
If a user's site builds today, it should build tomorrow.
|
||||
Backwards-compatibility should be strongly preferred over breaking changes.
|
||||
Breaking changes should be made to support a strong practical goal, and
|
||||
breaking changes should never be made to drive forward "purity" of the
|
||||
codebase, or other changes purely to make the maintainers' lives easier.
|
||||
Breaking changes provide a significant amount of friction between upgrades
|
||||
and reduce the confidence of users in this software, and should thus be
|
||||
avoided unless absolutely necessary.
|
||||
Upon breaking changes, provide a clear path for users to upgrade.
|
||||
|
||||
### 5. Small & Extensible
|
||||
|
||||
The core of Jekyll should be simple and small, and extensibility should be
|
||||
a first-class feature to provide added functionality from community
|
||||
contributors. The core should be kept to features used by at least 90% of
|
||||
users–everything else should be provided as a plugin. New features should
|
||||
be shipped as plugins and focus should be put on creating extensible core
|
||||
API's to support rich plugins.
|
||||
@@ -77,8 +77,7 @@ Feature: Collections
|
||||
When I run jekyll build
|
||||
Then I should get a zero exit status
|
||||
Then the _site directory should exist
|
||||
And I should see "Collections: _methods/3940394-21-9393050-fifif1323-test.md _methods/collection/entries _methods/configuration.md _methods/escape-\+ #%20\[\].md _methods/sanitized_path.md _methods/site/generate.md _methods/site/initialize.md _methods/um_hi.md" in "_site/index.html" unless Windows
|
||||
And I should see "Collections: _methods/3940394-21-9393050-fifif1323-test.md _methods/collection/entries _methods/configuration.md _methods/escape-\+ #%20\[\].md _methods/sanitized_path.md _methods/site/generate.md _methods/site/initialize.md _methods/yaml_with_dots.md" in "_site/index.html" if on Windows
|
||||
And I should see "Collections: _methods/collection/entries _methods/configuration.md _methods/escape-\+ #%20\[\].md _methods/sanitized_path.md _methods/site/generate.md _methods/site/initialize.md _methods/um_hi.md" in "_site/index.html"
|
||||
|
||||
Scenario: Collections specified as an hash
|
||||
Given I have an "index.html" page that contains "Collections: {% for method in site.methods %}{{ method.relative_path }} {% endfor %}"
|
||||
@@ -91,53 +90,7 @@ Feature: Collections
|
||||
When I run jekyll build
|
||||
Then I should get a zero exit status
|
||||
Then the _site directory should exist
|
||||
And I should see "Collections: _methods/3940394-21-9393050-fifif1323-test.md _methods/collection/entries _methods/configuration.md _methods/escape-\+ #%20\[\].md _methods/sanitized_path.md _methods/site/generate.md _methods/site/initialize.md _methods/um_hi.md" in "_site/index.html" unless Windows
|
||||
And I should see "Collections: _methods/3940394-21-9393050-fifif1323-test.md _methods/collection/entries _methods/configuration.md _methods/escape-\+ #%20\[\].md _methods/sanitized_path.md _methods/site/generate.md _methods/site/initialize.md _methods/yaml_with_dots.md" in "_site/index.html" if on Windows
|
||||
|
||||
Scenario: Rendered collection with document with future date
|
||||
Given I have a _puppies directory
|
||||
And I have the following documents under the puppies collection:
|
||||
| title | date | content |
|
||||
| Rover | 2007-12-31 | content for Rover. |
|
||||
| Fido | 2120-12-31 | content for Fido. |
|
||||
And I have a "_config.yml" file with content:
|
||||
"""
|
||||
collections:
|
||||
puppies:
|
||||
output: true
|
||||
"""
|
||||
When I run jekyll build
|
||||
Then I should get a zero exit status
|
||||
And the _site directory should exist
|
||||
And I should see "content for Rover" in "_site/puppies/rover.html"
|
||||
And the "_site/puppies/fido.html" file should not exist
|
||||
When I run jekyll build --future
|
||||
Then I should get a zero exit status
|
||||
And the _site directory should exist
|
||||
And the "_site/puppies/fido.html" file should exist
|
||||
|
||||
Scenario: Hidden collection with document with future date
|
||||
Given I have a _puppies directory
|
||||
And I have the following documents under the puppies collection:
|
||||
| title | date | content |
|
||||
| Rover | 2007-12-31 | content for Rover. |
|
||||
| Fido | 2120-12-31 | content for Fido. |
|
||||
And I have a "_config.yml" file with content:
|
||||
"""
|
||||
collections:
|
||||
puppies:
|
||||
output: false
|
||||
"""
|
||||
And I have a "foo.txt" file that contains "random static file"
|
||||
When I run jekyll build
|
||||
Then I should get a zero exit status
|
||||
And the _site directory should exist
|
||||
And the "_site/puppies/rover.html" file should not exist
|
||||
And the "_site/puppies/fido.html" file should not exist
|
||||
When I run jekyll build --future
|
||||
Then I should get a zero exit status
|
||||
And the _site directory should exist
|
||||
And the "_site/puppies/fido.html" file should not exist
|
||||
And I should see "Collections: _methods/collection/entries _methods/configuration.md _methods/escape-\+ #%20\[\].md _methods/sanitized_path.md _methods/site/generate.md _methods/site/initialize.md _methods/um_hi.md" in "_site/index.html"
|
||||
|
||||
Scenario: All the documents
|
||||
Given I have an "index.html" page that contains "All documents: {% for doc in site.documents %}{{ doc.relative_path }} {% endfor %}"
|
||||
@@ -150,11 +103,10 @@ Feature: Collections
|
||||
When I run jekyll build
|
||||
Then I should get a zero exit status
|
||||
Then the _site directory should exist
|
||||
And I should see "All documents: _methods/3940394-21-9393050-fifif1323-test.md _methods/collection/entries _methods/configuration.md _methods/escape-\+ #%20\[\].md _methods/sanitized_path.md _methods/site/generate.md _methods/site/initialize.md _methods/um_hi.md" in "_site/index.html" unless Windows
|
||||
And I should see "All documents: _methods/3940394-21-9393050-fifif1323-test.md _methods/collection/entries _methods/configuration.md _methods/escape-\+ #%20\[\].md _methods/sanitized_path.md _methods/site/generate.md _methods/site/initialize.md _methods/yaml_with_dots.md" in "_site/index.html" if on Windows
|
||||
And I should see "All documents: _methods/collection/entries _methods/configuration.md _methods/escape-\+ #%20\[\].md _methods/sanitized_path.md _methods/site/generate.md _methods/site/initialize.md _methods/um_hi.md" in "_site/index.html"
|
||||
|
||||
Scenario: Documents have an output attribute, which is the converted HTML
|
||||
Given I have an "index.html" page that contains "Second document's output: {{ site.documents[2].output }}"
|
||||
Given I have an "index.html" page that contains "Second document's output: {{ site.documents[1].output }}"
|
||||
And I have fixture collections
|
||||
And I have a "_config.yml" file with content:
|
||||
"""
|
||||
@@ -190,8 +142,7 @@ Feature: Collections
|
||||
When I run jekyll build
|
||||
Then I should get a zero exit status
|
||||
And the _site directory should exist
|
||||
And I should see "2. of 9: <p>Page without title.</p>" in "_site/index.html" unless Windows
|
||||
And I should see "2. of 8: <p>Page without title.</p>" in "_site/index.html" if on Windows
|
||||
And I should see "2. of 8: <p>Page without title.</p>" in "_site/index.html"
|
||||
|
||||
Scenario: Sort by relative_path
|
||||
Given I have an "index.html" page that contains "Collections: {% assign methods = site.methods | sort: 'relative_path' %}{{ methods | map:"title" | join: ", " }}"
|
||||
@@ -204,8 +155,7 @@ Feature: Collections
|
||||
When I run jekyll build
|
||||
Then I should get a zero exit status
|
||||
Then the _site directory should exist
|
||||
And I should see "Collections: this is a test!, Collection#entries, Jekyll.configuration, Jekyll.escape, Jekyll.sanitized_path, Site#generate, Initialize, Site#generate, YAML with Dots" in "_site/index.html" unless Windows
|
||||
And I should see "Collections: this is a test!, Collection#entries, Jekyll.configuration, Jekyll.escape, Jekyll.sanitized_path, Site#generate, Initialize, YAML with Dots" in "_site/index.html" if on Windows
|
||||
And I should see "Collections: Collection#entries, Jekyll.configuration, Jekyll.escape, Jekyll.sanitized_path, Site#generate, Initialize, Site#generate," in "_site/index.html"
|
||||
|
||||
Scenario: Rendered collection with date/dateless filename
|
||||
Given I have an "index.html" page that contains "Collections: {% for method in site.thanksgiving %}{{ method.title }} {% endfor %}"
|
||||
|
||||
@@ -59,20 +59,6 @@ Feature: Data
|
||||
And I should see "Jack" in "_site/index.html"
|
||||
And I should see "Leon" in "_site/index.html"
|
||||
|
||||
Scenario: autoload *.tsv files in _data directory
|
||||
Given I have a _data directory
|
||||
And I have a "_data/members.tsv" file with content:
|
||||
"""
|
||||
name age
|
||||
Jack 28
|
||||
Leon 34
|
||||
"""
|
||||
And I have an "index.html" page that contains "{% for member in site.data.members %}{{member.name}}{% endfor %}"
|
||||
When I run jekyll build
|
||||
Then the "_site/index.html" file should exist
|
||||
And I should see "Jack" in "_site/index.html"
|
||||
And I should see "Leon" in "_site/index.html"
|
||||
|
||||
Scenario: autoload *.yml files in _data directory with space in file name
|
||||
Given I have a _data directory
|
||||
And I have a "_data/team members.yml" file with content:
|
||||
|
||||
@@ -80,26 +80,6 @@ Feature: frontmatter defaults
|
||||
And I should see "main: <p>content of site/special/2013/10/14/about1.html</p>" in "_site/special/2013/10/14/about1.html"
|
||||
And I should see "main: <p>content of site/special/2013/10/14/about2.html</p>" in "_site/special/2013/10/14/about2.html"
|
||||
|
||||
Scenario: Use frontmatter scopes for subdirectories
|
||||
Given I have a _layouts directory
|
||||
And I have a main layout that contains "main: {{ content }}"
|
||||
|
||||
And I have a _posts/en directory
|
||||
And I have the following post under "en":
|
||||
| title | date | content |
|
||||
| helloworld | 2014-09-01 | {{page.lang}} is the current language |
|
||||
And I have a _posts/de directory
|
||||
And I have the following post under "de":
|
||||
| title | date | content |
|
||||
| hallowelt | 2014-09-01 | {{page.lang}} is the current language |
|
||||
|
||||
And I have a configuration file with "defaults" set to "[{scope: {path: "_posts/en"}, values: {layout: "main", lang: "en"}}, {scope: {path: "_posts/de"}, values: {layout: "main", lang: "de"}}]"
|
||||
|
||||
When I run jekyll build
|
||||
Then the _site directory should exist
|
||||
And I should see "main: <p>en is the current language</p>" in "_site/2014/09/01/helloworld.html"
|
||||
And I should see "main: <p>de is the current language</p>" in "_site/2014/09/01/hallowelt.html"
|
||||
|
||||
Scenario: Override frontmatter defaults by type
|
||||
Given I have a _posts directory
|
||||
And I have the following post:
|
||||
|
||||
@@ -1,33 +0,0 @@
|
||||
Feature: Syntax Highlighting
|
||||
As a hacker who likes to blog
|
||||
I want to share code snippets in my blog
|
||||
And make them pretty for all the world to see
|
||||
|
||||
Scenario: highlighting an apache configuration
|
||||
Given I have an "index.html" file with content:
|
||||
"""
|
||||
---
|
||||
---
|
||||
|
||||
{% highlight apache %}
|
||||
RewriteEngine On
|
||||
RewriteCond %{REQUEST_FILENAME} !-f
|
||||
RewriteCond %{REQUEST_FILENAME} !-d
|
||||
RewriteRule ^(.*)$ index.php [QSA,L]
|
||||
{% endhighlight %}
|
||||
|
||||
```apache
|
||||
RewriteEngine On
|
||||
RewriteCond %{REQUEST_FILENAME} !-f
|
||||
RewriteCond %{REQUEST_FILENAME} !-d
|
||||
RewriteRule ^(.*)$ index.php [QSA,L]
|
||||
```
|
||||
"""
|
||||
And I have a "_config.yml" file with content:
|
||||
"""
|
||||
kramdown:
|
||||
input: GFM
|
||||
"""
|
||||
When I run jekyll build
|
||||
Then I should get a zero exit-status
|
||||
And I should see "<span class="nc">RewriteCond</span>" in "_site/index.html"
|
||||
@@ -235,7 +235,7 @@ Feature: Hooks
|
||||
owner.output = "1 #{owner.output.chomp}"
|
||||
end
|
||||
Jekyll::Hooks.register :pages, :post_render, priority: :high do |owner|
|
||||
# high runs first
|
||||
# high runs last
|
||||
owner.output = "2 #{owner.output.chomp}"
|
||||
end
|
||||
Jekyll::Hooks.register :pages, :post_render do |owner|
|
||||
@@ -243,13 +243,13 @@ Feature: Hooks
|
||||
owner.output = "3 #{owner.output.chomp}"
|
||||
end
|
||||
Jekyll::Hooks.register :pages, :post_render, priority: :low do |owner|
|
||||
# low runs last
|
||||
# low runs first
|
||||
owner.output = "4 #{owner.output.chomp}"
|
||||
end
|
||||
"""
|
||||
And I have a "index.html" page that contains "WRAP ME"
|
||||
When I run jekyll build
|
||||
Then I should see "4 3 1 2 WRAP ME" in "_site/index.html"
|
||||
Then I should see "2 3 1 4 WRAP ME" in "_site/index.html"
|
||||
|
||||
Scenario: Alter a document right after it is initialized
|
||||
Given I have a _plugins directory
|
||||
@@ -333,28 +333,3 @@ Feature: Hooks
|
||||
Then I should get a zero exit status
|
||||
And the _site directory should exist
|
||||
And I should see "Wrote document 0" in "_site/document-build.log"
|
||||
|
||||
Scenario: Set a custom payload['page'] property
|
||||
Given I have a _plugins directory
|
||||
And I have a "_plugins/ext.rb" file with content:
|
||||
"""
|
||||
Jekyll::Hooks.register :pages, :pre_render do |page, payload|
|
||||
payload['page']['foo'] = "hello world"
|
||||
end
|
||||
"""
|
||||
And I have a _layouts directory
|
||||
And I have a "_layouts/custom.html" file with content:
|
||||
"""
|
||||
---
|
||||
---
|
||||
{{ content }} {% include foo.html %}
|
||||
"""
|
||||
And I have a _includes directory
|
||||
And I have a "_includes/foo.html" file with content:
|
||||
"""
|
||||
{{page.foo}}
|
||||
"""
|
||||
And I have an "index.html" page with layout "custom" that contains "page content"
|
||||
When I run jekyll build
|
||||
Then the "_site/index.html" file should exist
|
||||
And I should see "page content\n hello world" in "_site/index.html"
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user