Compare commits

..

3 Commits

Author SHA1 Message Date
Parker Moore
1c5399b947 Benchmark cached includes.
Calculating -------------------------------------
              cached       634 i/100ms
            uncached       543 i/100ms
-------------------------------------------------
              cached     6570.6 (±3.0%) i/s -      32968 in   5.022063s
            uncached     5613.0 (±2.1%) i/s -      28236 in   5.032667s
2015-01-08 11:30:24 -08:00
Parker Moore
0d6064b1a1 add benchmark-ips to BENCHMARK gemfile 2015-01-08 11:22:35 -08:00
Parker Moore
32ff033f9f Add a cache for the includes.
https://github.com/jekyll/jekyll/issues/3202
2015-01-08 11:13:18 -08:00
543 changed files with 12090 additions and 29076 deletions

View File

@@ -1,33 +0,0 @@
engines:
fixme:
enabled: false
rubocop:
enabled: true
exclude_paths:
- .codeclimate.yml
- .gitignore
- .rspec
- .rubocop.yml
- .travis.yml
- 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/**/*
ratings:
paths:
- lib/**/*.rb

View File

@@ -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

View File

@@ -1,142 +0,0 @@
# Contributing to Jekyll
Hi there! Interested in contributing to Jekyll? We'd love your help. Jekyll is an open source project, built one contribution at a time by users like you.
## Where to get help or report a problem
* If you have a question about using Jekyll, start a discussion on [Jekyll Talk](https://talk.jekyllrb.com).
* If you think you've found a bug within a Jekyll plugin, open an issue in that plugin's repository.
* If you think you've found a bug within Jekyll itself, [open an issue](https://github.com/jekyll/jekyll/issues/new).
* More resources are listed on our [Help page](https://jekyllrb.com/help/).
## Ways to contribute
Whether you're a developer, a designer, or just a Jekyll devotee, there are lots of ways to contribute. Here's a few ideas:
* [Install Jekyll on your computer](https://jekyllrb.com/docs/installation/) and kick the tires. Does it work? Does it do what you'd expect? If not, [open an issue](https://github.com/jekyll/jekyll/issues/new) and let us know.
* Comment on some of the project's [open issues](https://github.com/jekyll/jekyll/issues). Have you experienced the same problem? Know a work around? Do you have a suggestion for how the feature could be better?
* Read through [the documentation](https://jekyllrb.com/docs/home/), and click the "improve this page" button, any time you see something confusing, or have a suggestion for something that could be improved.
* Browse through [the Jekyll discussion forum](https://talk.jekyllrb.com/), and lend a hand answering questions. There's a good chance you've already experienced what another user is experiencing.
* Find [an open issue](https://github.com/jekyll/jekyll/issues) (especially [those labeled `help-wanted`](https://github.com/jekyll/jekyll/issues?q=is%3Aopen+is%3Aissue+label%3Ahelp-wanted)), and submit a proposed fix. If it's your first pull request, we promise we won't bite, and are glad to answer any questions.
* Help evaluate [open pull requests](https://github.com/jekyll/jekyll/pulls), by testing the changes locally and reviewing what's proposed.
## Submitting a pull request
### Pull requests generally
* The smaller the proposed change, the better. If you'd like to propose two unrelated changes, submit two pull requests.
* The more information, the better. Make judicious use of the pull request body. Describe what changes were made, why you made them, and what impact they will have for users.
* Pull requests are easy and fun. If this is your first pull request, it may help to [understand GitHub Flow](https://guides.github.com/introduction/flow/).
* If you're submitting a code contribution, be sure to read the [code contributions](#code-contributions) section below.
### Submitting a pull request via github.com
Many small changes can be made entirely through the github.com web interface.
1. Navigate to the file within [`jekyll/jekyll`](https://github.com/jekyll/jekyll) that you'd like to edit.
2. Click the pencil icon in the top right corner to edit the file
3. Make your proposed changes
4. Click "Propose file change"
5. Click "Create pull request"
6. Add a descriptive title and detailed description for your proposed change. The more information the better.
7. Click "Create pull request"
That's it! You'll be automatically subscribed to receive updates as others review your proposed change and provide feedback.
### Submitting a pull request via Git command line
1. Fork the project by clicking "Fork" in the top right corner of [`jekyll/jekyll`](https://github.com/jekyll/jekyll).
2. Clone the repository locally `git clone https://github.com/<you-username>/jekyll`.
3. Create a new, descriptively named branch to contain your change ( `git checkout -b my-awesome-feature` ).
4. Hack away, add tests. Not necessarily in that order.
5. Make sure everything still passes by running `script/cibuild` (see [the tests section](#running-tests-locally) below)
6. Push the branch up ( `git push origin my-awesome-feature` ).
7. Create a pull request by visiting `https://github.com/<your-username>/jekyll` and following the instructions at the top of the screen.
## Proposing updates to the documentation
We want the Jekyll documentation to be the best it can be. We've open-sourced our docs and we welcome any pull requests if you find it lacking.
### How to submit changes
You can find the documentation for jekyllrb.com in the [docs](https://github.com/jekyll/jekyll/tree/master/docs) directory. See the section above, [submitting a pull request](#submitting-a-pull-request) for information on how to propose a change.
One gotcha, all pull requests should be directed at the `master` branch (the default branch).
### Updating FontAwesome iconset for jekyllrb.com
We use a custom version of FontAwesome which contains just the icons we use.
If you ever need to update our documentation with an icon that is not already available in our custom iconset, you'll have to regenerate the iconset using Icomoon's Generator:
1. Go to <https://icomoon.io/app/>.
2. Click `Import Icons` on the top-horizontal-bar and upload the existing `<jekyll>/docs/icomoon-selection.json`.
3. Click `Add Icons from Library..` further down on the page, and add 'Font Awesome'.
4. Select the required icon(s) from the Library (make sure its the 'FontAwesome' library instead of 'IcoMoon-Free' library).
5. Click `Generate Font` on the bottom-horizontal-bar.
6. Inspect the included icons and proceed by clicking `Download`.
7. Extract the font files and adapt the CSS to the paths we use in Jekyll:
- Copy the entire `fonts` directory over and overwrite existing ones at `<jekyll>/docs/`.
- Copy the contents of `selection.json` and overwrite existing content inside `<jekyll>/docs/icomoon-selection.json`.
- Copy the entire `@font-face {}` declaration and only the **new-icon(s)' css declarations** further below, to update the
`<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.
## Code Contributions
Interesting in submitting a pull request? Awesome. Read on. There's a few common gotchas that we'd love to help you avoid.
### Tests and documentation
Any time you propose a code change, you should also include updates to the documentation and tests within the same pull request.
#### Documentation
If your contribution changes any Jekyll behavior, make sure to update the documentation. Documentation lives in the `docs/_docs` folder (spoiler alert: it's a Jekyll site!). If the docs are missing information, please feel free to add it in. Great docs make a great project. Include changes to the documentation within your pull request, and once merged, `jekyllrb.com` will be updated.
#### Tests
* If you're creating a small fix or patch to an existing feature, a simple test is more than enough. You can usually copy/paste from an existing example in the `tests` folder, but if you need you can find out about our tests suites [Shoulda](https://github.com/thoughtbot/shoulda/tree/master) and [RSpec-Mocks](https://github.com/rspec/rspec-mocks).
* If it's a brand new feature, create a new [Cucumber](https://github.com/cucumber/cucumber/) feature, reusing existing steps where appropriate.
### Code contributions generally
* Jekyll uses the [Rubocop](https://github.com/bbatsov/rubocop) static analyzer to ensure that contributions follow the [GitHub Ruby Styleguide](https://github.com/styleguide/ruby). Please check your code using `script/fmt` and resolve any errors before pushing your branch.
* Don't bump the Gem version in your pull request (if you don't know what that means, you probably didn't).
## Running tests locally
### Test Dependencies
To run the test suite and build the gem you'll need to install Jekyll's dependencies by running the following command:
<pre class="highlight"><code>$ script/bootstrap</code></pre>
Before you make any changes, run the tests and make sure that they pass (to confirm your environment is configured properly):
<pre class="highlight"><code>$ script/cibuild</code></pre>
If you are only updating a file in `test/`, you can use the command:
<pre class="highlight"><code>$ script/test test/blah_test.rb</code></pre>
If you are only updating a `.feature` file, you can use the command:
<pre class="highlight"><code>$ script/cucumber features/blah.feature</code></pre>
Both `script/test` and `script/cucumber` can be run without arguments to
run its entire respective suite.
## A thank you
Thanks! Hacking on Jekyll should be fun. If you find any of this hard to figure out, let us know so we can improve our process or documentation!

View File

@@ -1,83 +0,0 @@
<!--
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.
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!
-->
- [ ] 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+
<!--
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.
## 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.
-->
<!--
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)

28
.gitignore vendored
View File

@@ -1,23 +1,17 @@
Gemfile.lock
test/dest
*.gem
pkg/
*.swp
*~
.DS_Store
.analysis
_site/
.bundle/
.byebug_history
.jekyll-metadata
.ruby-gemset
.DS_Store
bbin/
gh-pages/
site/_site/
coverage
.ruby-version
.sass-cache
/test/source/file_name.txt
/vendor
Gemfile.lock
_site/
bin/
bbin/
coverage
gh-pages/
pkg/
site/_site/
test/dest
tmp/*
tmp/stackprof-*
.jekyll-metadata

View File

@@ -1,3 +0,0 @@
backtrace.mask=true
backtrace.color=true
backtrace.style=mri

View File

@@ -1,153 +0,0 @@
---
AllCops:
TargetRubyVersion: 2.0
Include:
- 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

View File

@@ -1,57 +1,26 @@
bundler_args: --without benchmark:site:development
script: script/cibuild
cache: bundler
language: ruby
cache: bundler
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
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:
- rvm: *jruby
env: TEST_SUITE=cucumber
- 2.2
- 2.1
- 2.0
env:
matrix:
- TEST_SUITE=test
- TEST_SUITE=cucumber
branches:
only:
- master
- themes
- /*-stable/
- TEST_SUITE=test
- TEST_SUITE=cucumber
before_script: bundle update
script: script/cibuild
notifications:
irc:
on_success: change
on_failure: change
channels:
- irc.freenode.org#jekyll
template:
- "%{repository}#%{build_number} (%{branch}) %{message} %{build_url}"
email:
on_success: never
on_failure: never
slack:
secure: "\
dNdKk6nahNURIUbO3ULhA09/vTEQjK0fNbgjVjeYPEvROHgQBP1cIP3AJy8aWs8rl5Yyow4Y\
GEilNRzKPz18AsFptVXofpwyqcBxaCfmHP809NX5PHBaadydveLm+TNVao2XeLXSWu+HUNAY\
O1AanCUbJSEyJTju347xCBGzESU=\
"
addons:
code_climate:
repo_token:
secure: "\
mAuvDu+nrzB8dOaLqsublDGt423mGRyZYM3vsrXh4Tf1sT+L1PxsRzU4gLmcV27HtX2Oq9\
DA4vsRURfABU0fIhwYkQuZqEcA3d8TL36BZcGEshG6MQ2AmnYsmFiTcxqV5bmlElHEqQuT\
5SUFXLafgZPBnL0qDwujQcHukID41sE=\
"
# regular test configuration
after_success:
- bundle exec codeclimate-test-reporter
before_install:
- gem update --system
secure: dNdKk6nahNURIUbO3ULhA09/vTEQjK0fNbgjVjeYPEvROHgQBP1cIP3AJy8aWs8rl5Yyow4YGEilNRzKPz18AsFptVXofpwyqcBxaCfmHP809NX5PHBaadydveLm+TNVao2XeLXSWu+HUNAYO1AanCUbJSEyJTju347xCBGzESU=

View File

@@ -1,49 +0,0 @@
# Code of Conduct
As contributors and maintainers of this project, and in the interest of
fostering an open and welcoming community, we pledge to respect all people who
contribute through reporting issues, posting feature requests, updating
documentation, submitting pull requests or patches, and other activities.
We are committed to making participation in this project a harassment-free
experience for everyone, regardless of level of experience, gender, gender
identity and expression, sexual orientation, disability, personal appearance,
body size, race, ethnicity, age, religion, or nationality.
Examples of unacceptable behavior by participants include:
* The use of sexualized language or imagery
* Personal attacks
* Trolling or insulting/derogatory comments
* Public or private harassment
* Publishing other's private information, such as physical or electronic
addresses, without explicit permission
* Other unethical or unprofessional conduct
Project maintainers have the right and responsibility to remove, edit, or
reject comments, commits, code, wiki edits, issues, and other contributions
that are not aligned to this Code of Conduct, or to ban temporarily or
permanently any contributor for other behaviors that they deem inappropriate,
threatening, offensive, or harmful.
By adopting this Code of Conduct, project maintainers commit themselves to
fairly and consistently applying these principles to every aspect of managing
this project. Project maintainers who do not follow or enforce the Code of
Conduct may be permanently removed from the project team.
This Code of Conduct applies both within project spaces and in public spaces
when an individual is representing the project or its community.
Instances of abusive, harassing, or otherwise unacceptable behavior may be
reported by opening an issue or contacting a project maintainer. All complaints
will be reviewed and investigated and will result in a response that is deemed
necessary and appropriate to the circumstances. Maintainers are obligated to
maintain confidentiality with regard to the reporter of an incident.
This Code of Conduct is adapted from the [Contributor Covenant][homepage],
version 1.3.0, available at
[http://contributor-covenant.org/version/1/3/0/][version]
[homepage]: http://contributor-covenant.org
[version]: http://contributor-covenant.org/version/1/3/0/

91
CONTRIBUTING.markdown Normal file
View File

@@ -0,0 +1,91 @@
Contribute
==========
So you've got an awesome idea to throw into Jekyll. Great! Please keep the
following in mind:
* **Contributions will not be accepted without tests or necessary documentation updates.**
* If you're creating a small fix or patch to an existing feature, just a simple
test will do. Please stay in the confines of the current test suite and use
[Shoulda](https://github.com/thoughtbot/shoulda/tree/master) and
[RR](https://github.com/rr/rr).
* If it's a brand new feature, make sure to create a new
[Cucumber](https://github.com/cucumber/cucumber/) feature and reuse steps
where appropriate. Also, whipping up some documentation in your fork's `site`
would be appreciated, and once merged it will be transferred over to the main
`site`, jekyllrb.com.
* If your contribution changes any Jekyll behavior, make sure to update the
documentation. It lives in `site/docs`. If the docs are missing information,
please feel free to add it in. Great docs make a great project!
* Please follow the [GitHub Ruby Styleguide](https://github.com/styleguide/ruby)
when modifying Ruby code.
* Please do your best to submit **small pull requests**. The easier the proposed
change is to review, the more likely it will be merged.
* When submitting a pull request, please make judicious use of the pull request
body. A description of what changes were made, the motivations behind the
changes and [any tasks completed or left to complete](http://git.io/gfm-tasks)
will also speed up review time.
Test Dependencies
-----------------
To run the test suite and build the gem you'll need to install Jekyll's
dependencies. Jekyll uses Bundler, so a quick run of the bundle command and
you're all set!
$ bundle
Before you start, run the tests and make sure that they pass (to confirm your
environment is configured properly):
$ bundle exec rake test
$ bundle exec rake features
Workflow
--------
Here's the most direct way to get your work merged into the project:
* Fork the project.
* Clone down your fork ( `git clone git@github.com:<username>/jekyll.git` ).
* Create a topic branch to contain your change ( `git checkout -b my_awesome_feature` ).
* Hack away, add tests. Not necessarily in that order.
* Make sure everything still passes by running `rake`.
* If necessary, rebase your commits into logical chunks, without errors.
* Push the branch up ( `git push origin my_awesome_feature` ).
* Create a pull request against jekyll/jekyll and describe what your change
does and the why you think it should be merged.
Updating Documentation
----------------------
We want the Jekyll documentation to be the best it can be. We've
open-sourced our docs and we welcome any pull requests if you find it
lacking.
You can find the documentation for jekyllrb.com in the
[site](https://github.com/jekyll/jekyll/tree/master/site) directory of
Jekyll's repo on GitHub.com.
All documentation pull requests should be directed at `master`. Pull
requests directed at another branch will not be accepted.
The [Jekyll wiki](https://github.com/jekyll/jekyll/wiki) on GitHub
can be freely updated without a pull request as all GitHub users have access.
Gotchas
-------
* If you want to bump the gem version, please put that in a separate commit.
This way, the maintainers can control when the gem gets released.
* Try to keep your patch(es) based from the latest commit on jekyll/jekyll.
The easier it is to apply your work, the less work the maintainers have to do,
which is always a good thing.
* Please don't tag your GitHub issue with [fix], [feature], etc. The maintainers
actively read the issues and will label it once they come across it.
Finally...
----------
Thanks! Hacking on Jekyll should be fun. If you find any of this hard to figure
out, let us know so we can improve our process or documentation!

126
Gemfile
View File

@@ -1,103 +1,29 @@
source "https://rubygems.org"
gemspec :name => "jekyll"
source 'https://rubygems.org'
gemspec
gem "rake", "~> 12.0"
gem 'rake', '~> 10.1'
gem 'rdoc', '~> 3.11'
gem 'redgreen', '~> 1.2'
gem 'shoulda', '~> 3.5'
gem 'rr', '~> 1.1'
gem 'cucumber', '1.3.18'
gem 'RedCloth', '~> 4.2'
gem 'maruku', '~> 0.7.0'
gem 'rdiscount', '~> 1.6'
gem 'launchy', '~> 2.3'
gem 'simplecov', '~> 0.9'
gem 'simplecov-gem-adapter', '~> 1.0.1'
gem 'mime-types', '~> 1.5'
gem 'activesupport', '~> 3.2.13'
gem 'jekyll_test_plugin'
gem 'jekyll_test_plugin_malicious'
gem 'rouge', '~> 1.7'
gem 'liquid-c', '~> 0.0.3'
gem 'minitest' if RUBY_PLATFORM =~ /cygwin/
gem 'test-unit' if RUBY_PLATFORM =~ /cygwin/ || RUBY_VERSION.start_with?("2.2")
# 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"
group :development do
gem "launchy", "~> 2.3"
gem "pry"
unless RUBY_ENGINE == "jruby"
gem "pry-byebug"
end
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 "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"
end
#
group :test_legacy do
if RUBY_PLATFORM =~ %r!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"
end
#
group :benchmark do
if ENV["BENCHMARK"]
gem "benchmark-ips"
gem "benchmark-memory"
gem "rbtrace"
gem "ruby-prof"
gem "stackprof"
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"
platform :ruby, :mswin, :mingw, :x64_mingw do
gem "classifier-reborn", "~> 2.1.0"
gem "liquid-c", "~> 3.0"
gem "pygments.rb", "~> 0.6.0"
gem "rdiscount", "~> 2.0"
gem "redcarpet", "~> 3.2", ">= 3.2.3"
gem "yajl-ruby", "~> 1.2"
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"
end
gem "jekyll-avatar"
gem "jekyll-mentions"
gem "jekyll-seo-tag"
gem "jekyll-sitemap"
gem "jemoji"
if ENV['BENCHMARK']
gem 'benchmark-ips'
gem 'rbtrace'
gem 'stackprof'
end

File diff suppressed because it is too large Load Diff

View File

@@ -1,6 +1,6 @@
The MIT License (MIT)
Copyright (c) 2008-2017 Tom Preston-Werner and Jekyll contributors
Copyright (c) 2008-2014 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

View File

@@ -1,59 +1,36 @@
# [Jekyll](https://jekyllrb.com/)
# [Jekyll](http://jekyllrb.com/)
[![Gem Version](https://img.shields.io/gem/v/jekyll.svg)][ruby-gems]
[![Linux Build Status](https://img.shields.io/travis/jekyll/jekyll/master.svg?label=Linux%20build)][travis]
[![Windows Build status](https://img.shields.io/appveyor/ci/jekyll/jekyll/master.svg?label=Windows%20build)][appveyor]
[![Test Coverage](https://img.shields.io/codeclimate/coverage/github/jekyll/jekyll.svg)][coverage]
[![Code Climate](https://img.shields.io/codeclimate/github/jekyll/jekyll.svg)][codeclimate]
[![Dependency Status](https://img.shields.io/gemnasium/jekyll/jekyll.svg)][gemnasium]
[![Security](https://hakiri.io/github/jekyll/jekyll/master.svg)][hakiri]
[![Gem Version](https://img.shields.io/gem/v/jekyll.svg)](https://rubygems.org/gems/jekyll)
[![Build Status](https://img.shields.io/travis/jekyll/jekyll/master.svg)](https://travis-ci.org/jekyll/jekyll)
[![Code Climate](https://img.shields.io/codeclimate/github/jekyll/jekyll.svg)](https://codeclimate.com/github/jekyll/jekyll)
[![Dependency Status](https://img.shields.io/gemnasium/jekyll/jekyll.svg)](https://gemnasium.com/jekyll/jekyll)
[![Security](https://hakiri.io/github/jekyll/jekyll/master.svg)](https://hakiri.io/github/jekyll/jekyll/master)
[ruby-gems]: https://rubygems.org/gems/jekyll
[gemnasium]: https://gemnasium.com/jekyll/jekyll
[codeclimate]: https://codeclimate.com/github/jekyll/jekyll
[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
By Tom Preston-Werner, Nick Quaranto, Parker Moore, and many [awesome contributors](https://github.com/jekyll/jekyll/graphs/contributors)!
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.
Jekyll is a simple, blog-aware, static site generator perfect for personal, project, or organization sites. Think of it like a file-based CMS, without all the complexity. Jekyll takes your content, renders Markdown and Liquid templates, and spits out a complete, static website ready to be served by Apache, Nginx or another web server. Jekyll is the engine behind [GitHub Pages](http://pages.github.com), which you can use to host sites right from your GitHub repositories.
## Philosophy
Jekyll does what you tell it to do — no more, no less. It doesn't try to outsmart users by making bold assumptions, nor does it burden them with needless complexity and configuration. Put simply, Jekyll gets out of your way and allows you to concentrate on what truly matters: your content.
## Having trouble with OS X/macOS?
See: https://jekyllrb.com/docs/troubleshooting/
## Getting Started
* [Install](https://jekyllrb.com/docs/installation/) the gem
* Read up about its [Usage](https://jekyllrb.com/docs/usage/) and [Configuration](https://jekyllrb.com/docs/configuration/)
* [Install](http://jekyllrb.com/docs/installation/) the gem
* Read up about its [Usage](http://jekyllrb.com/docs/usage/) and [Configuration](http://jekyllrb.com/docs/configuration/)
* Take a gander at some existing [Sites](https://wiki.github.com/jekyll/jekyll/sites)
* [Fork](https://github.com/jekyll/jekyll/fork) and [Contribute](https://jekyllrb.com/docs/contributing/) your own modifications
* Have questions? Check out our official forum community [Jekyll Talk](https://talk.jekyllrb.com/) or [`#jekyll` on irc.freenode.net](https://botbot.me/freenode/jekyll/)
## Code of Conduct
In order to have a more open and welcoming community, Jekyll adheres to a
[code of conduct](CONDUCT.markdown) adapted from the Ruby on Rails code of
conduct.
Please adhere to this code of conduct in any interactions you have in the
Jekyll community. It is strictly enforced on all official Jekyll
repositories, websites, and resources. If you encounter someone violating
these terms, please let 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.
* Fork and [Contribute](http://jekyllrb.com/docs/contributing/) your own modifications
* Have questions? Check out [`#jekyll` on irc.freenode.net](https://botbot.me/freenode/jekyll/).
## Diving In
* [Migrate](http://import.jekyllrb.com/docs/home/) from your previous system
* Learn how the [YAML Front Matter](https://jekyllrb.com/docs/frontmatter/) works
* Put information on your site with [Variables](https://jekyllrb.com/docs/variables/)
* Customize the [Permalinks](https://jekyllrb.com/docs/permalinks/) your posts are generated with
* Use the built-in [Liquid Extensions](https://jekyllrb.com/docs/templates/) to make your life easier
* Use custom [Plugins](https://jekyllrb.com/docs/plugins/) to generate content specific to your site
* Learn how the [YAML Front Matter](http://jekyllrb.com/docs/frontmatter/) works
* Put information on your site with [Variables](http://jekyllrb.com/docs/variables/)
* Customize the [Permalinks](http://jekyllrb.com/docs/permalinks/) your posts are generated with
* Use the built-in [Liquid Extensions](http://jekyllrb.com/docs/templates/) to make your life easier
* Use custom [Plugins](http://jekyllrb.com/docs/plugins/) to generate content specific to your site
## License
See the [LICENSE](https://github.com/jekyll/jekyll/blob/master/LICENSE) file.
See [LICENSE](https://github.com/jekyll/jekyll/blob/master/LICENSE).

282
Rakefile
View File

@@ -1,13 +1,11 @@
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"
Dir.glob("rake/**.rake").each { |f| import f }
$LOAD_PATH.unshift(File.join(File.dirname(__FILE__), *%w[lib]))
require 'jekyll/version'
#############################################################################
#
@@ -16,41 +14,33 @@ Dir.glob("rake/**.rake").each { |f| import f }
#############################################################################
def name
"jekyll"
@name ||= File.basename(Dir['*.gemspec'].first, ".*")
end
def version
Jekyll::VERSION
end
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}-#{version}.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 +50,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 +65,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,38 +78,7 @@ def converted_history(markdown)
custom_release_header_anchors(
liquid_escape(
linkify(
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)
title = begin
File.read(file).match(%r!\A# (.*)$!)[1]
rescue
File.basename(file, ".*").downcase.capitalize
end
slug = File.basename(file, ".markdown").downcase
front_matter = {
"title" => title,
"permalink" => "/docs/#{slug}/",
"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)
end
def content_for(file)
contents = File.read(file)
case file
when "History.markdown"
converted_history(contents)
else
contents.gsub(%r!\A# .*\n\n?!, "")
end
normalize_bullets(markdown)))))
end
#############################################################################
@@ -130,24 +89,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 +113,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
@@ -165,3 +123,185 @@ desc "Open an irb session preloaded with this library"
task :console do
sh "irb -rubygems -r ./lib/#{name}.rb"
end
#############################################################################
#
# Site tasks - http://jekyllrb.com
#
#############################################################################
namespace :site do
desc "Generate and view the site locally"
task :preview do
require "launchy"
require "jekyll"
# Yep, it's a hack! Wait a few seconds for the Jekyll site to generate and
# then open it in a browser. Someday we can do better than this, I hope.
Thread.new do
sleep 4
puts "Opening in browser..."
Launchy.open("http://localhost:4000")
end
# Generate the site in server mode.
puts "Running Jekyll..."
options = {
"source" => File.expand_path("site"),
"destination" => File.expand_path("site/_site"),
"watch" => true,
"serving" => true
}
Jekyll::Commands::Build.process(options)
Jekyll::Commands::Serve.process(options)
end
desc "Generate the site"
task :generate => [:history, :version_file] do
require "jekyll"
Jekyll::Commands::Build.process({
"source" => File.expand_path("site"),
"destination" => File.expand_path("site/_site")
})
end
desc "Update normalize.css library to the latest version and minify"
task :update_normalize_css do
Dir.chdir("site/_sass") do
sh 'curl "http://necolas.github.io/normalize.css/latest/normalize.css" -o "normalize.scss"'
sh 'sass "normalize.scss":"_normalize.scss" --style compressed'
rm ['normalize.scss', Dir.glob('*.map')].flatten
end
end
desc "Commit the local site to the gh-pages branch and publish to GitHub Pages"
task :publish => [:history, :version_file] do
# Ensure the gh-pages dir exists so we can generate into it.
puts "Checking for gh-pages dir..."
unless File.exist?("./gh-pages")
puts "Creating gh-pages dir..."
sh "git clone git@github.com:jekyll/jekyll gh-pages"
end
# Ensure latest gh-pages branch history.
Dir.chdir('gh-pages') do
sh "git checkout gh-pages"
sh "git pull origin gh-pages"
end
# Proceed to purge all files in case we removed a file in this release.
puts "Cleaning gh-pages directory..."
purge_exclude = %w[
gh-pages/.
gh-pages/..
gh-pages/.git
]
FileList["gh-pages/{*,.*}"].exclude(*purge_exclude).each do |path|
sh "rm -rf #{path}"
end
# Copy site to gh-pages dir.
puts "Copying site to gh-pages branch..."
copy_exclude = %w[
site/.
site/..
site/.jekyll-metadata
site/_site
]
FileList["site/{*,.*}"].exclude(*copy_exclude).each do |path|
sh "cp -R #{path} gh-pages/"
end
# Change any configuration settings for production.
config = YAML.load_file("gh-pages/_config.yml")
config.merge!({'sass' => {'style' => 'compressed'}})
File.write('gh-pages/_config.yml', YAML.dump(config))
# Commit and push.
puts "Committing and pushing to GitHub Pages..."
sha = `git log`.match(/[a-z0-9]{40}/)[0]
Dir.chdir('gh-pages') do
sh "git add ."
sh "git commit --allow-empty -m 'Updating to #{sha}.'"
sh "git push origin gh-pages"
end
puts 'Done.'
end
desc "Create a nicely formatted history page for the jekyll site based on the repo history."
task :history do
if File.exist?("History.markdown")
history_file = File.read("History.markdown")
front_matter = {
"layout" => "docs",
"title" => "History",
"permalink" => "/docs/history/",
"prev_section" => "contributing"
}
Dir.chdir('site/_docs/') do
File.open("history.md", "w") do |file|
file.write("#{front_matter.to_yaml}---\n\n")
file.write(converted_history(history_file))
end
end
else
abort "You seem to have misplaced your History.markdown file. I can haz?"
end
end
desc "Write the site latest_version.txt file"
task :version_file do
File.open('site/latest_version.txt', 'wb') { |f| f.write(version) }
end
namespace :releases do
desc "Create new release post"
task :new, :version do |t, args|
raise "Specify a version: rake site:releases:new['1.2.3']" unless args.version
today = Time.new.strftime('%Y-%m-%d')
release = args.version.to_s
filename = "site/_posts/#{today}-jekyll-#{release.split('.').join('-')}-released.markdown"
File.open(filename, "wb") do |post|
post.puts("---")
post.puts("layout: news_item")
post.puts("title: 'Jekyll #{release} Released'")
post.puts("date: #{Time.new.strftime('%Y-%m-%d %H:%M:%S %z')}")
post.puts("author: ")
post.puts("version: #{release}")
post.puts("categories: [release]")
post.puts("---")
post.puts
post.puts
end
puts "Created #{filename}"
end
end
end
#############################################################################
#
# Packaging tasks
#
#############################################################################
desc "Release #{name} v#{version}"
task :release => :build do
unless `git branch` =~ /^\* master$/
puts "You must be on the master branch to release!"
exit!
end
sh "git commit --allow-empty -m 'Release :gem: #{version}'"
sh "git tag v#{version}"
sh "git push origin master"
sh "git push origin v#{version}"
sh "gem push pkg/#{name}-#{version}.gem"
end
desc "Build #{name} v#{version} into pkg/"
task :build do
mkdir_p "pkg"
sh "gem build #{gemspec_file}"
sh "mv #{gem_file} pkg"
end

View File

@@ -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'

View File

@@ -0,0 +1,32 @@
require 'benchmark/ips'
require 'jekyll'
site = Jekyll::Site.new(Jekyll.configuration({
'source' => File.expand_path('../site', __dir__),
'destination' => File.expand_path('../site/_site', __dir__)
}))
payload = Jekyll::Utils.deep_merge_hashes(
site.site_payload,
{ 'site' => {'page' => site.pages.first.to_liquid } }
)
info = {
filters: [Jekyll::Filters],
registers: { :site => site, :page => payload['page'] }
}
class WithoutCacheInclude < Jekyll::Tags::IncludeTag
def source(file, context)
File.read(file, file_read_opts(context))
end
end
Liquid::Template.register_tag('include_woc', WithoutCacheInclude)
def parse(tag, payload, info)
Liquid::Template.parse("{% #{tag} footer.html %}").render!(payload, info)
end
Benchmark.ips do |x|
x.report('cached') { parse 'include', payload, info }
x.report('uncached') { parse 'include_woc', payload, info }
end

View File

@@ -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

View File

@@ -1,16 +0,0 @@
#!/usr/bin/env ruby
require 'benchmark/ips'
Benchmark.ips do |x|
path_without_ending_slash = '/some/very/very/long/path/to/a/file/i/like'
x.report('no slash regexp') { path_without_ending_slash =~ /\/$/ }
x.report('no slash end_with?') { path_without_ending_slash.end_with?("/") }
x.report('no slash [-1, 1]') { path_without_ending_slash[-1, 1] == "/" }
end
Benchmark.ips do |x|
path_with_ending_slash = '/some/very/very/long/path/to/a/file/i/like/'
x.report('slash regexp') { path_with_ending_slash =~ /\/$/ }
x.report('slash end_with?') { path_with_ending_slash.end_with?("/") }
x.report('slash [-1, 1]') { path_with_ending_slash[-1, 1] == "/" }
end

View File

@@ -1,54 +0,0 @@
#!/usr/bin/env ruby
require 'benchmark/ips'
# For this pull request, which changes Page#dir
# https://github.com/jekyll/jekyll/pull/4403
FORWARD_SLASH = '/'.freeze
def pre_pr(url)
url[-1, 1] == FORWARD_SLASH ? url : File.dirname(url)
end
def pr(url)
if url.end_with?(FORWARD_SLASH)
url
else
url_dir = File.dirname(url)
url_dir.end_with?(FORWARD_SLASH) ? url_dir : "#{url_dir}/"
end
end
def envygeeks(url)
return url if url.end_with?(FORWARD_SLASH) || url == FORWARD_SLASH
url = File.dirname(url)
url == FORWARD_SLASH ? url : "#{url}/"
end
# Just a slash
Benchmark.ips do |x|
path = '/'
x.report("pre_pr:#{path}") { pre_pr(path) }
x.report("pr:#{path}") { pr(path) }
x.report("envygeeks:#{path}") { pr(path) }
x.compare!
end
# No trailing slash
Benchmark.ips do |x|
path = '/some/very/very/long/path/to/a/file/i/like'
x.report("pre_pr:#{path}") { pre_pr(path) }
x.report("pr:#{path}") { pr(path) }
x.report("envygeeks:#{path}") { pr(path) }
x.compare!
end
# No trailing slash
Benchmark.ips do |x|
path = '/some/very/very/long/path/to/a/file/i/like/'
x.report("pre_pr:#{path}") { pre_pr(path) }
x.report("pr:#{path}") { pr(path) }
x.report("envygeeks:#{path}") { pr(path) }
x.compare!
end

2
benchmark/flat-map Executable file → Normal file
View File

@@ -1,4 +1,3 @@
#!/usr/bin/env ruby
require 'benchmark/ips'
enum = (0..50).to_a
@@ -15,3 +14,4 @@ Benchmark.ips do |x|
x.report('.map.flatten with no nested arrays') { enum.map { |i| do_thing(i) }.flatten(1) }
x.report('.flat_map with no nested arrays') { enum.flat_map { |i| do_thing(i) } }
end

1
benchmark/hash-fetch Executable file → Normal file
View File

@@ -1,4 +1,3 @@
#!/usr/bin/env ruby
require 'benchmark/ips'
h = {:bar => 'uco'}

0
benchmark/jekyll-sanitize-path Executable file → Normal file
View File

1
benchmark/proc-call-vs-yield Executable file → Normal file
View File

@@ -1,4 +1,3 @@
#!/usr/bin/env ruby
require 'benchmark/ips'
def fast

View File

@@ -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

View File

@@ -1,51 +0,0 @@
#!/usr/bin/env ruby
require 'benchmark/ips'
# For this pull request, which changes Page#dir
# https://github.com/jekyll/jekyll/pull/4403
CONTENT_CONTAINING = <<-HTML.freeze
<!DOCTYPE HTML>
<html lang="en-US">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta charset="UTF-8">
<title>Jemoji</title>
<meta name="viewport" content="width=device-width,initial-scale=1">
<link rel="stylesheet" href="/css/screen.css">
</head>
<body class="wrap">
<p><img class="emoji" title=":+1:" alt=":+1:" src="https://assets.github.com/images/icons/emoji/unicode/1f44d.png" height="20" width="20" align="absmiddle"></p>
</body>
</html>
HTML
CONTENT_NOT_CONTAINING = <<-HTML.freeze
<!DOCTYPE HTML>
<html lang="en-US">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta charset="UTF-8">
<title>Jemoji</title>
<meta name="viewport" content="width=device-width,initial-scale=1">
<link rel="stylesheet" href="/css/screen.css">
</head>
<body class="wrap">
<p><img class="emoji" title=":+1:" alt=":+1:" src="https://assets.github.com/images/icons/emoji/unicode/1f44d.png" height="20" width="20" align="absmiddle"></p>
</body>
</html>
HTML
Benchmark.ips do |x|
x.report("no body include?") { CONTENT_NOT_CONTAINING.include?('<body') }
x.report("no body regexp") { CONTENT_NOT_CONTAINING =~ /<\s*body/ }
x.compare!
end
# No trailing slash
Benchmark.ips do |x|
x.report("with body include?") { CONTENT_CONTAINING.include?('<body') }
x.report("with body regexp") { CONTENT_CONTAINING =~ /<\s*body/ }
x.compare!
end

1
benchmark/sequential-assignment Executable file → Normal file
View File

@@ -1,4 +1,3 @@
#!/usr/bin/env ruby
require 'benchmark/ips'
Benchmark.ips do |x|

3
benchmark/string-concat Executable file → Normal file
View 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 += '/' }

5
benchmark/string-replacement Executable file → Normal file
View File

@@ -1,4 +1,3 @@
#!/usr/bin/env ruby
require 'benchmark/ips'
def str
@@ -9,6 +8,6 @@ Benchmark.ips do |x|
x.report('#tr') { str.tr('some', 'a') }
x.report('#gsub') { str.gsub('some', 'a') }
x.report('#gsub!') { str.gsub!('some', 'a') }
x.report('#sub') { str.sub('some', 'a') }
x.report('#sub!') { str.sub!('some', 'a') }
x.report('#sub') { str.sub('some', 'a') }
x.report('#sub!') { str.sub!('some', 'a') }
end

1
benchmark/symbol-to-proc Executable file → Normal file
View File

@@ -1,4 +1,3 @@
#!/usr/bin/env ruby
require 'benchmark/ips'
Benchmark.ips do |x|

40
bin/jekyll Executable file
View File

@@ -0,0 +1,40 @@
#!/usr/bin/env ruby
STDOUT.sync = true
$:.unshift File.join(File.dirname(__FILE__), *%w{ .. lib })
require 'jekyll'
require 'mercenary'
Jekyll::External.require_if_present(
Jekyll::External.blessed_gems
)
Jekyll::PluginManager.require_from_bundler
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.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', '-p', '--plugins PLUGINS_DIR1[,PLUGINS_DIR2[,...]]', Array, 'Plugins directory (defaults to ./_plugins)'
p.option 'layouts', '--layouts DIR', String, 'Layouts directory (defaults to ./_layouts)'
Jekyll::Command.subclasses.each { |c| c.init_with_program(p) }
p.action do |args, options|
if args.empty?
Jekyll.logger.error "A subcommand is required."
puts p
else
unless p.has_command?(args.first)
Jekyll.logger.abort_with "Invalid command. Use --help for more information"
end
end
end
end

View File

@@ -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>

View File

@@ -1,60 +0,0 @@
markdown: kramdown
highlighter: rouge
sass:
style: compressed
gauges_id: 503c5af6613f5d0f19000027
google_analytics_id: UA-50755011-1
google_site_verification: onQcXpAvtHBrUI5LlroHNE_FP0b2qvFyPq7VZw36iEY
repository: https://github.com/jekyll/jekyll
help_url: https://github.com/jekyll/jekyll-help
timezone: America/Los_Angeles
defaults:
-
scope:
path: "_docs"
type: "docs"
values:
layout: "docs"
-
scope:
path: "_posts"
type: "posts"
values:
layout: "news_item"
collections:
docs:
permalink: /:collection/:path/
output: true
posts:
permalink: /news/:year/:month/:day/:title/
output: true
tutorials:
output: true
name: Jekyll • Simple, blog-aware, static sites
description: Transform your plain text into static websites and blogs
url: https://jekyllrb.com
twitter:
username: jekyllrb
logo: /img/logo-2x.png
gems:
- jekyll-avatar
- jekyll-feed
- jekyll-mentions
- jekyll-redirect-from
- jekyll-seo-tag
- jekyll-sitemap
- jemoji
exclude:
- .gitignore
- README.md

View File

@@ -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

View File

@@ -1,11 +0,0 @@
- title: Tutorials
tutorials:
- home
- navigation
- orderofinterpretation
- custom-404-page
- convert-site-to-jekyll
#- title: Another section
# tutorials:
# - sample

View File

@@ -1,456 +0,0 @@
---
title: Collections
permalink: /docs/collections/
---
Not everything is a post or a page. Maybe you want to document the various
methods in your open source project, members of a team, or talks at a
conference. Collections allow you to define a new type of document that behave
like Pages or Posts do normally, but also have their own unique properties and
namespace.
## Using Collections
To start using collections, follow these 3 steps:
* [Step 1: Tell Jekyll to read in your collection](#step1)
* [Step 2: Add your content](#step2)
* [Step 3: Optionally render your collection's documents into independent files](#step3)
### Step 1: Tell Jekyll to read in your collection {#step1}
Add the following to your site's `_config.yml` file, replacing `my_collection`
with the name of your collection:
```yaml
collections:
- my_collection
```
You can optionally specify metadata for your collection in the configuration:
```yaml
collections:
my_collection:
foo: bar
```
Default attributes can also be set for a collection:
```yaml
defaults:
- scope:
path: ""
type: my_collection
values:
layout: page
```
### Step 2: Add your content {#step2}
Create a corresponding folder (e.g. `<source>/_my_collection`) and add
documents. YAML front matter is processed if the front matter exists, and everything
after the front matter is pushed into the document's `content` attribute. If no YAML front
matter is provided, Jekyll will not generate the file in your collection.
<div class="note info">
<h5>Be sure to name your directories correctly</h5>
<p>
The folder must be named identically to the collection you defined in
your <code>_config.yml</code> file, with the addition of the preceding <code>_</code> character.
</p>
</div>
### Step 3: Optionally render your collection's documents into independent files {#step3}
If you'd like Jekyll to create a public-facing, rendered version of each
document in your collection, set the `output` key to `true` in your collection
metadata in your `_config.yml`:
```yaml
collections:
my_collection:
output: true
```
This will produce a file for each document in the collection.
For example, if you have `_my_collection/some_subdir/some_doc.md`,
it will be rendered using Liquid and the Markdown converter of your
choice and written out to `<dest>/my_collection/some_subdir/some_doc.html`.
<div class="note info">
<h5>Don't forget to add YAML for processing</h5>
<p>
Files in collections that do not have front matter are treated as
<a href="/docs/static-files">static files</a> and simply copied to their
output location without processing.
</p>
</div>
## Configuring permalinks for collections {#permalinks}
If you wish to specify a custom pattern for the URLs where your Collection pages
will reside, you may do so with the [`permalink` property](../permalinks/):
```yaml
collections:
my_collection:
output: true
permalink: /:collection/:name
```
### Examples
For a collection with the following source file structure,
```
_my_collection/
└── some_subdir
└── some_doc.md
```
each of the following `permalink` configurations will produce the document structure shown below it.
* **Default**
Same as `permalink: /:collection/:path`.
```
_site/
├── my_collection
│   └── some_subdir
│   └── some_doc.html
...
```
* `permalink: pretty`
Same as `permalink: /:collection/:path/`.
```
_site/
├── my_collection
│   └── some_subdir
│   └── some_doc
│   └── index.html
...
```
* `permalink: /doc/:path`
```
_site/
├── doc
│   └── some_subdir
│   └── some_doc.html
...
```
* `permalink: /doc/:name`
```
_site/
├── doc
│   └── some_doc.html
...
```
* `permalink: /:name`
```
_site/
├── some_doc.html
...
```
### Template Variables
<div class="mobile-side-scroller">
<table>
<thead>
<tr>
<th>Variable</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr>
<td>
<p><code>:collection</code></p>
</td>
<td>
<p>Label of the containing collection.</p>
</td>
</tr>
<tr>
<td>
<p><code>:path</code></p>
</td>
<td>
<p>Path to the document relative to the collection's directory.</p>
</td>
</tr>
<tr>
<td>
<p><code>:name</code></p>
</td>
<td>
<p>The document's base filename, with every sequence of spaces
and non-alphanumeric characters replaced by a hyphen.</p>
</td>
</tr>
<tr>
<td>
<p><code>:title</code></p>
</td>
<td>
<p>The document's lowercase title (as defined in its <a href="/docs/frontmatter/">front matter</a>), with every sequence of spaces and non-alphanumeric characters replaced by a hyphen. If the document does not define a title in its <a href="/docs/frontmatter/">front matter</a>, this is equivalent to <code>name</code>.</p>
</td>
</tr>
<tr>
<td>
<p><code>:output_ext</code></p>
</td>
<td>
<p>Extension of the output file. (Included by default and usually unnecessary.)</p>
</td>
</tr>
</tbody>
</table>
</div>
## Liquid Attributes
### Collections
Each collection is accessible as a field on the `site` variable. For example, if
you want to access the `albums` collection found in `_albums`, you'd use
`site.albums`.
Each collection is itself an array of documents (e.g., `site.albums` is an array of documents, much like `site.pages` and
`site.posts`). See the table below for how to access attributes of those documents.
The collections are also available under `site.collections`, with the metadata
you specified in your `_config.yml` (if present) and the following information:
<div class="mobile-side-scroller">
<table>
<thead>
<tr>
<th>Variable</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr>
<td>
<p><code>label</code></p>
</td>
<td>
<p>
The name of your collection, e.g. <code>my_collection</code>.
</p>
</td>
</tr>
<tr>
<td>
<p><code>docs</code></p>
</td>
<td>
<p>
An array of <a href="#documents">documents</a>.
</p>
</td>
</tr>
<tr>
<td>
<p><code>files</code></p>
</td>
<td>
<p>
An array of static files in the collection.
</p>
</td>
</tr>
<tr>
<td>
<p><code>relative_directory</code></p>
</td>
<td>
<p>
The path to the collection's source directory, relative to the site
source.
</p>
</td>
</tr>
<tr>
<td>
<p><code>directory</code></p>
</td>
<td>
<p>
The full path to the collections's source directory.
</p>
</td>
</tr>
<tr>
<td>
<p><code>output</code></p>
</td>
<td>
<p>
Whether the collection's documents will be output as individual
files.
</p>
</td>
</tr>
</tbody>
</table>
</div>
<div class="note info">
<h5>A Hard-Coded Collection</h5>
<p>In addition to any collections you create yourself, the
<code>posts</code> collection is hard-coded into Jekyll. It exists whether
you have a <code>_posts</code> directory or not. This is something to note
when iterating through <code>site.collections</code> as you may need to
filter it out.</p>
<p>You may wish to use filters to find your collection:
<code>{% raw %}{{ site.collections | where: "label", "myCollection" | first }}{% endraw %}</code></p>
</div>
### Documents
In addition to any YAML Front Matter provided in the document's corresponding
file, each document has the following attributes:
<div class="mobile-side-scroller">
<table>
<thead>
<tr>
<th>Variable</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr>
<td>
<p><code>content</code></p>
</td>
<td>
<p>
The (unrendered) content of the document. If no YAML Front Matter is
provided, Jekyll will not generate the file in your collection. If
YAML Front Matter is used, then this is all the contents of the file
after the terminating
`---` of the front matter.
</p>
</td>
</tr>
<tr>
<td>
<p><code>output</code></p>
</td>
<td>
<p>
The rendered output of the document, based on the
<code>content</code>.
</p>
</td>
</tr>
<tr>
<td>
<p><code>path</code></p>
</td>
<td>
<p>
The full path to the document's source file.
</p>
</td>
</tr>
<tr>
<td>
<p><code>relative_path</code></p>
</td>
<td>
<p>
The path to the document's source file relative to the site source.
</p>
</td>
</tr>
<tr>
<td>
<p><code>url</code></p>
</td>
<td>
<p>
The URL of the rendered collection. The file is only written to the destination when the collection to which it belongs has <code>output: true</code> in the site's configuration.
</p>
</td>
</tr>
<tr>
<td>
<p><code>collection</code></p>
</td>
<td>
<p>
The name of the document's collection.
</p>
</td>
</tr>
<tr>
<td>
<p><code>date</code></p>
</td>
<td>
<p>
The date of the document's collection.
</p>
</td>
</tr>
</tbody>
</table>
</div>
## Accessing Collection Attributes
Attributes from the YAML front matter can be accessed as data anywhere in the
site. Using the above example for configuring a collection as `site.albums`,
you might have front matter in an individual file structured as follows (which
must use a supported markup format, and cannot be saved with a `.yaml`
extension):
```yaml
title: "Josquin: Missa De beata virgine and Missa Ave maris stella"
artist: "The Tallis Scholars"
director: "Peter Phillips"
works:
- title: "Missa De beata virgine"
composer: "Josquin des Prez"
tracks:
- title: "Kyrie"
duration: "4:25"
- title: "Gloria"
duration: "9:53"
- title: "Credo"
duration: "9:09"
- title: "Sanctus & Benedictus"
duration: "7:47"
- title: "Agnus Dei I, II & III"
duration: "6:49"
```
Every album in the collection could be listed on a single page with a template:
```html
{% raw %}
{% for album in site.albums %}
<h2>{{ album.title }}</h2>
<p>Performed by {{ album.artist }}{% if album.director %}, directed by {{ album.director }}{% endif %}</p>
{% for work in album.works %}
<h3>{{ work.title }}</h3>
<p>Composed by {{ work.composer }}</p>
<ul>
{% for track in work.tracks %}
<li>{{ track.title }} ({{ track.duration }})</li>
{% endfor %}
</ul>
{% endfor %}
{% endfor %}
{% endraw %}
```

View File

@@ -1,55 +0,0 @@
---
title: Code of Conduct
permalink: "/docs/conduct/"
note: This file is autogenerated. Edit /CONDUCT.markdown instead.
redirect_from: "/conduct/index.html"
editable: false
---
As contributors and maintainers of this project, and in the interest of
fostering an open and welcoming community, we pledge to respect all people who
contribute through reporting issues, posting feature requests, updating
documentation, submitting pull requests or patches, and other activities.
We are committed to making participation in this project a harassment-free
experience for everyone, regardless of level of experience, gender, gender
identity and expression, sexual orientation, disability, personal appearance,
body size, race, ethnicity, age, religion, or nationality.
Examples of unacceptable behavior by participants include:
* The use of sexualized language or imagery
* Personal attacks
* Trolling or insulting/derogatory comments
* Public or private harassment
* Publishing other's private information, such as physical or electronic
addresses, without explicit permission
* Other unethical or unprofessional conduct
Project maintainers have the right and responsibility to remove, edit, or
reject comments, commits, code, wiki edits, issues, and other contributions
that are not aligned to this Code of Conduct, or to ban temporarily or
permanently any contributor for other behaviors that they deem inappropriate,
threatening, offensive, or harmful.
By adopting this Code of Conduct, project maintainers commit themselves to
fairly and consistently applying these principles to every aspect of managing
this project. Project maintainers who do not follow or enforce the Code of
Conduct may be permanently removed from the project team.
This Code of Conduct applies both within project spaces and in public spaces
when an individual is representing the project or its community.
Instances of abusive, harassing, or otherwise unacceptable behavior may be
reported by opening an issue or contacting a project maintainer. All complaints
will be reviewed and investigated and will result in a response that is deemed
necessary and appropriate to the circumstances. Maintainers are obligated to
maintain confidentiality with regard to the reporter of an incident.
This Code of Conduct is adapted from the [Contributor Covenant][homepage],
version 1.3.0, available at
[http://contributor-covenant.org/version/1/3/0/][version]
[homepage]: http://contributor-covenant.org
[version]: http://contributor-covenant.org/version/1/3/0/

View File

@@ -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 Build](https://buddy.works/data/blog/_images/buddyworks-jekyll-small.png)
[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/

View File

@@ -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

View File

@@ -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)

View File

@@ -1,146 +0,0 @@
---
title: Contributing
permalink: "/docs/contributing/"
note: This file is autogenerated. Edit /.github/CONTRIBUTING.markdown instead.
---
Hi there! Interested in contributing to Jekyll? We'd love your help. Jekyll is an open source project, built one contribution at a time by users like you.
## Where to get help or report a problem
* If you have a question about using Jekyll, start a discussion on [Jekyll Talk](https://talk.jekyllrb.com).
* If you think you've found a bug within a Jekyll plugin, open an issue in that plugin's repository.
* If you think you've found a bug within Jekyll itself, [open an issue](https://github.com/jekyll/jekyll/issues/new).
* More resources are listed on our [Help page](https://jekyllrb.com/help/).
## Ways to contribute
Whether you're a developer, a designer, or just a Jekyll devotee, there are lots of ways to contribute. Here's a few ideas:
* [Install Jekyll on your computer](https://jekyllrb.com/docs/installation/) and kick the tires. Does it work? Does it do what you'd expect? If not, [open an issue](https://github.com/jekyll/jekyll/issues/new) and let us know.
* Comment on some of the project's [open issues](https://github.com/jekyll/jekyll/issues). Have you experienced the same problem? Know a work around? Do you have a suggestion for how the feature could be better?
* Read through [the documentation](https://jekyllrb.com/docs/home/), and click the "improve this page" button, any time you see something confusing, or have a suggestion for something that could be improved.
* Browse through [the Jekyll discussion forum](https://talk.jekyllrb.com/), and lend a hand answering questions. There's a good chance you've already experienced what another user is experiencing.
* Find [an open issue](https://github.com/jekyll/jekyll/issues) (especially [those labeled `help-wanted`](https://github.com/jekyll/jekyll/issues?q=is%3Aopen+is%3Aissue+label%3Ahelp-wanted)), and submit a proposed fix. If it's your first pull request, we promise we won't bite, and are glad to answer any questions.
* Help evaluate [open pull requests](https://github.com/jekyll/jekyll/pulls), by testing the changes locally and reviewing what's proposed.
## Submitting a pull request
### Pull requests generally
* The smaller the proposed change, the better. If you'd like to propose two unrelated changes, submit two pull requests.
* The more information, the better. Make judicious use of the pull request body. Describe what changes were made, why you made them, and what impact they will have for users.
* Pull requests are easy and fun. If this is your first pull request, it may help to [understand GitHub Flow](https://guides.github.com/introduction/flow/).
* If you're submitting a code contribution, be sure to read the [code contributions](#code-contributions) section below.
### Submitting a pull request via github.com
Many small changes can be made entirely through the github.com web interface.
1. Navigate to the file within [`jekyll/jekyll`](https://github.com/jekyll/jekyll) that you'd like to edit.
2. Click the pencil icon in the top right corner to edit the file
3. Make your proposed changes
4. Click "Propose file change"
5. Click "Create pull request"
6. Add a descriptive title and detailed description for your proposed change. The more information the better.
7. Click "Create pull request"
That's it! You'll be automatically subscribed to receive updates as others review your proposed change and provide feedback.
### Submitting a pull request via Git command line
1. Fork the project by clicking "Fork" in the top right corner of [`jekyll/jekyll`](https://github.com/jekyll/jekyll).
2. Clone the repository locally `git clone https://github.com/<you-username>/jekyll`.
3. Create a new, descriptively named branch to contain your change ( `git checkout -b my-awesome-feature` ).
4. Hack away, add tests. Not necessarily in that order.
5. Make sure everything still passes by running `script/cibuild` (see [the tests section](#running-tests-locally) below)
6. Push the branch up ( `git push origin my-awesome-feature` ).
7. Create a pull request by visiting `https://github.com/<your-username>/jekyll` and following the instructions at the top of the screen.
## Proposing updates to the documentation
We want the Jekyll documentation to be the best it can be. We've open-sourced our docs and we welcome any pull requests if you find it lacking.
### How to submit changes
You can find the documentation for jekyllrb.com in the [docs](https://github.com/jekyll/jekyll/tree/master/docs) directory. See the section above, [submitting a pull request](#submitting-a-pull-request) for information on how to propose a change.
One gotcha, all pull requests should be directed at the `master` branch (the default branch).
### Updating FontAwesome iconset for jekyllrb.com
We use a custom version of FontAwesome which contains just the icons we use.
If you ever need to update our documentation with an icon that is not already available in our custom iconset, you'll have to regenerate the iconset using Icomoon's Generator:
1. Go to <https://icomoon.io/app/>.
2. Click `Import Icons` on the top-horizontal-bar and upload the existing `<jekyll>/docs/icomoon-selection.json`.
3. Click `Add Icons from Library..` further down on the page, and add 'Font Awesome'.
4. Select the required icon(s) from the Library (make sure its the 'FontAwesome' library instead of 'IcoMoon-Free' library).
5. Click `Generate Font` on the bottom-horizontal-bar.
6. Inspect the included icons and proceed by clicking `Download`.
7. Extract the font files and adapt the CSS to the paths we use in Jekyll:
- Copy the entire `fonts` directory over and overwrite existing ones at `<jekyll>/docs/`.
- Copy the contents of `selection.json` and overwrite existing content inside `<jekyll>/docs/icomoon-selection.json`.
- Copy the entire `@font-face {}` declaration and only the **new-icon(s)' css declarations** further below, to update the
`<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.
## Code Contributions
Interesting in submitting a pull request? Awesome. Read on. There's a few common gotchas that we'd love to help you avoid.
### Tests and documentation
Any time you propose a code change, you should also include updates to the documentation and tests within the same pull request.
#### Documentation
If your contribution changes any Jekyll behavior, make sure to update the documentation. Documentation lives in the `docs/_docs` folder (spoiler alert: it's a Jekyll site!). If the docs are missing information, please feel free to add it in. Great docs make a great project. Include changes to the documentation within your pull request, and once merged, `jekyllrb.com` will be updated.
#### Tests
* If you're creating a small fix or patch to an existing feature, a simple test is more than enough. You can usually copy/paste from an existing example in the `tests` folder, but if you need you can find out about our tests suites [Shoulda](https://github.com/thoughtbot/shoulda/tree/master) and [RSpec-Mocks](https://github.com/rspec/rspec-mocks).
* If it's a brand new feature, create a new [Cucumber](https://github.com/cucumber/cucumber/) feature, reusing existing steps where appropriate.
### Code contributions generally
* Jekyll uses the [Rubocop](https://github.com/bbatsov/rubocop) static analyzer to ensure that contributions follow the [GitHub Ruby Styleguide](https://github.com/styleguide/ruby). Please check your code using `script/fmt` and resolve any errors before pushing your branch.
* Don't bump the Gem version in your pull request (if you don't know what that means, you probably didn't).
## Running tests locally
### Test Dependencies
To run the test suite and build the gem you'll need to install Jekyll's dependencies by running the following command:
<pre class="highlight"><code>$ script/bootstrap</code></pre>
Before you make any changes, run the tests and make sure that they pass (to confirm your environment is configured properly):
<pre class="highlight"><code>$ script/cibuild</code></pre>
If you are only updating a file in `test/`, you can use the command:
<pre class="highlight"><code>$ script/test test/blah_test.rb</code></pre>
If you are only updating a `.feature` file, you can use the command:
<pre class="highlight"><code>$ script/cucumber features/blah.feature</code></pre>
Both `script/test` and `script/cucumber` can be run without arguments to
run its entire respective suite.
## A thank you
Thanks! Hacking on Jekyll should be fun. If you find any of this hard to figure out, let us know so we can improve our process or documentation!

View File

@@ -1,208 +0,0 @@
---
title: Deployment methods
permalink: /docs/deployment-methods/
---
Sites built using Jekyll can be deployed in a large number of ways due to the static nature of the generated output. A few of the most common deployment techniques are described below.
## Web hosting providers (FTP)
Just about any traditional web hosting provider will let you upload files to their servers over FTP. To upload a Jekyll site to a web host using FTP, simply run the `jekyll build` command and copy the contents of the generated `_site` folder to the root folder of your hosting account. This is most likely to be the `httpdocs` or `public_html` folder on most hosting providers.
## Self-managed web server
If you have direct access to the deployment web server, the process is essentially the same, except you might have other methods available to you (such as `scp`, or even direct filesystem access) for transferring the files. Just remember to make sure the contents of the generated `_site` folder get placed in the appropriate web root directory for your web server.
## Automated methods
There are also a number of ways to easily automate the deployment of a Jekyll site. If youve got another method that isnt listed below, wed love it if you [contributed](../contributing/) so that everyone else can benefit too.
### Git post-update hook
If you store your Jekyll site in [Git](https://git-scm.com/) (you are using
version control, right?), its pretty easy to automate the
deployment process by setting up a post-update hook in your Git
repository, [like
this](http://web.archive.org/web/20091223025644/http://www.taknado.com/en/2009/03/26/deploying-a-jekyll-generated-site/).
### Git post-receive hook
To have a remote server handle the deploy for you every time you push changes using Git, you can create a user account which has all the public keys that are authorized to deploy in its `authorized_keys` file. With that in place, setting up the post-receive hook is done as follows:
```sh
laptop$ ssh deployer@example.com
server$ mkdir myrepo.git
server$ cd myrepo.git
server$ git --bare init
server$ cp hooks/post-receive.sample hooks/post-receive
server$ mkdir /var/www/myrepo
```
Next, add the following lines to hooks/post-receive and be sure Jekyll is
installed on the server:
```sh
GIT_REPO=$HOME/myrepo.git
TMP_GIT_CLONE=$HOME/tmp/myrepo
PUBLIC_WWW=/var/www/myrepo
git clone $GIT_REPO $TMP_GIT_CLONE
jekyll build -s $TMP_GIT_CLONE -d $PUBLIC_WWW
rm -Rf $TMP_GIT_CLONE
exit
```
Finally, run the following command on any users laptop that needs to be able to
deploy using this hook:
```sh
laptops$ git remote add deploy deployer@example.com:~/myrepo.git
```
Deploying is now as easy as telling nginx or Apache to look at
`/var/www/myrepo` and running the following:
```sh
laptops$ git push deploy master
```
### Static Publisher
[Static Publisher](https://github.com/static-publisher/static-publisher) is another automated deployment option with a server listening for webhook posts, though it's not tied to GitHub specifically. It has a one-click deploy to Heroku, it can watch multiple projects from one server, it has an easy to user admin interface and can publish to either S3 or to a git repository (e.g. gh-pages).
### Rake
Another way to deploy your Jekyll site is to use [Rake](https://github.com/ruby/rake), [HighLine](https://github.com/JEG2/highline), and
[Net::SSH](https://github.com/net-ssh/net-ssh). A more complex example of deploying Jekyll with Rake that deals with multiple branches can be found in [Git Ready](https://github.com/gitready/gitready/blob/cdfbc4ec5321ff8d18c3ce936e9c749dbbc4f190/Rakefile).
### scp
Once youve generated the `_site` directory, you can easily scp its content using a
`tasks/deploy` shell script similar to [this deploy script][]. Youd obviously
need to change the values to reflect your sites details. There is even [a
matching TextMate command][] that will help you run this script.
[this deploy script]: https://github.com/henrik/henrik.nyh.se/blob/master/script/deploy
[a matching TextMate command]: https://gist.github.com/henrik/214959
### rsync
Once youve generated the `_site` directory, you can easily rsync its content using a `tasks/deploy` shell script similar to [this deploy script here](https://github.com/vitalyrepin/vrepinblog/blob/master/transfer.sh). Youd obviously need to change the values to reflect your sites details.
Certificate-based authorization is another way to simplify the publishing
process. It makes sense to restrict rsync access only to the directory which it is supposed to sync. This can be done using rrsync.
#### Step 1: Install rrsync to your home folder (server-side)
If it is not already installed by your host, you can do it yourself:
- [Download rrsync](https://ftp.samba.org/pub/unpacked/rsync/support/rrsync)
- Place it in the `bin` subdirectory of your home folder (`~/bin`)
- Make it executable (`chmod +x`)
#### Step 2: Set up certificate-based SSH access (server side)
This [process](https://wiki.gentoo.org/wiki/SSH#Passwordless_Authentication) is
described in several places online. What is different from the typical approach
is to put the restriction to certificate-based authorization in
`~/.ssh/authorized_keys`. Then, launch `rrsync` and supply
it with the folder it shall have read-write access to:
```sh
command="$HOME/bin/rrsync <folder>",no-agent-forwarding,no-port-forwarding,no-pty,no-user-rc,no-X11-forwarding ssh-rsa <cert>
```
`<folder>` is the path to your site. E.g., `~/public_html/you.org/blog-html/`.
#### Step 3: Rsync (client-side)
Add the `deploy` script to the site source folder:
```sh
#!/bin/sh
rsync -crvz --rsh='ssh -p2222' --delete-after --delete-excluded <folder> <user>@<site>:
```
Command line parameters are:
- `--rsh=ssh -p2222` &mdash; The port for SSH access. It is required if
your host uses a different port than the default (e.g, HostGator)
- `<folder>` &mdash; The name of the local output folder (defaults to `_site`)
- `<user>` &mdash; The username for your hosting account
- `<site>` &mdash; Your hosting server
Using this setup, you might run the following command:
```sh
rsync -crvz --rsh='ssh -p2222' --delete-after --delete-excluded _site/ hostuser@example.org:
```
Don't forget the column `:` after server name!
#### Step 4 (Optional): Exclude the transfer script from being copied to the output folder.
This step is recommended if you use these instructions to deploy your site. If
you put the `deploy` script in the root folder of your project, Jekyll will
copy it to the output folder. This behavior can be changed in `_config.yml`.
Just add the following line:
```yaml
# Do not copy these files to the output directory
exclude: ["deploy"]
```
Alternatively, you can use an `rsync-exclude.txt` file to control which files will be transferred to your server.
#### Done!
Now it's possible to publish your website simply by running the `deploy`
script. If your SSH certificate is [passphrase-protected](https://martin.kleppmann.com/2013/05/24/improving-security-of-ssh-private-keys.html), you will be asked to enter it when the
script executes.
## Rack-Jekyll
[Rack-Jekyll](https://github.com/adaoraul/rack-jekyll/) is an easy way to deploy your site on any Rack server such as Amazon EC2, Slicehost, Heroku, and so forth. It also can run with [shotgun](https://github.com/rtomayko/shotgun/), [rackup](https://github.com/rack/rack), [mongrel](https://github.com/mongrel/mongrel), [unicorn](https://github.com/defunkt/unicorn/), and [others](https://github.com/adaoraul/rack-jekyll#readme).
Read [this post](http://andycroll.com/ruby/serving-a-jekyll-blog-using-heroku/) on how to deploy to Heroku using Rack-Jekyll.
## Jekyll-Admin for Rails
If you want to maintain Jekyll inside your existing Rails app, [Jekyll-Admin](https://github.com/zkarpinski/Jekyll-Admin) contains drop in code to make this possible. See Jekyll-Admins [README](https://github.com/zkarpinski/Jekyll-Admin/blob/master/README) for more details.
## Amazon S3
If you want to host your site in Amazon S3, you can do so by
using the [s3_website](https://github.com/laurilehmijoki/s3_website)
application. It will push your site to Amazon S3 where it can be served like
any web server,
dynamically scaling to almost unlimited traffic. This approach has the
benefit of being about the cheapest hosting option available for
low-volume blogs as you only pay for what you use.
## OpenShift
If you'd like to deploy your site to an OpenShift gear, there's [a cartridge
for that](https://github.com/openshift-quickstart/jekyll-openshift).
<div class="note">
<h5>ProTip™: Use GitHub Pages for zero-hassle Jekyll hosting</h5>
<p>GitHub Pages are powered by Jekyll behind the scenes, so if youre looking for a zero-hassle, zero-cost solution, GitHub Pages are a great way to <a href="../github-pages/">host your Jekyll-powered website for free</a>.</p>
</div>
## Kickster
Use [Kickster](http://kickster.nielsenramon.com/) for easy (automated) deploys to GitHub Pages when using unsupported plugins on GitHub Pages.
Kickster provides a basic Jekyll project setup packed with web best practises and useful optimization tools increasing your overall project quality. Kickster ships with automated and worry-free deployment scripts for GitHub Pages.
Setting up Kickster is very easy, just install the gem and you are good to go. More documentation can here found [here](https://github.com/nielsenramon/kickster#kickster). If you do not want to use the gem or start a new project you can just copy paste the deployment scripts for [Travis CI](https://github.com/nielsenramon/kickster/tree/master/snippets/travis) or [Circle CI](https://github.com/nielsenramon/kickster#automated-deployment-with-circle-ci).
## Aerobatic
[Aerobatic](https://www.aerobatic.com) has custom domains, global CDN distribution, basic auth, CORS proxying, and a growing list of plugins all included.
Automating the deployment of a Jekyll site is simple. See our [Jekyll docs](https://www.aerobatic.com/docs/static-site-generators/#jekyll) for more details. Your built `_site` folder is deployed to our highly-available, globally distributed hosting service.

View File

@@ -1,19 +0,0 @@
---
title: Working with drafts
permalink: /docs/drafts/
---
Drafts are posts without a date. They're posts you're still working on and
don't want to publish yet. To get up and running with drafts, create a
`_drafts` folder in your site's root (as described in the [site structure](/docs/structure/) section) and create your
first draft:
```text
|-- _drafts/
| |-- a-draft-post.md
```
To preview your site with drafts, simply run `jekyll serve` or `jekyll build`
with the `--drafts` switch. Each will be assigned the value modification time
of the draft file for its date, and thus you will see currently edited drafts
as the latest posts.

View File

@@ -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, theyre 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, [@mojombos 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 youre
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/">GitHubs Pages Help section</a>.
If all else fails, you should contact <a href="https://github.com/contact">GitHub Support</a>.
</p>
</div>

File diff suppressed because it is too large Load Diff

View File

@@ -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 &mdash; 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`.

View File

@@ -1,135 +0,0 @@
---
title: Installation
permalink: /docs/installation/
---
Getting Jekyll installed and ready-to-go should only take a few minutes.
If it ever becomes a pain, please [file an issue]({{ site.repository }}/issues/new)
(or submit a pull request) describing the issue you
encountered and how we might make the process easier.
### Requirements
Installing Jekyll should be straight-forward if all requirements are met.
Before you start, make sure your system has the following:
- GNU/Linux, Unix, or macOS
- [Ruby](https://www.ruby-lang.org/en/downloads/) version 2.1 or above, including all development
headers
- [RubyGems](https://rubygems.org/pages/download)
- [GCC](https://gcc.gnu.org/install/) and [Make](https://www.gnu.org/software/make/) (in case your system doesn't have them installed, which you can check by running `gcc -v` and `make -v` in your system's command line interface)
#### Only required for Jekyll 2 and earlier
- [NodeJS](https://nodejs.org/), or another JavaScript runtime (for CoffeeScript support).
- [Python 2.7](https://www.python.org/downloads/)
<div class="note info">
<h5>Problems installing Jekyll?</h5>
<p>
Check out the <a href="../troubleshooting/">troubleshooting</a> page or
<a href="{{ site.repository }}/issues/new">report an issue</a> so the
Jekyll community can improve the experience for everyone.
</p>
</div>
<div class="note info">
<h5>Running Jekyll on Windows</h5>
<p>
While Windows is not officially supported, it is possible to get Jekyll running
on Windows. Special instructions can be found on our
<a href="../windows/#installation">Windows-specific docs page</a>.
</p>
</div>
## Install with RubyGems
The best way to install Jekyll is via
[RubyGems](https://rubygems.org/pages/download). At the terminal prompt,
simply run the following command to install Jekyll:
```sh
$ gem install jekyll
```
All of Jekylls gem dependencies are automatically installed by the above
command, so you wont have to worry about them at all.
<div class="note info">
<h5>Installing Xcode Command-Line Tools</h5>
<p>
If you run into issues installing Jekyll's dependencies which make use of
native extensions and are using macOS, you will need to install Xcode
and the Command-Line Tools it ships with. Download them in
<code>Preferences &#8594; Downloads &#8594; Components</code>.
</p>
</div>
## Pre-releases
In order to install a pre-release, make sure you have all the requirements
installed properly and run:
```sh
gem install jekyll --pre
```
This will install the latest pre-release. If you want a particular pre-release,
use the `-v` switch to indicate the version you'd like to install:
```sh
gem install jekyll -v '2.0.0.alpha.1'
```
If you'd like to install a development version of Jekyll, the process is a bit
more involved. This gives you the advantage of having the latest and greatest,
but may be unstable.
```sh
$ git clone git://github.com/jekyll/jekyll.git
$ cd jekyll
$ script/bootstrap
$ bundle exec rake build
$ ls pkg/*.gem | head -n 1 | xargs gem install -l
```
## Optional Extras
There are a number of (optional) extra features that Jekyll supports that you
may want to install, depending on how you plan to use Jekyll. These extras
include LaTeX support, and the use of alternative content rendering engines.
Check out [the extras page](../extras/) for more information.
<div class="note">
<h5>ProTip™: Enable Syntax Highlighting</h5>
<p>
If youre the kind of person who is using Jekyll, then chances are youll
want to enable syntax highlighting using <a href="http://pygments.org/">Pygments</a>
or <a href="https://github.com/jayferd/rouge">Rouge</a>. You should really
<a href="../templates/#code-snippet-highlighting">check out how to
do that</a> before you go any farther.
</p>
</div>
## Already Have Jekyll?
Before you start developing with Jekyll, you may want to check that you're up to date with the latest version. To find your version of Jekyll, run one of these commands:
```sh
$ jekyll --version
$ gem list jekyll
```
You can also use [RubyGems](https://rubygems.org/gems/jekyll) to find the current versioning of any gem. But you can also use the `gem` command line tool:
```sh
$ gem search jekyll --remote
```
and you'll search for just the name `jekyll`, and in brackets will be latest version. Another way to check if you have the latest version is to run the command `gem outdated`. This will provide a list of all the gems on your system that need to be updated. If you aren't running the latest version, run this command:
```sh
$ gem update jekyll
```
Now that youve got everything up-to-date and installed, lets get to work!

View File

@@ -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 its 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/

View File

@@ -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 its 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.

View File

@@ -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 its 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.

View File

@@ -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 its 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/)

View File

@@ -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 its 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:

View File

@@ -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 its 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.

View File

@@ -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 its 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)

View File

@@ -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 its 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).

View File

@@ -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 youre 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, heres 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.

View File

@@ -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 documents filename. May be overridden via
the documents <code>slug</code> YAML front matter.
</p>
</td>
</tr>
<tr>
<td>
<p><code>slug</code></p>
</td>
<td>
<p>
Slugified title from the documents filename (any character
except numbers and letters is replaced as hyphen). May be
overridden via the documents <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 &mdash; 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.

View File

@@ -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 &mdash; 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.

View File

@@ -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.

View File

@@ -1,579 +0,0 @@
---
title: Templates
permalink: /docs/templates/
---
Jekyll uses the [Liquid](https://shopify.github.io/liquid/) templating language to
process templates. All of the standard Liquid [tags](https://shopify.github.io/liquid/tags/control-flow/) and
[filters](https://shopify.github.io/liquid/filters/abs/) are
supported. Jekyll even adds a few handy filters and tags of its own to make
common tasks easier.
## Filters
<div class="mobile-side-scroller">
<table>
<thead>
<tr>
<th>Description</th>
<th><span class="filter">Filter</span> and <span class="output">Output</span></th>
</tr>
</thead>
<tbody>
<tr>
<td>
<p class="name"><strong>Relative URL</strong></p>
<p>Prepend the <code>baseurl</code> value to the input. Useful if your site is hosted at a subpath rather than the root of the domain.</p>
</td>
<td class="align-center">
<p>
<code class="filter">{% raw %}{{ "/assets/style.css" | relative_url }}{% endraw %}</code>
</p>
<p>
<code class="output">/my-baseurl/assets/style.css</code>
</p>
</td>
</tr>
<tr>
<td>
<p class="name"><strong>Absolute URL</strong></p>
<p>Prepend the <code>url</code> and <code>baseurl</code> value to the input.</p>
</td>
<td class="align-center">
<p>
<code class="filter">{% raw %}{{ "/assets/style.css" | absolute_url }}{% endraw %}</code>
</p>
<p>
<code class="output">http://example.com/my-baseurl/assets/style.css</code>
</p>
</td>
</tr>
<tr>
<td>
<p class="name"><strong>Date to XML Schema</strong></p>
<p>Convert a Date into XML Schema (ISO 8601) format.</p>
</td>
<td class="align-center">
<p>
<code class="filter">{% raw %}{{ site.time | date_to_xmlschema }}{% endraw %}</code>
</p>
<p>
<code class="output">2008-11-07T13:07:54-08:00</code>
</p>
</td>
</tr>
<tr>
<td>
<p class="name"><strong>Date to RFC-822 Format</strong></p>
<p>Convert a Date into the RFC-822 format used for RSS feeds.</p>
</td>
<td class="align-center">
<p>
<code class="filter">{% raw %}{{ site.time | date_to_rfc822 }}{% endraw %}</code>
</p>
<p>
<code class="output">Mon, 07 Nov 2008 13:07:54 -0800</code>
</p>
</td>
</tr>
<tr>
<td>
<p class="name"><strong>Date to String</strong></p>
<p>Convert a date to short format.</p>
</td>
<td class="align-center">
<p>
<code class="filter">{% raw %}{{ site.time | date_to_string }}{% endraw %}</code>
</p>
<p>
<code class="output">07 Nov 2008</code>
</p>
</td>
</tr>
<tr>
<td>
<p class="name"><strong>Date to Long String</strong></p>
<p>Format a date to long format.</p>
</td>
<td class="align-center">
<p>
<code class="filter">{% raw %}{{ site.time | date_to_long_string }}{% endraw %}</code>
</p>
<p>
<code class="output">07 November 2008</code>
</p>
</td>
</tr>
<tr>
<td>
<p class="name"><strong>Where</strong></p>
<p>Select all the objects in an array where the key has the given value.</p>
</td>
<td class="align-center">
<p>
<code class="filter">{% raw %}{{ site.members | where:"graduation_year","2014" }}{% endraw %}</code>
</p>
</td>
</tr>
<tr>
<td>
<p class="name"><strong>Where Expression</strong></p>
<p>Select all the objects in an array where the expression is true. Jekyll v3.2.0 & later.</p>
</td>
<td class="align-center">
<p>
<code class="filter">{% raw %}{{ site.members | where_exp:"item",
"item.graduation_year == 2014" }}{% endraw %}</code>
<code class="filter">{% raw %}{{ site.members | where_exp:"item",
"item.graduation_year < 2014" }}{% endraw %}</code>
<code class="filter">{% raw %}{{ site.members | where_exp:"item",
"item.projects contains 'foo'" }}{% endraw %}</code>
</p>
</td>
</tr>
<tr>
<td>
<p class="name"><strong>Group By</strong></p>
<p>Group an array's items by a given property.</p>
</td>
<td class="align-center">
<p>
<code class="filter">{% raw %}{{ site.members | group_by:"graduation_year" }}{% endraw %}</code>
</p>
<p>
<code class="output">[{"name"=>"2013", "items"=>[...]},
{"name"=>"2014", "items"=>[...]}]</code>
</p>
</td>
</tr>
<tr>
<td>
<p class="name"><strong>Group By Expression</strong></p>
<p>Group an array's items using a Liquid expression.</p>
</td>
<td class="align-center">
<p>
<code class="filter">{% raw %}{{ site.members | group_by_exp:"item",
"item.graduation_year | truncate: 3, \"\"" }}{% endraw %}</code>
</p>
<p>
<code class="output">[{"name"=>"201...", "items"=>[...]},
{"name"=>"200...", "items"=>[...]}]</code>
</p>
</td>
</tr>
<tr>
<td>
<p class="name"><strong>XML Escape</strong></p>
<p>Escape some text for use in XML.</p>
</td>
<td class="align-center">
<p>
<code class="filter">{% raw %}{{ page.content | xml_escape }}{% endraw %}</code>
</p>
</td>
</tr>
<tr>
<td>
<p class="name"><strong>CGI Escape</strong></p>
<p>
CGI escape a string for use in a URL. Replaces any special characters
with appropriate <code>%XX</code> replacements. CGI escape normally replaces a space with a plus <code>+</code> sign.
</p>
</td>
<td class="align-center">
<p>
<code class="filter">{% raw %}{{ "foo, bar; baz?" | cgi_escape }}{% endraw %}</code>
</p>
<p>
<code class="output">foo%2C+bar%3B+baz%3F</code>
</p>
</td>
</tr>
<tr>
<td>
<p class="name"><strong>URI Escape</strong></p>
<p>
Percent encodes any special characters in a URI. URI escape normally replaces a space with <code>%20</code>. <a href="https://en.wikipedia.org/wiki/Percent-encoding#Types_of_URI_characters">Reserved characters</a> will not be escaped.
</p>
</td>
<td class="align-center">
<p>
<code class="filter">{% raw %}{{ "http://foo.com/?q=foo, \bar?" | uri_escape }}{% endraw %}</code>
</p>
<p>
<code class="output">http://foo.com/?q=foo,%20%5Cbar?</code>
</p>
</td>
</tr>
<tr>
<td>
<p class="name"><strong>Number of Words</strong></p>
<p>Count the number of words in some text.</p>
</td>
<td class="align-center">
<p>
<code class="filter">{% raw %}{{ page.content | number_of_words }}{% endraw %}</code>
</p>
<p>
<code class="output">1337</code>
</p>
</td>
</tr>
<tr>
<td>
<p class="name"><strong>Array to Sentence</strong></p>
<p>Convert an array into a sentence. Useful for listing tags. Optional argument for connector.</p>
</td>
<td class="align-center">
<p>
<code class="filter">{% raw %}{{ page.tags | array_to_sentence_string }}{% endraw %}</code>
</p>
<p>
<code class="output">foo, bar, and baz</code>
</p>
<p>
<code class="filter">{% raw %}{{ page.tags | array_to_sentence_string: 'or' }}{% endraw %}</code>
</p>
<p>
<code class="output">foo, bar, or baz</code>
</p>
</td>
</tr>
<tr>
<td>
<p class="name"><strong>Markdownify</strong></p>
<p>Convert a Markdown-formatted string into HTML.</p>
</td>
<td class="align-center">
<p>
<code class="filter">{% raw %}{{ page.excerpt | markdownify }}{% endraw %}</code>
</p>
</td>
</tr>
<tr>
<td>
<p class="name"><strong>Smartify</strong></p>
<p>Convert "quotes" into &ldquo;smart quotes.&rdquo;</p>
</td>
<td class="align-center">
<p>
<code class="filter">{% raw %}{{ page.title | smartify }}{% endraw %}</code>
</p>
</td>
</tr>
<tr>
<td>
<p class="name"><strong>Converting Sass/SCSS</strong></p>
<p>Convert a Sass- or SCSS-formatted string into CSS.</p>
</td>
<td class="align-center">
<p>
<code class="filter">{% raw %}{{ some_scss | scssify }}{% endraw %}</code>
<code class="filter">{% raw %}{{ some_sass | sassify }}{% endraw %}</code>
</p>
</td>
</tr>
<tr>
<td>
<p class="name"><strong>Slugify</strong></p>
<p>Convert a string into a lowercase URL "slug". See below for options.</p>
</td>
<td class="align-center">
<p>
<code class="filter">{% raw %}{{ "The _config.yml file" | slugify }}{% endraw %}</code>
</p>
<p>
<code class="output">the-config-yml-file</code>
</p>
<p>
<code class="filter">{% raw %}{{ "The _config.yml file" | slugify: 'pretty' }}{% endraw %}</code>
</p>
<p>
<code class="output">the-_config.yml-file</code>
</p>
</td>
</tr>
<tr>
<td>
<p class="name"><strong>Data To JSON</strong></p>
<p>Convert Hash or Array to JSON.</p>
</td>
<td class="align-center">
<p>
<code class="filter">{% raw %}{{ site.data.projects | jsonify }}{% endraw %}</code>
</p>
</td>
</tr>
<tr>
<td>
<p class="name"><strong>Normalize Whitespace</strong></p>
<p>Replace any occurrence of whitespace with a single space.</p>
</td>
<td class="align-center">
<p>
<code class="filter">{% raw %}{{ "a \n b" | normalize_whitespace }}{% endraw %}</code>
</p>
</td>
</tr>
<tr>
<td>
<p class="name"><strong>Sort</strong></p>
<p>Sort an array. Optional arguments for hashes: 1.&nbsp;property name 2.&nbsp;nils order (<em>first</em> or <em>last</em>).</p>
</td>
<td class="align-center">
<p>
<code class="filter">{% raw %}{{ page.tags | sort }}{% endraw %}</code>
</p>
<p>
<code class="filter">{% raw %}{{ site.posts | sort: 'author' }}{% endraw %}</code>
</p>
<p>
<code class="filter">{% raw %}{{ site.pages | sort: 'title', 'last' }}{% endraw %}</code>
</p>
</td>
</tr>
<tr>
<td>
<p class="name"><strong>Sample</strong></p>
<p>Pick a random value from an array. Optional: pick multiple values.</p>
</td>
<td class="align-center">
<p>
<code class="filter">{% raw %}{{ site.pages | sample }}{% endraw %}</code>
</p>
<p>
<code class="filter">{% raw %}{{ site.pages | sample:2 }}{% endraw %}</code>
</p>
</td>
</tr>
<tr>
<td>
<p class="name"><strong>To Integer</strong></p>
<p>Convert a string or boolean to integer.</p>
</td>
<td class="align-center">
<p>
<code class="filter">{% raw %}{{ some_var | to_integer }}{% endraw %}</code>
</p>
</td>
</tr>
<tr>
<td>
<p class="name"><strong>Array Filters</strong></p>
<p>Push, pop, shift, and unshift elements from an Array.</p>
<p>These are <strong>NON-DESTRUCTIVE</strong>, i.e. they do not mutate the array, but rather make a copy and mutate that.</p>
</td>
<td class="align-center">
<p>
<code class="filter">{% raw %}{{ page.tags | push: 'Spokane' }}{% endraw %}</code>
</p>
<p>
<code class="output">['Seattle', 'Tacoma', 'Spokane']</code>
</p>
<p>
<code class="filter">{% raw %}{{ page.tags | pop }}{% endraw %}</code>
</p>
<p>
<code class="output">['Seattle']</code>
</p>
<p>
<code class="filter">{% raw %}{{ page.tags | shift }}{% endraw %}</code>
</p>
<p>
<code class="output">['Tacoma']</code>
</p>
<p>
<code class="filter">{% raw %}{{ page.tags | unshift: "Olympia" }}{% endraw %}</code>
</p>
<p>
<code class="output">['Olympia', 'Seattle', 'Tacoma']</code>
</p>
</td>
</tr>
<tr>
<td>
<p class="name"><strong>Inspect</strong></p>
<p>Convert an object into its String representation for debugging.</p>
</td>
<td class="align-center">
<p>
<code class="filter">{% raw %}{{ some_var | inspect }}{% endraw %}</code>
</p>
</td>
</tr>
</tbody>
</table>
</div>
### Options for the `slugify` filter
The `slugify` filter accepts an option, each specifying what to filter.
The default is `default`. They are as follows (with what they filter):
- `none`: no characters
- `raw`: spaces
- `default`: spaces and non-alphanumeric characters
- `pretty`: spaces and non-alphanumeric characters except for `._~!$&'()+,;=@`
## Tags
### Includes
If you have small page snippets that you want to include in multiple places on your site, save the snippets as *include files* and insert them where required, by using the `include` tag:
```liquid
{% raw %}{% include footer.html %}{% endraw %}
```
Jekyll expects all *include files* to be placed in an `_includes` directory at the root of your source directory. In the above example, this will embed the contents of `_includes/footer.html` into the calling file.
For more advanced information on using includes, see [Includes](../includes).
### Code snippet highlighting
Jekyll has built in support for syntax highlighting of over 60 languages
thanks to [Rouge](http://rouge.jneen.net). Rouge is the default highlighter
in Jekyll 3 and above. To use it in Jekyll 2, set `highlighter` to `rouge`
and ensure the `rouge` gem is installed properly.
Alternatively, you can use [Pygments](http://pygments.org) to highlight
your code snippets. To use Pygments, you must have Python installed on your
system, have the `pygments.rb` gem installed and set `highlighter` to
`pygments` in your site's configuration file. Pygments supports [over 100
languages](http://pygments.org/languages/)
To render a code block with syntax highlighting, surround your code as follows:
```liquid
{% raw %}
{% highlight ruby %}
def foo
puts 'foo'
end
{% endhighlight %}
{% endraw %}
```
The argument to the `highlight` tag (`ruby` in the example above) is the
language identifier. To find the appropriate identifier to use for the language
you want to highlight, look for the “short name” on the [Rouge
wiki](https://github.com/jayferd/rouge/wiki/List-of-supported-languages-and-lexers)
or the [Pygments' Lexers page](http://pygments.org/docs/lexers/).
#### Line numbers
There is a second argument to `highlight` called `linenos` that is optional.
Including the `linenos` argument will force the highlighted code to include line
numbers. For instance, the following code block would include line numbers next
to each line:
```liquid
{% raw %}
{% highlight ruby linenos %}
def foo
puts 'foo'
end
{% endhighlight %}
{% endraw %}
```
#### Stylesheets for syntax highlighting
In order for the highlighting to show up, youll need to include a highlighting
stylesheet. For an example stylesheet you can look at
[syntax.css](https://github.com/mojombo/tpw/tree/master/css/syntax.css). These
are the same styles as used by GitHub and you are free to use them for your own
site. If you use `linenos`, you might want to include an additional CSS class
definition for the `.lineno` class in `syntax.css` to distinguish the line
numbers from the highlighted code.
### Gist
Use the `gist` tag to easily embed a GitHub Gist onto your site. This works
with public or secret gists:
```liquid
{% raw %}
{% gist parkr/931c1c8d465a04042403 %}
{% endraw %}
```
You may also optionally specify the filename in the gist to display:
```liquid
{% raw %}
{% gist parkr/931c1c8d465a04042403 jekyll-private-gist.markdown %}
{% endraw %}
```
To use the `gist` tag, you'll need to add the
[jekyll-gist](https://github.com/jekyll/jekyll-gist) gem to your project.
## Links
### Linking to pages {#link}
To link to a post, a page, collection item, or file, the `link` tag will generate the correct permalink URL for the path you specify. For example, if you use the `link` tag to link to `mypage.html`, even if you change your permalink style to include the file extension or omit it, the URL formed by the `link` tag will always be valid.
You must include the file's original extension when using the `link` tag. Here are some examples:
```liquid
{% raw %}
{{ site.baseurl }}{% link _collection/name-of-document.md %}
{{ site.baseurl }}{% link _posts/2016-07-26-name-of-post.md %}
{{ site.baseurl }}{% link news/index.html %}
{{ site.baseurl }}{% link /assets/files/doc.pdf %}
{% endraw %}
```
You can also use the `link` tag to create a link in Markdown as follows:
```liquid
{% raw %}
[Link to a document]({{ site.baseurl }}{% link _collection/name-of-document.md %})
[Link to a post]({{ site.baseurl }}{% link _posts/2016-07-26-name-of-post.md %})
[Link to a page]({{ site.baseurl }}{% link news/index.html %})
[Link to a file]({{ site.baseurl }}{% link /assets/files/doc.pdf %})
{% endraw %}
```
(Including `{% raw %}{{ site.baseurl }}{% endraw %}` is optional &mdash; it depends on whether you want to preface the page URL with the `baseurl` value.)
The path to the post, page, or collection is defined as the path relative to the root directory (where your config file is) to the file, not the path from your existing page to the other page.
For example, suppose you're creating a link in `page_a.md` (stored in `pages/folder1/folder2`) to `page_b.md` (stored in `pages/folder1`). Your path in the link would not be `../page_b.html`. Instead, it would be `/pages/folder1/page_b.md`.
If you're unsure of the path, add `{% raw %}{{ page.path }}{% endraw %}` to the page and it will display the path.
One major benefit of using the `link` tag is link validation. If the link doesn't exist, Jekyll won't build your site. This is a good thing, as it will alert you to a broken link so you can fix it (rather than allowing you to build and deploy a site with broken links).
Note you cannot add filters to `link` tags. For example, you cannot append a string using Liquid filters, such as `{% raw %}{% link mypage.html | append: "#section1" %} {% endraw %}`. To link to sections on a page, you will need to use regular HTML or Markdown linking techniques.
### Linking to posts
If you want to include a link to a post on your site, the `post_url` tag will generate the correct permalink URL for the post you specify.
```liquid
{% raw %}
{{ site.baseurl }}{% post_url 2010-07-21-name-of-post %}
{% endraw %}
```
If you organize your posts in subdirectories, you need to include subdirectory path to the post:
```liquid
{% raw %}
{{ site.baseurl }}{% post_url /subdir/2010-07-21-name-of-post %}
{% endraw %}
```
There is no need to include the file extension when using the `post_url` tag.
You can also use this tag to create a link to a post in Markdown as follows:
```liquid
{% raw %}
[Name of Link]({{ site.baseurl }}{% post_url 2010-07-21-name-of-post %})
{% endraw %}
```

View File

@@ -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.

View File

@@ -1,241 +0,0 @@
---
title: Troubleshooting
permalink: /docs/troubleshooting/
---
If you ever run into problems installing or using Jekyll, here are a few tips
that might be of help. If the problem youre experiencing isnt covered below,
**please [check out our other help resources](/help/)** as well.
- [Installation Problems](#installation-problems)
- [Problems running Jekyll](#problems-running-jekyll)
- [Base-URL Problems](#base-url-problems)
- [Configuration problems](#configuration-problems)
- [Markup Problems](#markup-problems)
- [Production Problems](#production-problems)
## Installation Problems
If you encounter errors during gem installation, you may need to install
the header files for compiling extension modules for Ruby 2.x This
can be done on Ubuntu or Debian by running:
```sh
sudo apt-get install ruby2.3-dev
```
On Red Hat, CentOS, and Fedora systems you can do this by running:
```sh
sudo yum install ruby-devel
```
If you installed the above - specifically on Fedora 23 - but the extensions would still not compile, you are probably running a Fedora image that misses the `redhat-rpm-config` package. To solve this, simply run:
```sh
sudo dnf install redhat-rpm-config
```
On Ubuntu if you get stuck after `bundle exec jekyll serve` and see error
messages like `Could not locate Gemfile` or `.bundle/ directory`, it's likely
because all requirements have not been fully met. Recent stock Ubuntu
distributions require the installation of both the `ruby` and `ruby-all-dev`
packages:
```sh
sudo apt-get install ruby ruby-all-dev
```
On [NearlyFreeSpeech](https://www.nearlyfreespeech.net/) you need to run the
following commands before installing Jekyll:
```sh
export GEM_HOME=/home/private/gems
export GEM_PATH=/home/private/gems:/usr/local/lib/ruby/gems/1.8/
export PATH=$PATH:/home/private/gems/bin
export RB_USER_INSTALL='true'
```
To install RubyGems on Gentoo:
```sh
sudo emerge -av dev-ruby/rubygems
```
On Windows, you may need to install [RubyInstaller
DevKit](https://wiki.github.com/oneclick/rubyinstaller/development-kit).
On Android (with Termux) you can install all requirements by running:
```sh
apt update && apt install libffi-dev clang ruby-dev make
```
On macOS, you may need to update RubyGems (using `sudo` only if necessary):
```sh
sudo gem update --system
```
If you still have issues, you can download and install new Command Line
Tools (such as `gcc`) using the following command:
```sh
xcode-select --install
```
which may allow you to install native gems using this command (again using
`sudo` only if necessary):
```sh
sudo gem install jekyll
```
Note that upgrading macOS does not automatically upgrade Xcode itself
(that can be done separately via the App Store), and having an out-of-date
Xcode.app can interfere with the command line tools downloaded above. If
you run into this issue, upgrade Xcode and install the upgraded Command
Line Tools.
### Jekyll &amp; Mac OS X 10.11
With the introduction of System Integrity Protection, several directories
that were previously writable are now considered system locations and are no
longer available. Given these changes, there are a couple of simple ways to get
up and running. One option is to change the location where the gem will be
installed (again using `sudo` only if necessary):
```sh
sudo gem install -n /usr/local/bin jekyll
```
Alternatively, Homebrew can be installed and used to set up Ruby. This can be
done as follows:
```sh
ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
```
Once Homebrew is installed, the second step is easy:
```sh
brew install ruby
```
Advanced users (with more complex needs) may find it helpful to choose one of a
number of Ruby version managers ([RVM][], [rbenv][], [chruby][], [etc][].) in
which to install Jekyll.
[RVM]: https://rvm.io
[rbenv]: http://rbenv.org
[chruby]: https://github.com/postmodern/chruby
[etc]: https://github.com/rvm/rvm/blob/master/docs/alt.md
If you elect to use one of the above methods to install Ruby, it might be
necessary to modify your `$PATH` variable using the following command:
```sh
export PATH=/usr/local/bin:$PATH
```
GUI apps can modify the `$PATH` as follows:
```sh
launchctl setenv PATH "/usr/local/bin:$PATH"
```
Either of these approaches are useful because `/usr/local` is considered a
"safe" location on systems which have SIP enabled, they avoid potential
conflicts with the version of Ruby included by Apple, and it keeps Jekyll and
its dependencies in a sandboxed environment. This also has the added
benefit of not requiring `sudo` when you want to add or remove a gem.
### Could not find a JavaScript runtime. (ExecJS::RuntimeUnavailable)
This error can occur during the installation of `jekyll-coffeescript` when
you don't have a proper JavaScript runtime. To solve this, either install
`execjs` and `therubyracer` gems, or install `nodejs`. Check out
[issue #2327](https://github.com/jekyll/jekyll/issues/2327) for more info.
## Problems running Jekyll
On Debian or Ubuntu, you may need to add `/var/lib/gems/1.8/bin/` to your path
in order to have the `jekyll` executable be available in your Terminal.
## Base-URL Problems
If you are using base-url option like:
```sh
jekyll serve --baseurl '/blog'
```
… then make sure that you access the site at:
```sh
http://localhost:4000/blog/index.html
```
It wont work to just access:
```sh
http://localhost:4000/blog
```
## Configuration problems
The order of precedence for conflicting [configuration settings](../configuration/)
is as follows:
1. Command-line flags
2. Configuration file settings
3. Defaults
That is: defaults are overridden by options specified in `_config.yml`,
and flags specified at the command-line will override all other settings
specified elsewhere.
If you encounter an error in building the site, with the error message
"'0000-00-00-welcome-to-jekyll.markdown.erb' does not have a valid date in the
YAML front matter." try including the line `exclude: [vendor]`
in `_config.yml`.
## Markup Problems
The various markup engines that Jekyll uses may have some issues. This
page will document them to help others who may run into the same
problems.
### Liquid
The latest version, version 2.0, seems to break the use of `{{ "{{" }}` in
templates. Unlike previous versions, using `{{ "{{" }}` in 2.0 triggers the
following error:
```sh
'{{ "{{" }}' was not properly terminated with regexp: /\}\}/ (Liquid::SyntaxError)
```
### Excerpts
Since v1.0.0, Jekyll has had automatically-generated post excerpts. Since
v1.1.0, Jekyll also passes these excerpts through Liquid, which can cause
strange errors where references don't exist or a tag hasn't been closed. If you
run into these errors, try setting `excerpt_separator: ""` in your
`_config.yml`, or set it to some nonsense string.
## Production Problems
If you run into an issue that a static file can't be found in your
production environment during build since v3.2.0 you should set your
[environment to `production`](../configuration/#specifying-a-jekyll-environment-at-build-time).
The issue is caused by trying to copy a non-existing symlink.
<div class="note">
<h5>Please report issues you encounter!</h5>
<p>
If you come across a bug, please <a href="{{ site.help_url }}/issues/new">create an issue</a>
on GitHub describing the problem and any work-arounds you find so we can
document it here for others.
</p>
</div>

View File

@@ -1,13 +0,0 @@
---
layout: docs
title: Upgrading
permalink: /docs/upgrading/
---
Upgrading from an older version of Jekyll? Upgrading to a new major version of Jekyll (e.g. from v2.x to v3.x) may cause some headaches. Take the following guides to aid your upgrade:
- [From 0.x to 1.x and 2.x](/docs/upgrading/0-to-2/)
- [From 2.x to 3.x](/docs/upgrading/2-to-3/)
If you are making a minor update (for example from 3.3.1 to the latest version at the time 3.3.2) run 'bundle update jekyll' when in your site directory.
If you would like to update all your gems, run 'bundle update' when in your site directory.

View File

@@ -1,137 +0,0 @@
---
title: Upgrading from 2.x to 3.x
permalink: /docs/upgrading/2-to-3/
---
Upgrading from an older version of Jekyll? A few things have changed in 3.0
that you'll want to know about.
Before we dive in, go ahead and fetch the latest version of Jekyll:
```sh
$ gem update jekyll
```
Please note: Jekyll 3.2 requires Ruby version >= 2.1
<div class="note feature">
<h5 markdown="1">Diving in</h5>
<p markdown="1">Want to get a new Jekyll site up and running quickly? Simply
run <code>jekyll new SITENAME</code> to create a new folder with a bare bones
Jekyll site.</p>
</div>
### site.collections has changed
In 2.x, your iterations over `site.collections` yielded an array with the collection
label and the collection object as the first and second items, respectively. In 3.x,
this complication has been removed and iterations now yield simply the collection object.
A simple conversion must be made in your templates:
- `collection[0]` becomes `collection.label`
- `collection[1]` becomes `collection`
When iterating over `site.collections`, ensure the above conversions are made.
For `site.collections.myCollection` in Jekyll 2, you now do:
```liquid
{% raw %}
{% assign myCollection = site.collections | where: "label", "myCollection" | first %}
{% endraw %}
```
This is a bit cumbersome at first, but is easier than a big `for` loop.
### Dropped dependencies
We dropped a number of dependencies the Core Team felt were optional. As such, in 3.0, they must be explicitly installed and included if you use any of the features. They are:
- jekyll-paginate Jekyll's pagination solution from days past
- jekyll-coffeescript processing of CoffeeScript
- jekyll-gist the `gist` Liquid tag
- pygments.rb the Pygments highlighter
- redcarpet the Markdown processor
- toml an alternative to YAML for configuration files
- classifier-reborn for `site.related_posts`
### Future posts
A seeming feature regression in 2.x, the `--future` flag was automatically _enabled_.
The future flag allows post authors to give the post a date in the future and to have
it excluded from the build until the system time is equal or after the post time.
In Jekyll 3, this has been corrected. **Now, `--future` is disabled by default.**
This means you will need to include `--future` if you want your future-dated posts to
generate when running `jekyll build` or `jekyll serve`.
<div class="note info">
<h5>Future Posts on GitHub Pages</h5>
<p>
An exception to the above rule are GitHub Pages sites, where the <code>--future</code> flag remains <em>enabled</em>
by default to maintain historical consistency for those sites.
</p>
</div>
### Layout metadata
Introducing: `layout`. In Jekyll 2 and below, any metadata in the layout was merged onto
the `page` variable in Liquid. This caused a lot of confusion in the way the data was
merged and some unexpected behaviour. In Jekyll 3, all layout data is accessible via `layout`
in Liquid. For example, if your layout has `class: my-layout` in its YAML front matter,
then the layout can access that via `{% raw %}{{ layout.class }}{% endraw %}`.
### Syntax highlighter changed
For the first time, the default syntax highlighter has changed for the
`highlight` tag and for backtick code blocks. Instead of [Pygments.rb](https://github.com/tmm1/pygments.rb),
it's now [Rouge](http://rouge.jneen.net/). If you were using the `highlight` tag with certain
options, such as `hl_lines`, they may not be available when using Rouge. To
go back to using Pygments, set `highlighter: pygments` in your
`_config.yml` file and run `gem install pygments.rb` or add
`gem 'pygments.rb'` to your project's `Gemfile`.
### Relative Permalink support removed
In Jekyll 3 and above, relative permalinks have been deprecated. If you
created your site using Jekyll 2 and below, you may receive the following
error when trying to **serve** or **build**:
```text
Since v3.0, permalinks for pages in subfolders must be relative to the site
source directory, not the parent directory. Check
https://jekyllrb.com/docs/upgrading/ for more info.
```
This can be fixed by removing the following line from your `_config.yml` file:
```yaml
relative_permalinks: true
```
### Permalinks no longer automatically add a trailing slash
In Jekyll 2, any URL constructed from the `permalink:` field had a trailing slash (`/`) added to it automatically. Jekyll 3 no longer adds a trailing slash automatically to `permalink:` URLs. This can potentially result in old links to pages returning a 404 error. For example, suppose a page previously contained the YAML `permalink: /:year-:month-:day-:title` that resulted in the URL `example.com/2016-02-01-test/` (notice the trailing slash), Jekyll internally generates a folder named `2016-02-01-test`. In Jekyll 3, the same `permalink:` generate the file `2016-02-01-test.html` and the URL for the same page will be `example.com/2016-02-01-test`, and consequently any links to the old URL will result in a 404 error. In order to maintain the same URLs and avoid this problem, a trailing slash should be added to the `permalink:` field, for example `permalink: /:year-:month-:day-:title/`.
### All my posts are gone! Where'd they go!
Try adding `future: true` to your `_config.yml` file. Are they showing up now? If they are, then you were ensnared by an issue with the way Ruby parses times. Each of your posts is being read in a different timezone than you might expect and, when compared to the computer's current time, is "in the future." The fix for this is to add [a timezone offset](https://en.wikipedia.org/wiki/List_of_UTC_time_offsets) to each post (and make sure you remove `future: true` from your `_config.yml` file). If you're writing from California, for example, you would change this:
```yaml
---
date: 2016-02-06 19:32:10
---
```
to this (note the offset):
```yaml
---
date: 2016-02-06 19:32:10 -0800
---
```
### My categories have stopped working!
If you organized your categories as `/_posts/code/2008-12-24-closures.md`, you will need to restructure your directories to put the categories _above_ the `_posts` directories, as follows: `/code/_posts/2008-12-24-closures.md`.
_Did we miss something? Please click "Improve this page" above and add a section. Thanks!_

View File

@@ -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).

View File

@@ -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 %}

View File

@@ -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>

View File

@@ -1,20 +0,0 @@
<ul>
<li class="{% if page.overview %}current{% endif %}">
<a href="/">Home</a>
</li>
<li class="{% if page.url contains '/docs/' %}current{% endif %}">
<a href="/docs/home/">Docs</a>
</li>
<li class="{% if page.author %}current{% endif %}">
<a href="/news/">News</a>
</li>
<li class="{% if page.url contains '/community/' %}current{% endif %}">
<a href="/community/">Community</a>
</li>
<li class="{% if page.url contains '/help/' %}current{% endif %}">
<a href="/help/">Help</a>
</li>
<li>
<a href="{{ site.repository }}">GitHub</a>
</li>
</ul>

View File

@@ -1,39 +0,0 @@
{% comment %}
Map grabs the doc 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 docs = site.data.docs | map: 'docs' | 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 document in docs %}
{% assign document_url = document | prepend:"/docs/" | append:"/" %}
{% if document_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 = docs[previous] | prepend:"/docs/" | 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 = docs[next] | prepend:"/docs/" | append:"/" %}
<a href="{{ next_page }}" class="next">Next</a>
{% endif %}
</div>
</div>
<div class="clear"></div>
{% break %}
{% endif %}
{% endfor %}

View File

@@ -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 %}

View File

@@ -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>

View File

@@ -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>

View File

@@ -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 %}

View File

@@ -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>

View File

@@ -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>

View File

@@ -1,18 +0,0 @@
---
layout: default
---
<section class="standalone">
<div class="grid">
<div class="unit whole">
<article>
<h1>{{ page.title }}</h1>
{{ content }}
</article>
</div>
<div class="clear"></div>
</div>
</section>

View File

@@ -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> &nbsp;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>

View File

@@ -1,19 +0,0 @@
---
title: "Jekyll Meet & Greet at GitHub HQ"
date: "2015-01-20 19:23:12 -0800"
author: parkr
categories: [meetup]
---
Hey! Our friends at GitHub have agreed to host a Jekyll meet & greet on
**February 5, 2015 at 7pm**. The event will be hosted at
[GitHub's Headquarters](https://goo.gl/maps/Bmy7i)
here in San Francisco, CA. Pizza & beer will be available for those interested,
and there will be much time to sit and chat about all things Jekyll. This would
be an especially good time to get help with bugs you've encountered or to talk
over a potential feature with the core team in attendance.
A special thanks to [@gjtorikian](https://github.com/gjtorikian) for making this
all possible! You rock.
We look forward to meeting all you fine folks. Cheers!

View File

@@ -1,39 +0,0 @@
---
title: 'Jekyll 3.0.0.beta1 Released'
date: 2015-01-24 00:42:31 -0800
author: parkr
version: 3.0.0.beta1
categories: [release]
---
Hey!
Exciting news! First beta for Jekyll 3 is out. Check out the [sizable
changelog](https://github.com/jekyll/jekyll/blob/v3.0.0.beta1/History.markdown#head)
to get a feel for what changes are afoot. Key features:
1. **Speed.** Jekyll now features incremental regeneration and greatly
improved problematic code that caused slow-downs.
2. Gobs of bugfixes and customization.
3. Uniformity and sanity to Jekyll extensions of Liquid.
To install just run:
{% highlight shell %}
$ gem install jekyll --pre
{% endhighlight %}
Future versions will include [some awesome new
features](https://github.com/jekyll/jekyll/issues/3324) that we haven't
built yet. If you see one you want to tackle, submit a PR & you'll be
featured in the Jekyll 3.0 release post as a contributor to that epic
release.
Please file bugs as you encounter them, being sure to include your version
of Ruby, the Jekyll version, and (if possible) a link to your site so we
can reproduce.
If you think there's room for improvement in the UX, also do let us know.
We're always looking to make Jekyll easier to use!
Happy Jekylling!

View File

@@ -1,14 +0,0 @@
---
title: 'Join the Discussion at Jekyll Talk'
date: 2015-02-26 21:06:51 -0800
author: alfredxing
categories: [community]
---
We're super excited to announce the launch of [Jekyll Talk](https://talk.jekyllrb.com), a Discourse forum for anything related to Jekyll!
The forum was set up by [@envygeeks](https://github.com/envygeeks) to build a community more accessible to Jekyll users and more suitable for general discussion.
There's already been a lot of interesting topics, including a [site showcase](https://talk.jekyllrb.com/t/showcase-sites-made-using-jekyll/18) and [a poll for Jekyll 3.0 priorities](https://talk.jekyllrb.com/t/poll-installation-priorities-for-3-0/106/9).
Come join the fun!

View File

@@ -1,34 +0,0 @@
---
title: 'Jekyll 3.0 Released'
date: 2015-10-26 15:37:30 -0700
author: parkr
version: 3.0
categories: [release]
---
The much-anticipated Jekyll 3.0 has been released! Key changes:
- Incremental regeneration (experimental, enable with `--incremental`)
- Liquid profiler (add `--profile` to a build or serve)
- Hook plugin API (no more monkey-patching!)
- Dependencies reduced from 14 to 8, none contain C extensions. We're hoping to reduce this even more in the future.
- Changed version support: no support for Ruby 1.9.3, added basic JRuby support. Better Windows support.
- Extension-less URLs
- `site.collections` is an array of collections, thus:
- `collection[0]` becomes `collection.label`
- `collection[1]` becomes `collection`
- Default highlighter is now Rouge instead of Pygments
- Lots of performance improvements
- ... and lots more!
We also added a [Code of Conduct](/docs/conduct/) to encourage a happier, nicer community where contributions and discussion is protected from negative behaviour.
A huge shout-out to the amazing Jekyll Core Team members Jordon Bedwell, Alfred Xing, and Matt Rogers for all their hard work in making Jekyll 3 the best release yet.
We also added [Jekyll Talk](https://talk.jekyllrb.com), managed solely by Jordon, which offers a modern forum experience for Jekyllers across the globe to talk and learn about Jekyll!
As always, check out the [full history](/docs/history/#v3-0-0) for more details.
Our contributors are the core of what makes Jekyll great! Many thanks to the 132 contributors who made this release possible (in alphabetical order): AJ Acevedo, Adam Richeimer, Alan Scherger, Alfred Xing, Anatol Broder, Andrew Dunning, Anna Debenham, Anton, Arne Gockeln, Arthur Hammer, Arthur Neves, BRAVO, Ben Balter, Bernardo Dias, BigBlueHat, Brandon Mathis, Bruce Smith, Cai⚡, Carlos Matallín, ChaYoung You, Christian Vuerings, Cory Simmons, David Herman, David Silva Smith, David Smith, David Wales, David Williamson, DigitalSparky, Dimitri König, Dominik, Eduardo Boucas, Eduardo Bouças, Eduardo Bouças, Erlend Sogge Heggen, Eugene Pirogov, Ezmyrelda Andrade, Fabian Rodriguez, Fabian Tamp, Fabio Niephaus, Falko Richter, Florian Weingarten, Fonso, Garen Torikian, Guillaume LARIVIERE, Günter Kits, I´m a robot, Jason Ly, Jedd Ahyoung, Jensen Kuras, Jesse Pinho, Jesse W, Jim Meyer, Joel Glovier, Johan Bové, Joop Aué, Jordan Thornquest, Jordon Bedwell, Joseph Anderson, Julien Bourdeau, Justin Weiss, Kamil Dziemianowicz, Kevin Locke, Kevin Ushey, Leonard, Lukas, Mads Ohm Larsen, Malo Skrylevo, Marcus Stollsteimer, Mark Phelps, Mark Tareshawty, Martijn den Hoedt, Martin Jorn Rogalla, Martin Rogalla, Matt Rogers, Matt Sheehan, Matthias Nuessler, Max, Max Beizer, Max White, Merlos, Michael Giuffrida, Michael Tu, Mike Bland, Mike Callan, MonsieurV, Nate Berkopec, Neil Faccly, Nic West, Nicholas Burlett, Nicolas Hoizey, Parker Moore, Pascal Borreli, Pat Hawks, Paul Rayner, Pedro Euko, Peter Robins, Philipp Rudloff, Philippe Loctaux, Rafael Picanço, Renaud Martinet, Robert Papp, Ryan Burnette, Ryan Tomayko, Seb, Seth Warburton, Shannon, Stephen Crosby, Stuart Kent, Suriyaa Kudo, Sylvester Keil, Tanguy Krotoff, Toddy69, Tom Johnson, Tony Eichelberger, Tunghsiao Liu, Veres Lajos, Vitaly Repin, Will Norris, William Entriken, XhmikosR, chrisfinazzo, eksperimental, hartmel, jaybe@jekyll, kaatt, nightsense, nitoyon, robschia, schneems, sonnym, takuti, and tasken.
Happy Jekylling!

View File

@@ -1,24 +0,0 @@
---
title: 'Jekyll 3.0.1 Released'
date: 2015-11-17 22:04:39 -0800
author: parkr
version: 3.0.1
categories: [release]
---
Hey, folks! Bunch of bug fixes here. Notables:
* Only superdirectories of `_posts` will be categories.
* `:title` in permalink templates are now properly cased as before
* `.jekyll-metadata` being erroneously written when not using incremental build.
* Failure in liquid will now always fail the `jekyll` process.
* All hooks should now be properly registered & documented
And a bunch more changes which you can see over in the
[changelog](/docs/history).
Thanks to the 17 developers who contributed code and documentation to this
patch release: Alfred Xing, Christian Trosell, Jordan Thornquest, Jordon
Bedwell, Larry Fox, Lawrence Murray, Lewis Cowles, Matt Rogers, Nicole
White, Parker Moore, Paul Robert Lloyd, Sarah Kuehnle, Vincent Wochnik,
Will Norris, XhmikosR, chrisfinazzo, and rebornix.

View File

@@ -1,18 +0,0 @@
---
title: 'Jekyll 3.0.2 Released'
date: 2016-01-20 14:08:18 -0800
author: parkr
version: 3.0.2
categories: [release]
---
A crucial bug was found in v3.0.1 which caused invalid post dates to go
unnoticed in the build chain until the error that popped up was unhelpful.
v3.0.2 [throws errors as you'd expect](https://github.com/jekyll/jekyll/issues/4375)
when there is a post like `_posts/2016-22-01-future.md` or a post has an
invalid date like `date: "tuesday"` in their front matter.
This should make the experience of working with Jekyll just a little
better.
Happy Jekylling!

View File

@@ -1,49 +0,0 @@
---
title: 'Jekyll 3.1.0 Released'
date: 2016-01-24 13:16:12 -0800
author: parkr
version: 3.1.0
categories: [release]
---
Happy weekend! To make your weekend all the better, we have just released
v3.1.0 of Jekyll.
There are _lots_ of great performance improvements, including a huge one
which is to use Liquid drops instead of hashes. Much of the slowness in
Jekyll is due to Jekyll making lots of objects it doesn't need to make.
By making these objects only as they're needed, we can speed up Jekyll
considerably!
Some other highlights:
* Fix: `permalink`s with non-HTML extensions will not be honored
* Fix: `jekyll clean` now accepts build flags like `--source`.
* Enhancement: `include` tags can now accept multiple liquid variables
* Feature: adds new `sample` liquid tag which gets random element from an array
* Fix: Jekyll will read in files with YAML front matter that has extraneous
spaces after the first line
* Enhancement: extract the `title` attribute from the filename for
collection items without a date
* Fix: gracefully handle empty configuration files
... and [a whole bunch more](/docs/history/#v3-1-0)!
Please [file a bug]({{ site.repository }}/issues/new?title=Jekyll+3.1.0+Issue:)
if you encounter any issues! As always, [Jekyll Talk](https://talk.jekyllrb.com)
is the best place to get help if you're encountering a problem.
Special thanks to all our amazing contributors who helped make v3.1.0 a
possibility:
Alex J Best, Alexander Köplinger, Alfred Xing, Alistair Calder, Atul
Bhosale, Ben Orenstein, Chi Trung Nguyen, Conor O'Callaghan, Craig P.
Motlin, Dan K, David Burela, David Litvak Bruno, Decider UI, Ducksan Cho,
Florian Thomas, James Wen, Jordon Bedwell, Joseph Wynn, Kakoma, Liam
Bowers, Mike Neumegen, Nick Quaranto, Nielsen Ramon, Olivér Falvai, Pat
Hawks, Paul Robert Lloyd, Pedro Euko, Peter Suschlik, Sam Volin, Samuel
Wright, Sasha Friedenberg, Tim Cuthbertson, Vincent Wochnik, William
Entriken, Zshawn Syed, chrisfinazzo, ducksan cho, leethomas,
midnightSuyama, musoke, and rebornix
Happy Jekylling!

View File

@@ -1,32 +0,0 @@
---
title: 'Jekyll 3.1.1 Released'
date: 2016-01-28 17:21:50 -0800
author: parkr
version: 3.1.1
categories: [release]
---
This release squashes a few bugs :bug: :bug: :bug: noticed by a few
wonderful Jekyll users:
* If your `permalink` ended with a `/`, your URL didn't have any extension,
even if you wanted one
* We now strip the BOM by default per Ruby's `IO.open`.
* `page.dir` will not always end in a slash.
We also updated our [Code of Conduct](/docs/conduct/) to the latest version of
the Contributor Covenant. The update includes language to ensure that the
reporter of the incident remains confidential to non-maintainers and that
all complaints will result in an appropriate response. I care deeply about
Jekyll's community and will do everything in my power to ensure it is a
welcoming community. Feel free to reach out to me directly if you feel
there is a way we can improve the community for everyone! If you're
interested in more details, [there is a diff for
that](https://github.com/ContributorCovenant/contributor_covenant/blob/v1_4/diffs/1_3_vs_1_4.patch).
See links to the PR's on [the history page](/docs/history/#v3-1-1).
Thanks to Jordon Bedwell, chrisfinazzo, Kroum Tzanev, David Celis, and
Alfred Xing for their commits on this latest release! :sparkles:
Happy Jekylling!

View File

@@ -1,31 +0,0 @@
---
title: 'Jekyll 3.0.3 Released'
date: 2016-02-08 10:39:08 -0800
author: parkr
version: 3.0.3
categories: [release]
---
[GitHub Pages upgraded to Jekyll 3.0.2][1] last week. With a testbed of
over a million sites, this really put Jekyll 3 through the wringer. This
release addresses a handful of bugs that were surfaced as a result. The
fixes:
* Fix problem where outputting to a folder would have two extensions
* Handle tildes (`~`) in filenames properly
* Fix issue when comparing documents without dates
* Include line numbers in liquid error output
Read more on the [changelog](/docs/history/#v3-0-3) with links to the
related patches.
Please keep [submitting bugs][2] as you find them! Please do take a look
[in our various help resources](/help/) before filing a bug and use [our
forum][3] for asking questions and getting help on a specific problem
you're having.
Happy Jekylling!
[1]: https://github.com/blog/2100-github-pages-now-faster-and-simpler-with-jekyll-3-0
[2]: {{ site.repository }}/issues
[3]: https://talk.jekyllrb.com/

View File

@@ -1,19 +0,0 @@
---
title: 'Jekyll 3.1.2 Released!'
date: 2016-02-19 15:24:00 -0800
author: parkr
version: 3.1.2
categories: [release]
---
Happy Friday from sunny California! Today, we're excited to announce the release of Jekyll v3.1.2, which comes with some crucial bug fixes:
* If a syntax error is encountered by Liquid, it will now print the line number.
* A nasty war between symbols and strings in our configuration hash caused kramdown syntax highlighting to break. That has been resolved; you stand victorious!
* A tilde at the beginning of a filename will no longer crash Jekyll.
* The `titleize` filter mistakenly dropped words that were already capitalized. Fixed!
* Permalinks which end in a slash will now always output as a folder with an `index.html` inside.
Nitty-gritty details, like always, are available in the [history](/docs/history/).
Thanks to those who contributed to this release: Alfred Xing, atomicules, bojanland, Brenton Horne, Carlos Garcés, Cash Costello, Chris, chrisfinazzo, Daniel Schildt, Dean Attali, Florian Thomas, Jordon Bedwell, Juuso Mikkonen, Katya Demidova, lonnen, Manabu Sakai, Michael Lee, Michael Lyons, Mitesh Shah, Nicolas Hoizey, Parker Moore, Pat Hawks, Prayag Verma, Robert Martin, Suriyaa Kudo, and toshi.

View File

@@ -1,16 +0,0 @@
---
title: Making it easier to contribute to Jekyll
description: We've made it easier to contribute to Jekyll by updating our contributing documentation and introducing Jekyll Affinity Teams, teams dedicated to specific aspects of the project.
author: benbalter
categories: [community]
---
Jekyll is an open source project, built one contribution at a time by community members just like you. These community contributions can come in many forms beyond just writing code, from reporting an issue or suggesting a new feature to improving documentation or providing feedback on proposed changes.
If you've been looking to get involved with the Jekyll community, but didn't know, we've recently made it easier to contribute to Jekyll in two ways:
First, we've completely rewritten [the project's contributing guidelines](https://jekyllrb.com/docs/contributing/), outlining [the various ways you can contribute](https://jekyllrb.com/docs/contributing/#ways-to-contribute), and including better instructions for [submitting proposed changes via GitHub.com](https://jekyllrb.com/docs/contributing/#submitting-a-pull-request-via-githubcom) or for [submitting your first code improvement](https://jekyllrb.com/docs/contributing/#code-contributions). And if you have any feedback, we'd love to hear it! Simply click the "improve this page" button in the top right corner of the contributing documentation.
Second, this week, we created six community interest groups, we're calling [Jekyll affinity teams](https://teams.jekyllrb.com). If you're interested in a particular aspect of the project (or just want to learn more), you can join any one of these teams (or two, or three), to participate in discussions about potential bugs and proposed improvements. And the best part is there's no commitment. If you just want to listen, or if at any point you want to leave (or switch teams), that's totally fine. We won't say a thing. To learn more about the various affinity teams, or to join one (please do!), just head on over to [teams.jekyllrb.com](https://teams.jekyllrb.com/).
We hope these changes will make it easier for you to make your first (or second, or third) contribution to Jekyll today. Thanks for helping to make Jekyll awesome!

View File

@@ -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!

View File

@@ -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!

View File

@@ -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!

View File

@@ -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!

View File

@@ -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!

View File

@@ -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!

View File

@@ -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!

View File

@@ -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!

View File

@@ -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!

View File

@@ -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!

View File

@@ -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!

View File

@@ -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!

Some files were not shown because too many files have changed in this diff Show More