This commit fixes a minor regression introduced in the commit e10a909
Prefer using `Regexp#match` because `@file` or `file` in these lines
could be `nil` if the `tag_markup` is just whitespace. In that scenario,
Jekyll should proceed to the validation logic and bail instead of raising
a `NoMethodError` exception.
#7464 and #7671 erroneously made changes to the auto-generated document
`docs/_docs/contributing.md` instead of the source file
`.github/CONTRIBUTING.markdown`
➜ rake site:latest_version
rake aborted!
LocalJumpError: unexpected return
/jekyll/rake/site.rake:89:in `block (2 levels) in <top (required)>'
Tasks: TOP => site:latest_version
(See full trace by running task with --trace)
* Revert "Refactor `highlight` tag to behave like the `raw` tag (#6821)"
This reverts commit 36404b9a43.
* use Liquid `raw` in upgrading document
* let the minor improvements stay
* Revert entry in History.markdown
Revert "Add missing divider in upgrading-guide"
This reverts commit d8c745ca30.
Revert "Update history to reflect merge of #7521"
This reverts commit 7ee2e26d6c.
Revert "Upgrade WinTZ utility to use TZInfo-2.0"
This reverts commit 13cbef4221.
Lock use of `tzinfo` gem to v1.x
Removes the following noise from test logs:
```
Input: '' is entirely stopwords or words with 2 or fewer characters.
Classifier-Reborn cannot handle this document properly.
```
Screenshots are better now but with Lazyloading it feels really slow. 🐢
Ideally we'd cache and use the former screenshot as placeholder and replace it with the newer version.
Hi, I'm making updates for Open Collective. Either you or a supporter signed this repo up for Open Collective. This pull request adds backers and sponsors from your Open Collective https://opencollective.com/jekyll❤️
It adds two badges at the top to show the latest number of backers and sponsors. It also adds placeholders so that the avatar/logo of new backers/sponsors can automatically be shown without having to update your README.md. [more info](https://github.com/opencollective/opencollective/wiki/Github-banner). See how it looks on this [repo](https://github.com/apex/apex#backers).
You can also add a postinstall script to let people know after npm|yarn install that you are welcoming donations (optional). [More info](https://github.com/OpenCollective/opencollective-cli)
You can also add a "Donate" button to your website and automatically show your backers and sponsors there with our widgets. Have a look here: https://opencollective.com/widgets
P.S: As with any pull request, feel free to comment or suggest changes. The only thing "required" are the placeholders on the README because we believe it's important to acknowledge the people in your community that are contributing (financially or with code!).
Thank you for your great contribution to the open source community. You are awesome! 🙌
And welcome to the open collective community! 😊
Come chat with us in the #opensource channel on https://slack.opencollective.com - great place to ask questions and share best practices with other open source sustainers!
Documentation from GitHub: https://help.github.com/articles/about-codeowners/
jekyllbot does too much already -- I'd like to see GitHub help us keep organized.
This is also an exercise in logically splitting up the codebase. The build team
is pretty overloaded it looks like -- can we split anything out?
* ashmaroli-ruby-2.4.0:
test with pygments 1.1 on all ruby versions
update rubygems version on travis
use compatible versions of gems
test against ruby-2.4.0
* Update data.feature
- add .tsv
- add .csv with `\t`
- add .csv with `;`
* Fix Appveyor with dst-aware cucumber steps
* Check for given content in posts
* mention Ruby > 2.1.0 in docs
* Update history to reflect merge of #5983 [ci skip]
* Update history to reflect merge of #5961 [ci skip]
* Update data_reader.rb
- add .tsv support with tab separated columns
- not adding support for auto-detecting `:col_sep`
ftp://ftp.iana.org/assignments/media-types/text/tab-separated-values
https://www.ietf.org/rfc/rfc4180.txt (CSV)
https://ruby-doc.org/stdlib-2.4.1/libdoc/csv/rdoc/CSV.html
* Update data.feature
don't do semicolons and tabs in .csv within this patch
* Update data.feature
I don't know which component replaced my tab characters by space before.
* Update data.feature
t
* Update data_reader.rb
add a single space to satisfy format checker
Removed the paragraph telling a user to visit the navigations page to learn how to build more robust navigation.
The permalink was broken since Navigation no longer exists and no other suitable substitute (closest being ./permalinks) fits the description.
I didn't know the difference between cgi_escape and uri_escape until it bit me when I had a colon in a title I used uri_escape on. Addressable::URI.encode (from addressable 2.4.0 and later) thought it was a URI and raised an error. I should have been using cgi_escape, which is for strings that will be added to URIs and not uri_escape, which is for encoding strings that are already in a URI.
This commit borrows from the addressable docs to make it more specific so that readers choose uri_escape when they already have a URI and cgi_escape when they are just escaping a plain string.
Offenses:
test/test_static_file.rb:151:9: C: [Corrected] Style/TrailingCommaInLiteral: Put a comma after the last item of a multiline hash.
"collection" => nil
^^^^^^^^^^^^^^^^^^^^^^
I moved the section about liquid and yaml to the end and shortened it. i also clarified that isn't an order-of-interpretation issue why liquid doesn't render in yaml. I also fixed the type with HMTL.
This tutorial defines Jekyll's "order of interpretation," as @swizca called it in [#5808](https://github.com/jekyll/jekyll/pull/5698). This tutorial makes it clear how Jekyll processes files as it renders the static HTML output.
This order-of-interpretation info is important for troubleshooting and generally understanding Jekyll. It's important to know how Jekyll generates out the files, what rules it uses, what order it processes things, and so forth.
(Note: Please process 5698 before this request, because 5698 includes the tutorial collection/navigation that this tutorial fits into. I also need to update this commit to add a link in the Tutorials nav to this topic, but I'm waiting for 5698 to be merged so that menu becomes available.)
@jekyll/documentation
@dirtyf
* master: (39 commits)
Update history to reflect merge of #5798 [ci skip]
Update history to reflect merge of #5822 [ci skip]
use logger.info
run codeclimate after success
Update history to reflect merge of #5819 [ci skip]
Fixed inaccuracy in "Built-in permalink styles" docs [skip ci]
Update history to reflect merge of #5802 [ci skip]
Update history to reflect merge of #5811 [ci skip]
Update history to reflect merge of #5690 [ci skip]
Update history to reflect merge of #5815 [ci skip]
Review CI pages
Rework CI doc to include multiple providers.
Update history to reflect merge of #5812 [ci skip]
Add jekyll-ga plug-in
Update configuration.md
Add mention of classifier-reborn for LSI
Update history to reflect merge of #5810 [ci skip]
Got that diaper money?
Added note about --blank flag
Update history to reflect merge of #5797 [ci skip]
...
When viewing a page, it's kind of hard to see what page you're viewing. The little triangle graphic pointing to the page is too subtle. Making the link to the current page orange (the same as the hover color) would make it visually more apparent where you are in the navigation. Here's a screenshot showing the change: [https://www.screencast.com/t/e6NKerSAUL](https://www.screencast.com/t/e6NKerSAUL). The link to the current page is orange even when I'm not hovering over the link with my mouse.
Must be either:
> Rather than typing `permalink: /:categories/:year/:month/:day/:title/`, you can just type `permalink: pretty`.
or:
> Rather than typing `permalink: /:categories/:year/:month/:day/:title.html`, you can just type `permalink: date`.
I guess the former was meant to write because the latter was already mentioned in "Where to configure permalinks" section.
If we do a Dir.chdir before Configuration::DEFAULTS is initialized, then its source and destination values will not be what we expect.
We expect that Dir.pwd should stay as the root of the repo but there are some errant calls to Dir.chdir without a block that are still
not yet cleaned up.
1. Addition of *Running Jekyll on Ubuntu* section, to address Ubuntu stumbling block as per https://github.com/jekyll/jekyll/issues/5719.
2. Restructuring, and I hope I understood correctly when NodeJS/Python are/aren't required.
3. Gentler wording – it's probably not a good idea to tell punters who hit this page because they ran into trouble that installing Jekyll *is* easy and straight-forward; it *ought to be* straight-forward. (There's always the potential for pain and confusion if not all dependencies are in place.)
It turns out Liquid throws an error when you write `{% if {{ include.url }} %}` instead of `{% if {{include.url}} %}`. I updated the examples here to omit the spacing. To avoid inconsistency, I just omitted the spacing from all curly braces. Also added a note explaining the issue and put the blame on Liquid.
- made updates from Parkr's review
- update to Extensionless permalinks section
- update to note about not using built-in perm styles in front matter
- update for readability in places
When running 'script/stackprof object', I noticed that it would be helpful to see
GC information. It appears we create a lot of junk -- a source of optimization if
we decide to go down that path.
An average Jekyll build doesn't run a GC, but auto-regeneration likely would eventually
require a GC run and it would be interesting to see if we can reduce how much we throw
away with each call to 'site.process'.
It turns out Liquid throws an error when you write `{% if {{ include.url }} %}` instead of `{% if {{include.url}} %}`. I updated the examples here to omit the spacing. To avoid inconsistency, I just omitted the spacing from all curly braces. Also added a note explaining the issue and put the blame on Liquid.
I added a documentation page on how to build navigation for your site. This topic is primarily intended for users who have a lot of pages on their site (such as for documentation websites), and want to build a more robust sidebar navigation.
Jekyll combines Liquid with YAML in interesting ways that aren't really documented clearly in the existing docs, except for a brief reference [here](http://jekyllrb.com/docs/datafiles/#the-data-folder). You can read about Liquid on Shopify and YAML in YAML's docs, but exactly how you store YAML files in a Jekyll project and iterate through them using Liquid loops and filters to generate lists of pages is something that isn't clear to a lot of people. (You can see origins of these questions in [previous help issues](https://github.com/jekyll/jekyll-help/issues/266).) The documentation on navigation would fit well into the Jekyll docs.
I created more advanced details about includes and created a new page for it instead of putting all the info on the templates page.
See https://github.com/jekyll/jekyll/pull/5630 for more details on the update.
@jekyll/documentation
@DirtyF
Previously, the post_url function would give error messages when the
post being listed contained special characters for use in regular
expressions. These special characters are now escaped using
Regexp.escape.
Prior to the change backticks were used in an attempt to create a
code block. The problem is that inside block level HTML tags Markdown
is not supported. I have replaced the backticks with a combination of
HTML tags in order to approximately simulate the appearance of a code
block. The docs suggest possible use of span tags in place of the
surrounding div tags as a solution to getting the Markdown to render.
I tried this but no success.
This change improves the readers understanding of the information,
because the reader doesn't have to make sense of raw markdown.
In case of the GitHub example links like `<a href="https://github.com/{{ org.username }}">` with the full URL plus the variable were used, but for the Twitter example link only the `{{ author.name }}` was set as `href`.
Adding a link to updated installation instructions for Jekyll 3 and Ruby 2.2.5. These instructions were adapted and significantly updated from the earlier work of Julian Thilo which is now outdated.
Avoiding errors on `jekyll serve`
```
# jekyll serve -H 0.0.0.0
Configuration file: /jekyll-offline-docs/site/_config.yml
Configuration file: /jekyll-offline-docs/site/_config.yml
Source: /jekyll-offline-docs/site
Destination: /jekyll-offline-docs/site/_site
Incremental build: disabled. Enable with --incremental
Generating...
Conversion error: Jekyll::Converters::Scss encountered an error while converting 'css/screen.scss':
Invalid US-ASCII character "\xE2" on line 30
jekyll 3.3.0 | Error: Invalid US-ASCII character "\xE2" on line 30
```
And line 97 when 30 is adjusted...
Added link to my Jekyll plugin: https://github.com/snaptortoise/jekyll-pinboard-plugin. Interfaces with the Pinboard API to make data for specified tags available to the template, sort of similar to the built-in Data Files support.
I was reading through the "Upgrading from 2.x to 3.x" page in the docs and noticed some of the markdown was janky. I made these small edits to fix the formatting and conform with how it's done elsewhere.
this cucumber feature follows the likely steps a theme designer would take
to build a Rubygem of his theme starting from the scaffolding generated by
`jekyll new-theme` command and further checks if the gem built actually
has the files he planned to include.
2016-09-29 06:36:24 +05:30
618 changed files with 27407 additions and 10563 deletions
@@ -4,10 +4,7 @@ Hi there! Interested in contributing to Jekyll? We'd love your help. Jekyll is a
## 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/).
See the [support guidelines](https://jekyllrb.com/docs/support/)
## Ways to contribute
@@ -15,9 +12,9 @@ Whether you're a developer, a designer, or just a Jekyll devotee, there are lots
* [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.
* 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
@@ -28,7 +25,7 @@ Whether you're a developer, a designer, or just a Jekyll devotee, there are lots
* The more information, the better. Make judicious use of the pull request body. Describe what changes were made, why you made them, and what impact they will have for users.
* Pull request are easy and fun. If this is your first pull request, it may help to [understand GitHub Flow](https://guides.github.com/introduction/flow/).
* If 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.
@@ -52,7 +49,7 @@ That's it! You'll be automatically subscribed to receive updates as others revie
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)
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.
@@ -62,17 +59,37 @@ We want the Jekyll documentation to be the best it can be. We've open-sourced ou
### How to submit changes
You can find the documentation for jekyllrb.com in the [site](https://github.com/jekyll/jekyll/tree/master/site) directory. See the section above, [submitting a pull request](#submitting-a-pull-request) for information on how to propose a change.
You can find the documentation for jekyllrb.com in the [docs](https://github.com/jekyll/jekyll/tree/master/docs) directory. See the section above, [submitting a pull request](#submitting-a-pull-request) for information on how to propose a change.
One gotcha, all pull requests should be directed at the `master` branch (the default branch).
### Updating FontAwesome iconset for jekyllrb.com
We use a custom version of FontAwesome which contains just the icons we use.
If you ever need to update our documentation with an icon that is not already available in our custom iconset, you'll have to regenerate the iconset using Icomoon's Generator:
1. Go to <https://icomoon.io/app/>.
2. Click `Import Icons` on the top-horizontal-bar and upload the existing `<jekyll>/docs/icomoon-selection.json`.
3. Click `Add Icons from Library..` further down on the page, and add 'Font Awesome'.
4. Select the required icon(s) from the Library (make sure its the 'FontAwesome' library instead of 'IcoMoon-Free' library).
5. Click `Generate Font` on the bottom-horizontal-bar.
6. Inspect the included icons and proceed by clicking `Download`.
7. Extract the font files and adapt the CSS to the paths we use in Jekyll:
- Copy the entire `fonts` directory over and overwrite existing ones at `<jekyll>/docs/`.
- Copy the contents of `selection.json` and overwrite existing content inside `<jekyll>/docs/icomoon-selection.json`.
- Copy the entire `@font-face {}` declaration and only the **new-icon(s)' css declarations** further below, to update the
- Fix paths in the `@font-face {}` declaration by adding `../` before `fonts/FontAwesome.*` like so:
`('../fonts/Fontawesome.woff?9h6hxj')`.
### Adding plugins
If you want to add your plugin to the [list of plugins](https://jekyllrb.com/docs/plugins/#available-plugins), please submit a pull request modifying the [plugins page source file](https://github.com/jekyll/jekyll/blob/master/site/_docs/plugins.md) by adding a link to your plugin under the proper subheading depending upon its type.
If you want to add your plugin to the [list of plugins](https://jekyllrb.com/docs/plugins/#available-plugins), please submit a pull request modifying the [plugins page source file](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.
Interested 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
@@ -80,7 +97,7 @@ Any time you propose a code change, you should also include updates to the docum
#### Documentation
If your contribution changes any Jekyll behavior, make sure to update the documentation. Documentation lives in the `site/_docs` folder (spoiler alert: it's a Jekyll site!). If the docs are missing information, please feel free to add it in. Great docs make a great project. Include changes to the documentation within your pull request, and once merged, `jekyllrb.com` will be updated.
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
@@ -94,25 +111,39 @@ If your contribution changes any Jekyll behavior, make sure to update the docume
* Don't bump the Gem version in your pull request (if you don't know what that means, you probably didn't).
* You can use the command `script/console` to start a REPL to explore the result of
Jekyll's methods. It also provides you with helpful methods to quickly create a
site or configuration. [Feel free to check it out!](https://github.com/jekyll/jekyll/blob/master/script/console)
* Previously, we've used the WIP Probot app to help contributors determine whether their pull request is ready for review. Please use a [draft pull request](https://help.github.com/en/articles/about-pull-requests#draft-pull-requests) instead. When you're ready, [mark the pull request as ready for review](https://help.github.com/en/articles/changing-the-stage-of-a-pull-request)
## 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:
* If you have a question about using Jekyll, start a discussion on [Jekyll Forum](https://talk.jekyllrb.com/) or [StackOverflow](https://stackoverflow.com/questions/tagged/jekyll)
* Chat with Jekyllers — Join [our Gitter channel](https://gitter.im/jekyll/jekyll) or [our IRC channel on Freenode](irc:irc.freenode.net/jekyll)
There are a bunch of helpful community members on these services that should be willing to point you in the right direction.
## Report a bug
* If you think you've found a bug within a Jekyll plugin, open an issue in that plugin's repository — First [look for the plugin on rubygems](https://rubygems.org/) then click on the `Homepage` link to access the plugin repository.
* If you think you've found a bug within Jekyll itself, [open an issue](https://github.com/jekyll/jekyll/issues/new).
Thanks for opening this pull request! The maintainers of this repository would appreciate it if you would update some of our documentation based on your changes.
This issue is reserved for people who never contributed to Open Source before. We know that the process of creating a pull request is the biggest barrier for new contributors. This issue is for you 💝
[About First Timers Only](http://www.firsttimersonly.com/).
### 🤔 What you will need to know.
Nothing. This issue is meant to welcome you to Open Source :) We are happy to walk you through the process.
### 📋 Step by Step
- [ ] 👌 **Join the team**: Add yourself to a Jekyll affinity team.
Go to [teams.jekyllrb.com](https://teams.jekyllrb.com/) and join a team that best fits your interests. Once you click the link to join a team, you will soon receive an email inviting you to join the Jekyll organization.
- [ ] 🙋 **Claim this issue**: Comment below.
Leave a comment that you have claimed this issue.
- [ ] 📝 **Update** the file [$FILENAME]($BRANCH_URL) in the `$REPO` repository (press the little pen Icon) and edit the line as shown below.
```diff
$DIFF
```
- [ ] 💾 **Commit** your changes
- [ ] 🔀 **Start a Pull Request**. There are two ways how you can start a pull request:
1. If you are familiar with the terminal or would like to learn it, [here is a great tutorial](https://egghead.io/series/how-to-contribute-to-an-open-source-project-on-github) on how to send a pull request using the terminal.
2. You can [edit files directly in your browser](https://help.github.com/articles/editing-files-in-your-repository/)
- [ ] 🏁 **Done** Ask in comments for a review :)
### 🤔❓ Questions
Leave a comment below!
This issue was created by [First-Timers-Bot](https://github.com/hoodiehq/first-timers-bot).
In the interest of fostering an open and welcoming environment, we as
contributors and maintainers pledge to making participation in our project and
our community a harassment-free experience for everyone, regardless of age, body
size, disability, ethnicity, sex characteristics, gender identity and expression,
level of experience, education, socio-economic status, nationality, personal
appearance, race, religion, or sexual identity and orientation.
## Our Standards
Examples of behavior that contributes to creating a positive environment
include:
* Using welcoming and inclusive language
* Being respectful of differing viewpoints and experiences
* Gracefully accepting constructive criticism
* Focusing on what is best for the community
* Showing empathy towards other community members
Examples of unacceptable behavior by participants include:
* The use of sexualized language or imagery and unwelcome sexual attention or
advances
* Trolling, insulting/derogatory comments, and personal or political attacks
* Public or private harassment
* Publishing others' private information, such as a physical or electronic
address, without explicit permission
* Other conduct which could reasonably be considered inappropriate in a
professional setting
## Our Responsibilities
Project maintainers are responsible for clarifying the standards of acceptable
behavior and are expected to take appropriate and fair corrective action in
response to any instances of unacceptable behavior.
Project maintainers have the right and responsibility to remove, edit, or
reject comments, commits, code, wiki edits, issues, and other contributions
that are not aligned to this Code of Conduct, or to ban temporarily or
permanently any contributor for other behaviors that they deem inappropriate,
threatening, offensive, or harmful.
## Scope
This Code of Conduct applies both within project spaces and in public spaces
when an individual is representing the project or its community. Examples of
representing a project or community include using an official project e-mail
address, posting via an official social media account, or acting as an appointed
representative at an online or offline event. Representation of a project may be
further defined and clarified by project maintainers.
## Enforcement
Instances of abusive, harassing, or otherwise unacceptable behavior may be
reported by contacting the project team at [olivia@jekyllrb.com](mailto:olivia@jekyllrb.com). All
complaints will be reviewed and investigated and will result in a response that
is deemed necessary and appropriate to the circumstances. The project team is
obligated to maintain confidentiality with regard to the reporter of an incident.
Further details of specific enforcement policies may be posted separately.
Project maintainers who do not follow or enforce the Code of Conduct in good
faith may face temporary or permanent repercussions as determined by other
members of the project's leadership.
## Attribution
This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4,
available at [https://www.contributor-covenant.org/version/1/4/code-of-conduct.html](https://www.contributor-covenant.org/version/1/4/code-of-conduct.html)
[homepage]: https://www.contributor-covenant.org
For answers to common questions about this code of conduct, see
@@ -22,38 +22,68 @@ Jekyll is a simple, blog-aware, static site generator perfect for personal, proj
Jekyll does what you tell it to do— no more, no less. It doesn't try to outsmart users by making bold assumptions, nor does it burden them with needless complexity and configuration. Put simply, Jekyll gets out of your way and allows you to concentrate on what truly matters: your content.
* [Install](https://jekyllrb.com/docs/installation/) the gem
* Read up about its [Usage](https://jekyllrb.com/docs/usage/) and [Configuration](https://jekyllrb.com/docs/configuration/)
* Take a gander at some existing [Sites](https://wiki.github.com/jekyll/jekyll/sites)
* Take a gander at some existing [Sites](https://github.com/jekyll/jekyll/wiki/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/)
## Diving In
* [Migrate](http://import.jekyllrb.com/docs/home/) from your previous system
* Learn how [Front Matter](https://jekyllrb.com/docs/front-matter/) 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
* Watch [video tutorials from Giraffe Academy](https://jekyllrb.com/tutorials/video-walkthroughs/)
## Need help?
If you don't find the answer to your problem in our [docs](https://jekyllrb.com/docs/), or in the [troubleshooting section](https://jekyllrb.com/docs/troubleshooting/), ask the [community](https://jekyllrb.com/docs/community/) for help.
## 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
[code of conduct](CODE_OF_CONDUCT.markdown) adapted from the Ruby on Rails code of
conduct.
Please adhere to this code of conduct in any interactions you have in the
Jekyll community. It is strictly enforced on all official Jekyll
repositories, websites, and resources. If you encounter someone violating
these terms, please let a maintainer ([@parkr](https://github.com/parkr), [@envygeeks](https://github.com/envygeeks), or [@mattr-](https://github.com/mattr-)) know
and we will address it as soon as possible.
these terms, please let one of our [core team members](https://jekyllrb.com/team/#core-team) know and we will address it as soon as possible.
## Diving In
## Credits
* [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
### Sponsors
Support this project by becoming a sponsor. Your logo will show up in this README with a link to your website. [Become a sponsor!](https://opencollective.com/jekyll#sponsor)
note: This file is autogenerated. Edit /CODE_OF_CONDUCT.markdown instead.
redirect_from: "/conduct/index.html"
editable: false
---
## Our Pledge
In the interest of fostering an open and welcoming environment, we as
contributors and maintainers pledge to making participation in our project and
our community a harassment-free experience for everyone, regardless of age, body
size, disability, ethnicity, sex characteristics, gender identity and expression,
level of experience, education, socio-economic status, nationality, personal
appearance, race, religion, or sexual identity and orientation.
## Our Standards
Examples of behavior that contributes to creating a positive environment
include:
* Using welcoming and inclusive language
* Being respectful of differing viewpoints and experiences
* Gracefully accepting constructive criticism
* Focusing on what is best for the community
* Showing empathy towards other community members
Examples of unacceptable behavior by participants include:
* The use of sexualized language or imagery and unwelcome sexual attention or
advances
* Trolling, insulting/derogatory comments, and personal or political attacks
* Public or private harassment
* Publishing others' private information, such as a physical or electronic
address, without explicit permission
* Other conduct which could reasonably be considered inappropriate in a
professional setting
## Our Responsibilities
Project maintainers are responsible for clarifying the standards of acceptable
behavior and are expected to take appropriate and fair corrective action in
response to any instances of unacceptable behavior.
Project maintainers have the right and responsibility to remove, edit, or
reject comments, commits, code, wiki edits, issues, and other contributions
that are not aligned to this Code of Conduct, or to ban temporarily or
permanently any contributor for other behaviors that they deem inappropriate,
threatening, offensive, or harmful.
## Scope
This Code of Conduct applies both within project spaces and in public spaces
when an individual is representing the project or its community. Examples of
representing a project or community include using an official project e-mail
address, posting via an official social media account, or acting as an appointed
representative at an online or offline event. Representation of a project may be
further defined and clarified by project maintainers.
## Enforcement
Instances of abusive, harassing, or otherwise unacceptable behavior may be
reported by contacting the project team at [olivia@jekyllrb.com](mailto:olivia@jekyllrb.com). All
complaints will be reviewed and investigated and will result in a response that
is deemed necessary and appropriate to the circumstances. The project team is
obligated to maintain confidentiality with regard to the reporter of an incident.
Further details of specific enforcement policies may be posted separately.
Project maintainers who do not follow or enforce the Code of Conduct in good
faith may face temporary or permanent repercussions as determined by other
members of the project's leadership.
## Attribution
This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4,
available at [https://www.contributor-covenant.org/version/1/4/code-of-conduct.html](https://www.contributor-covenant.org/version/1/4/code-of-conduct.html)
[homepage]: https://www.contributor-covenant.org
For answers to common questions about this code of conduct, see
Collections are a great way to group related content like members of a team or
talks at a conference.
## Setup
To use a Collection you first need to define it in your `_config.yml`. For
example here's a collection of staff members:
```yaml
collections:
- staff_members
```
You can optionally specify metadata for your collection in the configuration:
```yaml
collections:
staff_members:
people:true
```
<div class="note">
<h5>Gather your collections {%- include docs_version_badge.html version="3.7.0" -%}</h5>
<p>You can optionally specify a directory to store all your collections in the same place with <code>collections_dir: my_collections</code>.</p>
<p>Then Jekyll will look in <code>my_collections/_books</code> for the <code>books</code> collection, and
in <code>my_collections/_recipes</code> for the <code>recipes</code> collection.</p>
</div>
<div class="note warning">
<h5>Be sure to move drafts and posts into custom collections directory</h5>
<p>If you specify a directory to store all your collections in the same place with <code>collections_dir: my_collections</code>, then you will need to move your <code>_drafts</code> and <code>_posts</code> directory to <code>my_collections/_drafts</code> and <code>my_collections/_posts</code>. Note that, the name of your collections directory cannot start with an underscore (`_`).</p>
</div>
## Add content
Create a corresponding folder (e.g. `<source>/_staff_members`) and add
documents. 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 front
matter is provided, Jekyll will consider it to be a [static file](/docs/static-files/)
and copy it to the destination (e.g. `_site`) without processing. If front matter
is provided, Jekyll will process the file in your collection but will not write to disk
unless `output: true` is set in the collection's metadata.
For example here's how you would add a staff member to the collection set above.
The filename is `./_staff_members/jane.md` with the following content:
```markdown
---
name: Jane Doe
position: Developer
---
Jane has worked on Jekyll for the past *five years*.
```
<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>
## Output
Now you can iterate over `site.staff_members` on a page and output the content
for each staff member. Similar to posts, the body of the document is accessed
There are special [permalink variables for collections](/docs/permalinks/) to
help you control the output url for the entire collection.
## Custom Sorting of Documents
By default, documents in a collection are sorted by their paths. But you can control this sorting via the collection's metadata.
### Sort By Front Matter Key
Documents can be sorted based on a front matter key by setting a `sort_by` metadata to the front matter key string. For example,
to sort a collection of tutorials based on key `lesson`, the configuration would be:
```yaml
collections:
tutorials:
sort_by:lesson
```
The documents are arranged in the increasing order of the key's value. If a document does not have the front matter key defined
then that document is placed immediately after sorted documents. When multiple documents do not have the front matter key defined,
those documents are sorted by their dates or paths and then placed immediately after the sorted documents.
### Manually Ordering Documents
You can also manually order the documents by setting an `order` metadata with **the filenames listed** in the desired order.
For example, a collection of tutorials would be configured as:
```yaml
collections:
tutorials:
order:
- hello-world.md
- introduction.md
- basic-concepts.md
- advanced-concepts.md
```
Any documents with filenames that do not match the list entry simply gets placed after the rearranged documents. If a document is
nested under subdirectories, include them in entries as well:
```yaml
collections:
tutorials:
order:
- hello-world.md
- introduction.md
- concepts/basics.md
- concepts/advanced.md
```
If both metadata keys have been defined properly, `order` list takes precedence.
## Liquid Attributes
### Collections
Collections are also available under `site.collections`, with the metadata
you specified in your `_config.yml` (if present) and the following information:
<div class="mobile-side-scroller">
<table>
<thead>
<tr>
<th>Variable</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr>
<td>
<p><code>label</code></p>
</td>
<td>
<p>
The name of your collection, e.g. <code>my_collection</code>.
</p>
</td>
</tr>
<tr>
<td>
<p><code>docs</code></p>
</td>
<td>
<p>
An array of <a href="#documents">documents</a>.
</p>
</td>
</tr>
<tr>
<td>
<p><code>files</code></p>
</td>
<td>
<p>
An array of static files in the collection.
</p>
</td>
</tr>
<tr>
<td>
<p><code>relative_directory</code></p>
</td>
<td>
<p>
The path to the collection's source directory, relative to the site
source.
</p>
</td>
</tr>
<tr>
<td>
<p><code>directory</code></p>
</td>
<td>
<p>
The full path to the collections's source directory.
</p>
</td>
</tr>
<tr>
<td>
<p><code>output</code></p>
</td>
<td>
<p>
Whether the collection's documents will be output as individual
files.
</p>
</td>
</tr>
</tbody>
</table>
</div>
<div class="note info">
<h5>A Hard-Coded Collection</h5>
<p>In addition to any collections you create yourself, the
<code>posts</code> collection is hard-coded into Jekyll. It exists whether
you have a <code>_posts</code> directory or not. This is something to note
when iterating through <code>site.collections</code> as you may need to
filter it out.</p>
<p>You may wish to use filters to find your collection:
<code>{% raw %}{{ site.collections | where: "label", "myCollection" | first }}{% endraw %}</code></p>
</div>
<div class="note info">
<h5>Collections and Time</h5>
<p>Except for documents in hard-coded default collection <code>posts</code>, all documents in collections
you create, are accessible via Liquid irrespective of their assigned date, if any, and therefore renderable.
</p>
<p>Documents are attempted to be written to disk only if the concerned collection
metadata has <code>output: true</code>. Additionally, future-dated documents are only written if
<code>site.future</code> <em>is also true</em>.
</p>
<p>More fine-grained control over documents being written to disk can be exercised by setting
<code>published: false</code> (<em><code>true</code> by default</em>) in the document's front matter.
</p>
</div>
### Documents
In addition to any 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 front matter is
provided, Jekyll will not generate the file in your collection. If
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.
If you think you've found a bug within a Jekyll plugin, open an issue in that plugin's repository — First [look for the plugin on rubygems](https://rubygems.org/) then click on the `Homepage` link to access the plugin repository.
If you think you've found a bug within Jekyll itself, [open an issue](https://github.com/jekyll/jekyll/issues/new).
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.
Read the full [code of conduct](/docs/conduct/)
## Where to get support
If you're looking for support for Jekyll, there are a lot of options:
* Read the [Jekyll Documentation](https://jekyllrb.com/docs/)
* If you have a question about using Jekyll, start a discussion on the [Jekyll Forum](https://talk.jekyllrb.com/) or [StackOverflow](https://stackoverflow.com/questions/tagged/jekyll)
* Chat with Jekyllers — Join our [Gitter channel](https://gitter.im/jekyll/jekyll) or our [IRC channel on Freenode](irc:irc.freenode.net/jekyll)
There are a bunch of helpful community members on these services that should be willing to point you in the right direction.
**Reminder: Jekyll's issue tracker is not a support forum.**
## Ways to contribute
* [How to Contribute](/docs/contributing/)
* [How to file a bug](/docs/community/bug/)
* [Guide for maintaining Jekyll](/docs/maintaining/)
## Jekyllconf
[Watch videos](/jekyllconf/) from members of the Jekyll community speak about interesting use cases, tricks they’ve learned or meta Jekyll topics.
## Jekyll on Twitter
The [official Jekyll Twitter account](https://twitter.com/jekyllrb).
note: This file is autogenerated. Edit /CONDUCT.markdown instead.
redirect_from: "/conduct/index.html"
editable: false
---
## Our Pledge
In the interest of fostering an open and welcoming environment, we as
contributors and maintainers pledge to making participation in our project and
our community a harassment-free experience for everyone, regardless of age, body
size, disability, ethnicity, sex characteristics, gender identity and expression,
level of experience, education, socio-economic status, nationality, personal
appearance, race, religion, or sexual identity and orientation.
## Our Standards
Examples of behavior that contributes to creating a positive environment
include:
* Using welcoming and inclusive language
* Being respectful of differing viewpoints and experiences
* Gracefully accepting constructive criticism
* Focusing on what is best for the community
* Showing empathy towards other community members
Examples of unacceptable behavior by participants include:
* The use of sexualized language or imagery and unwelcome sexual attention or
advances
* Trolling, insulting/derogatory comments, and personal or political attacks
* Public or private harassment
* Publishing others' private information, such as a physical or electronic
address, without explicit permission
* Other conduct which could reasonably be considered inappropriate in a
professional setting
## Our Responsibilities
Project maintainers are responsible for clarifying the standards of acceptable
behavior and are expected to take appropriate and fair corrective action in
response to any instances of unacceptable behavior.
Project maintainers have the right and responsibility to remove, edit, or
reject comments, commits, code, wiki edits, issues, and other contributions
that are not aligned to this Code of Conduct, or to ban temporarily or
permanently any contributor for other behaviors that they deem inappropriate,
threatening, offensive, or harmful.
## Scope
This Code of Conduct applies both within project spaces and in public spaces
when an individual is representing the project or its community. Examples of
representing a project or community include using an official project e-mail
address, posting via an official social media account, or acting as an appointed
representative at an online or offline event. Representation of a project may be
further defined and clarified by project maintainers.
## Enforcement
Instances of abusive, harassing, or otherwise unacceptable behavior may be
reported by contacting the project team at [olivia@jekyllrb.com](mailto:olivia@jekyllrb.com). All
complaints will be reviewed and investigated and will result in a response that
is deemed necessary and appropriate to the circumstances. The project team is
obligated to maintain confidentiality with regard to the reporter of an incident.
Further details of specific enforcement policies may be posted separately.
Project maintainers who do not follow or enforce the Code of Conduct in good
faith may face temporary or permanent repercussions as determined by other
members of the project's leadership.
## Attribution
This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4,
available at [https://www.contributor-covenant.org/version/1/4/code-of-conduct.html](https://www.contributor-covenant.org/version/1/4/code-of-conduct.html)
[homepage]: https://www.contributor-covenant.org
For answers to common questions about this code of conduct, see
In the `build` (or `serve`) arguments, you can specify a Jekyll environment
and value. The build will then apply this value in any conditional statements
in your content.
For example, suppose you set this conditional statement in your code:
{% raw %}
```liquid
{% if jekyll.environment == "production" %}
{% include disqus.html %}
{% endif %}
```
{% endraw %}
When you build your Jekyll site, the content inside the `if` statement won't be
run unless you also specify a `production` environment in the build command,
like this:
```sh
JEKYLL_ENV=production jekyll build
```
Specifying an environment value allows you to make certain content available
only within specific environments.
The default value for `JEKYLL_ENV` is `development`. Therefore if you omit
`JEKYLL_ENV` from the build arguments, the default value will be
`JEKYLL_ENV=development`. Any content inside
{% raw %}`{% if jekyll.environment == "development" %}`{% endraw %} tags will
automatically appear in the build.
Your environment values can be anything you want (not just `development` or
`production`). Some elements you might want to hide in development
environments include Disqus comment forms or Google Analytics. Conversely,
you might want to expose an "Edit me in GitHub" button in a development
environment but not include it in production environments.
By specifying the option in the build command, you avoid having to change
values in your configuration files when moving from one environment to another.
<div class="note info">
<p>
To switch part of your config settings depending on the environment, use the <a href="/docs/configuration/options/#build-command-options">build command option</a>, for example <code>--config _config.yml,_config_development.yml</code>. Settings in later files override settings in earlier files.
Using [front matter](/docs/front-matter/) is one way that you can specify configuration in the pages and posts for your site. Setting things like a default layout, or customizing the title, or specifying a more precise date/time for the post can all be added to your page or post front matter.
Often times, you will find that you are repeating a lot of configuration options. Setting the same layout in each file, adding the same category - or categories - to a post, etc. You can even add custom variables like author names, which might be the same for the majority of posts on your blog.
Instead of repeating this configuration each time you create a new post or page, Jekyll provides a way to set these defaults in the site configuration. To do this, you can specify site-wide defaults using the `defaults` key in the `_config.yml` file in your project's root directory.
The `defaults` key holds an array of scope/values pairs that define what defaults should be set for a particular file path, and optionally, a file type in that path.
Let's say that you want to add a default layout to all pages and posts in your site. You would add this to your `_config.yml` file:
```yaml
defaults:
-
scope:
path:""# an empty string here means all files in the project
values:
layout:"default"
```
<div class="note info">
<h5>Stop and rerun `jekyll serve` command.</h5>
<p>
The <code>_config.yml</code> master configuration file contains global configurations
and variable definitions that are read once at execution time. Changes made to <code>_config.yml</code>
during automatic regeneration are not loaded until the next execution.
</p>
<p>
Note <a href="/docs/datafiles">Data Files</a> are included and reloaded during automatic regeneration.
</p>
</div>
Here, we are scoping the `values` to any file that exists in the path `scope`. Since the path is set as an empty string, it will apply to **all files** in your project. You probably don't want to set a layout on every file in your project - like css files, for example - so you can also specify a `type` value under the `scope` key.
```yaml
defaults:
-
scope:
path:""# an empty string here means all files in the project
type:"posts"# previously `post` in Jekyll 2.2.
values:
layout:"default"
```
Now, this will only set the layout for files where the type is `posts`.
The different types that are available to you are `pages`, `posts`, `drafts` or any collection in your site. While `type` is optional, you must specify a value for `path` when creating a `scope/values` pair.
As mentioned earlier, you can set multiple scope/values pairs for `defaults`.
With these defaults, all pages would use the `my-site` layout. Any html files that exist in the `projects/` folder will use the `project` layout, if it exists. Those files will also have the `page.author` [liquid variable](/docs/variables/) set to `Mr. Hyde`.
```yaml
collections:
my_collection:
output:true
defaults:
-
scope:
path:""
type:"my_collection"# a collection in your site, in plural form
values:
layout:"default"
```
In this example, the `layout` is set to `default` inside the
[collection](/docs/collections/) with the name `my_collection`.
### Glob patterns in Front Matter defaults
It is also possible to use glob patterns (currently limited to patterns that contain `*`) when matching defaults. For example, it is possible to set specific layout for each `special-page.html` in any subfolder of `section` folder. {%- include docs_version_badge.html version="3.7.0" -%}
```yaml
collections:
my_collection:
output:true
defaults:
-
scope:
path:"section/*/special-page.html"
values:
layout:"specific-layout"
```
<div class="note warning">
<h5>Globbing and Performance</h5>
<p>
Please note that globbing a path is known to have a negative effect on
performance and is currently not optimized, especially on Windows.
Globbing a path will increase your build times in proportion to the size
of the associated collection directory.
</p>
</div>
### Precedence
Jekyll will apply all of the configuration settings you specify in the `defaults` section of your `_config.yml` file. You can choose to override settings from other scope/values pair by specifying a more specific path for the scope.
You can see that in the second to last example above. First, we set the default page layout to `my-site`. Then, using a more specific path, we set the default layout for pages in the `projects/` path to `project`. This can be done with any value that you would set in the page or post front matter.
Finally, if you set defaults in the site configuration by adding a `defaults` section to your `_config.yml` file, you can override those settings in a post or page file. All you need to do is specify the settings in the post or page front matter. For example:
```yaml
# In _config.yml
...
defaults:
-
scope:
path:"projects"
type:"pages"
values:
layout:"project"
author:"Mr. Hyde"
category:"project"
...
```
```yaml
# In projects/foo_project.md
---
author:"John Smith"
layout:"foobar"
---
The post text goes here...
```
The `projects/foo_project.md` would have the `layout` set to `foobar` instead
of `project` and the `author` set to `John Smith` instead of `Mr. Hyde` when
The various Markdown renderers supported by Jekyll sometimes have extra options
available.
### Kramdown
Kramdown is the default Markdown renderer for Jekyll. Below is a list of the
currently supported options:
* **auto_id_prefix** - Prefix used for automatically generated header IDs
* **auto_id_stripping** - Strip all formatting from header text for automatic ID generation
* **auto_ids** - Use automatic header ID generation
* **coderay_bold_every** - Defines how often a line number should be made bold
* **coderay_css** - Defines how the highlighted code gets styled
* **coderay_default_lang** - Sets the default language for highlighting code blocks
* **coderay_line_number_start** - The start value for the line numbers
* **coderay_line_numbers** - Defines how and if line numbers should be shown
* **coderay_tab_width** - The tab width used in highlighted code
* **coderay_wrap** - Defines how the highlighted code should be wrapped
* **enable_coderay** - Use coderay for syntax highlighting
* **entity_output** - Defines how entities are output
* **footnote_backlink** - Defines the text that should be used for the footnote backlinks
* **footnote_backlink_inline** - Specifies whether the footnote backlink should always be inline
* **footnote_nr** - The number of the first footnote
* **gfm_quirks** - Enables a set of GFM specific quirks
* **hard_wrap** - Interprets line breaks literally
* **header_offset** - Sets the output offset for headers
* **html_to_native** - Convert HTML elements to native elements
* **line_width** - Defines the line width to be used when outputting a document
* **link_defs** - Pre-defines link definitions
* **math_engine** - Set the math engine
* **math_engine_opts** - Set the math engine options
* **parse_block_html** - Process kramdown syntax in block HTML tags
* **parse_span_html** - Process kramdown syntax in span HTML tags
* **smart_quotes** - Defines the HTML entity names or code points for smart quote output
* **syntax_highlighter** - Set the syntax highlighter
* **syntax_highlighter_opts** - Set the syntax highlighter options
* **toc_levels** - Defines the levels that are used for the table of contents
* **transliterated_header_ids** - Transliterate the header text before generating the ID
* **typographic_symbols** - Defines a mapping from typographical symbol to output characters
<div class="note warning">
<h5>There are two unsupported kramdown options</h5>
<p>
Please note that both <code>remove_block_html_tags</code> and
<code>remove_span_html_tags</code> are currently unsupported in Jekyll due
to the fact that they are not included within the kramdown HTML converter.
</p>
</div>
For more details about these options have a look at the [Kramdown configuration documentation](https://kramdown.gettalong.org/options.html).
### CommonMark
[CommonMark](https://commonmark.org/) is a rationalized version of Markdown syntax, implemented in C and thus faster than default Kramdown implemented in Ruby. It [slightly differs](https://github.com/commonmark/CommonMark#differences-from-original-markdown) from original Markdown and does not support all the syntax elements implemented in Kramdown, like [Block Inline Attribute Lists](https://kramdown.gettalong.org/syntax.html#block-ials).
It comes in two flavors: basic CommonMark with [jekyll-commonmark](https://github.com/jekyll/jekyll-commonmark) plugin and [GitHub Flavored Markdown supported by GitHub Pages](https://github.com/github/jekyll-commonmark-ghpages).
### Redcarpet
Redcarpet can be configured by providing an `extensions` sub-setting, whose
value should be an array of strings. Each string should be the name of one of
the `Redcarpet::Markdown` class's extensions; if present in the array, it will
set the corresponding extension to `true`.
Jekyll handles two special Redcarpet extensions:
-`no_fenced_code_blocks` --- By default, Jekyll sets the `fenced_code_blocks`
extension (for delimiting code blocks with triple tildes or triple backticks)
to `true`, probably because GitHub's eager adoption of them is starting to make
them inescapable. Redcarpet's normal `fenced_code_blocks` extension is inert
when used with Jekyll; instead, you can use this inverted version of the
extension for disabling fenced code.
Note that you can also specify a language for highlighting after the first
delimiter:
```ruby
# ...ruby code
```
With both fenced code blocks and highlighter enabled, this will statically
highlight the code; without any syntax highlighter, it will add a
`class="LANGUAGE"` attribute to the `<code>` element, which can be used as a
hint by various JavaScript code highlighting libraries.
- `smart` --- This pseudo-extension turns on SmartyPants, which converts
straight quotes to curly quotes and runs of hyphens to em (`---`) and en (`--`) dashes.
All other extensions retain their usual names from Redcarpet, and no renderer
options aside from `smart` can be specified in Jekyll. [A list of available
extensions can be found in the Redcarpet README file.](https://github.com/vmg/redcarpet/blob/v3.2.2/README.markdown#and-its-like-really-simple-to-use)
Make sure you're looking at the README for the right version of
Redcarpet: Jekyll currently uses v3.2.x. The most commonly used
extensions are:
- `tables`
- `no_intra_emphasis`
- `autolink`
### Custom Markdown Processors
If you're interested in creating a custom markdown processor, you're in luck! Create a new class in the `Jekyll::Converters::Markdown` namespace:
```ruby
class Jekyll::Converters::Markdown::MyCustomProcessor
def initialize(config)
require 'funky_markdown'
@config = config
rescue LoadError
STDERR.puts 'You are missing a library required for Markdown. Please run:'
Set the time zone for site generation. This sets the <code>TZ</code>
environment variable, which Ruby uses to handle time and date
creation and manipulation. Any entry from the
<a href="https://en.wikipedia.org/wiki/Tz_database">IANA Time Zone
Database</a> is valid, e.g. <code>America/New_York</code>. A list of all
available values can be found <a href="https://en.wikipedia.org/wiki/List_of_tz_database_time_zones">
here</a>. When serving on a local machine, the default time zone is set by your operating system. But when served on a remote host/server, the default time zone depends on the server's setting or location.
<p class="description">Specify config files instead of using <code>_config.yml</code> automatically. Settings in later files override settings in earlier files.</p>
[Buddy][buddy-homepage] is a [Docker][docker-homepage]-based CI server that you can set up in 15-20 minutes to build, test, and deploy your Jekyll websites. It supports [GitHub][github-homepage], [Bitbucket][bitbucket-homepage], and [GitLab][gitlab-homepage] repositories, and can be installed on-premises or used in cloud. The following guide will show you how to set up a free environment to build and test your Jekyll project.
[buddy-homepage]: https://buddy.works
[docker-homepage]: https://www.docker.com/
[github-homepage]: https://github.com
[bitbucket-homepage]: https://bitbucket.org/
[gitlab-homepage]: https://gitlab.com
## 1. Getting started
1. Log in at [https://buddy.works][buddy-homepage] with your GitHub/Bitbucket account or email
2. Choose your Git provider and select or push your Jekyll Project
3. Create a new pipeline and set the trigger mode to 'On every push'
4. Add and configure the Jekyll action and save the pipeline
## 2. How it works
Whenever you make a push to the selected branch, the Jekyll action runs `jekyll build` in an isolated [Jekyll Docker image][jekyll-docker-image]. The output is generated to the `/filesystem` directory, and can be further deployed to FTP/SFTP and IaaS services. You can add your own commands, install additional packages, attach services, and run Selenium tests, as well as add other actions down the pipeline, eg. a Slack notification or an SSH script that will restart your server.
If you prefer configuration as code over GUI, you can generate a `buddy.yml` that will create a pipeline with the Jekyll action once you push it to the target branch:
```yaml
- pipeline:"Build and Deploy Jekyll site"
trigger_mode:"ON_EVERY_PUSH"
ref_name:"master"
actions:
- action:"Execute: jekyll build"
type:"BUILD"
docker_image_name:"jekyll/jekyll"
docker_image_tag:"latest"
execute_commands:
- "chown jekyll:jekyll $WORKING_DIR"
- "jekyll build"
```
## 4. Setting up on-premises server
The self-hosted version of Buddy can be installed on any type of server supporting Docker, including [Linux][bw-linux], [Mac][bw-mac], [AWS EC2][bw-aws-ec2], [DigitalOcean][bw-digitalocean], and [Microsoft Azure][bw-azure].
This entire guide is open-source. Go ahead and [edit it][jekyll-docs-ci-buddy] if you want to expand it or have a fix or [ask for help][jekyll-help] if you run into trouble and need assistance. Buddy also has an [online community][buddy-forum] for help.
Building, testing, and deploying your Jekyll-generated website can quickly be done with [CircleCI][0], a continuous integration & delivery tool. CircleCI supports [GitHub][1] and [Bitbucket][2], and you can get started for free using an open-source or private repository.
[0]: https://circleci.com/
[1]: https://github.com/
[2]: https://bitbucket.org/
## 1. Follow Your Project on CircleCI
To start building your project on CircleCI, all you need to do is 'follow' your project from CircleCI's website:
1. Visit the 'Add Projects' page
1. From the GitHub or Bitbucket tab on the left, choose a user or organization.
1. Find your project in the list and click 'Build project' on the right.
1. The first build will start on its own. You can start telling CircleCI how to build your project by creating a [circle.yml][3] file in the root of your repository.
[3]: https://circleci.com/docs/configuration/
## 2. Dependencies
The easiest way to manage dependencies for a Jekyll project (with or without CircleCI) is via a [Gemfile][4]. You'd want to have Jekyll, any Jekyll plugins, [HTML Proofer](#html-proofer), and any other gems that you are using in the `Gemfile`. Don't forget to version `Gemfile.lock` as well. Here's an example `Gemfile`:
[4]: http://bundler.io/gemfile.html
```ruby
source'https://rubygems.org'
ruby'2.4.0'
gem'jekyll'
gem'html-proofer'
```
CircleCI detects when `Gemfile` is present and will automatically run `bundle install` for you in the `dependencies` phase.
## 3. Testing
The most basic test that can be run is seeing if `jekyll build` actually works. This is a blocker, a dependency if you will, for other tests you might run on the generate site. So we'll run Jekyll, via Bundler, in the `dependencies` phase.
```yaml
dependencies:
post:
- bundle exec jekyll build
```
### HTML Proofer
With your site built, it's useful to run tests to check for valid HTML, broken links, etc. There's a few tools out there but [HTML Proofer][5] is popular amongst Jekyll users. We'll run it in the `test` phase with a few preferred flags. Check out the `html-proofer` [README][6] for all available flags, or run `htmlproofer --help` locally.
for CircleCI v2, a Docker-based system which new projects will follow, set the `S3_BUCKET_NAME` environment variable (an example of the required config file is shown below).
```yaml
defaults:&defaults
working_directory:~/repo
version:2
jobs:
build:
<<:*defaults
docker:
- image:circleci/ruby:2.5
environment:
BUNDLE_PATH:~/repo/vendor/bundle
steps:
- checkout
- restore_cache:
keys:
- rubygems-v1-{% raw %}{{ checksum "Gemfile.lock" }}{% endraw %}
- rubygems-v1-fallback
- run:
name:Bundle Install
command:bundle check || bundle install
- save_cache:
key:rubygems-v1-{% raw %}{{ checksum "Gemfile.lock" }}{% endraw %}
This entire guide is open-source. Go ahead and [edit it][7] if you have a fix or [ask for help][8] if you run into trouble and need some help. CircleCI also has an [online community][9] for help.
@@ -80,7 +76,7 @@ with Ruby and requires RubyGems to install, we use the Ruby language build
environment. Below is a sample `.travis.yml` file, followed by
an explanation of each line.
**Note:** You will need a Gemfile as well, [Travis will automatically install](https://docs.travis-ci.com/user/languages/ruby/#Dependency-Management) the dependencies based on the referenced gems:
**Note:** You will need a Gemfile as well, [Travis will automatically install](https://docs.travis-ci.com/user/languages/ruby/#Dependency-Management) the dependencies based on the referenced gems. Here is an example `Gemfile` with two referenced gems, "jekyll" and "html-proofer":
```ruby
source "https://rubygems.org"
@@ -94,7 +90,7 @@ Your `.travis.yml` file should look like this:
```yaml
language: ruby
rvm:
- 2.2.5
- 2.6.3
before_script:
- chmod +x ./script/cibuild # or do this locally and commit
@@ -113,7 +109,18 @@ env:
global:
- NOKOGIRI_USE_SYSTEM_LIBRARIES=true # speeds up installation of html-proofer
addons:
apt:
packages:
- libcurl4-openssl-dev
sudo: false # route your build to the container-based infrastructure for a faster build
cache: bundler # caching bundler gem packages will speed up build
# Optional: disable email notifications about the outcome of your builds
notifications:
email: false
```
Ok, now for an explanation of each line:
@@ -127,12 +134,13 @@ access to Bundler, RubyGems, and a Ruby runtime.
```yaml
rvm:
- 2.2.5
- 2.6.3
```
RVM is a popular Ruby Version Manager (like rbenv, chruby, etc). This
directive tells Travis the Ruby version to use when running your test
script.
script. Use a [version which is pre-installed on the Travis build docker][5]
image to speed up the build.
```yaml
before_script:
@@ -214,6 +222,23 @@ does need `sudo` access, modify the line to `sudo: required`.
sudo: false
```
To speed up the build, you should cache the gem packages created by `bundler`.
Travis has a pre-defined [cache strategy for this tool][6] which should have
all the default configs to do exactly that.
```yaml
cache: bundler
```
Optionally, if you are not interested in the build email notifications you
can disable them with this configuration. Travis supports a wide array of
notification services, you may find [another one more useful (e.g. slack)][7].
```yaml
notifications:
email: false
```
### Troubleshooting
**Travis error:** *"You are trying to install in deployment mode after changing
@@ -229,5 +254,8 @@ an entry in the `.gitignore` file to avoid it from being checked in again.
This entire guide is open-source. Go ahead and [edit it][3] if you have a
fix or [ask for help][4] if you run into trouble and need some help.
note: This file is autogenerated. Edit /.github/CONTRIBUTING.markdown instead.
---
@@ -9,10 +8,7 @@ Hi there! Interested in contributing to Jekyll? We'd love your help. Jekyll is a
## 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/).
See the [support guidelines](https://jekyllrb.com/docs/support/)
## Ways to contribute
@@ -20,9 +16,9 @@ Whether you're a developer, a designer, or just a Jekyll devotee, there are lots
* [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.
* 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
@@ -33,7 +29,7 @@ Whether you're a developer, a designer, or just a Jekyll devotee, there are lots
* The more information, the better. Make judicious use of the pull request body. Describe what changes were made, why you made them, and what impact they will have for users.
* Pull request are easy and fun. If this is your first pull request, it may help to [understand GitHub Flow](https://guides.github.com/introduction/flow/).
* If 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.
@@ -57,7 +53,7 @@ That's it! You'll be automatically subscribed to receive updates as others revie
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)
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.
@@ -67,17 +63,37 @@ We want the Jekyll documentation to be the best it can be. We've open-sourced ou
### How to submit changes
You can find the documentation for jekyllrb.com in the [site](https://github.com/jekyll/jekyll/tree/master/site) directory. See the section above, [submitting a pull request](#submitting-a-pull-request) for information on how to propose a change.
You can find the documentation for jekyllrb.com in the [docs](https://github.com/jekyll/jekyll/tree/master/docs) directory. See the section above, [submitting a pull request](#submitting-a-pull-request) for information on how to propose a change.
One gotcha, all pull requests should be directed at the `master` branch (the default branch).
### Updating FontAwesome iconset for jekyllrb.com
We use a custom version of FontAwesome which contains just the icons we use.
If you ever need to update our documentation with an icon that is not already available in our custom iconset, you'll have to regenerate the iconset using Icomoon's Generator:
1. Go to <https://icomoon.io/app/>.
2. Click `Import Icons` on the top-horizontal-bar and upload the existing `<jekyll>/docs/icomoon-selection.json`.
3. Click `Add Icons from Library..` further down on the page, and add 'Font Awesome'.
4. Select the required icon(s) from the Library (make sure its the 'FontAwesome' library instead of 'IcoMoon-Free' library).
5. Click `Generate Font` on the bottom-horizontal-bar.
6. Inspect the included icons and proceed by clicking `Download`.
7. Extract the font files and adapt the CSS to the paths we use in Jekyll:
- Copy the entire `fonts` directory over and overwrite existing ones at `<jekyll>/docs/`.
- Copy the contents of `selection.json` and overwrite existing content inside `<jekyll>/docs/icomoon-selection.json`.
- Copy the entire `@font-face {}` declaration and only the **new-icon(s)' css declarations** further below, to update the
- Fix paths in the `@font-face {}` declaration by adding `../` before `fonts/FontAwesome.*` like so:
`('../fonts/Fontawesome.woff?9h6hxj')`.
### Adding plugins
If you want to add your plugin to the [list of plugins](https://jekyllrb.com/docs/plugins/#available-plugins), please submit a pull request modifying the [plugins page source file](https://github.com/jekyll/jekyll/blob/master/site/_docs/plugins.md) by adding a link to your plugin under the proper subheading depending upon its type.
If you want to add your plugin to the [list of plugins](https://jekyllrb.com/docs/plugins/#available-plugins), please submit a pull request modifying the [plugins page source file](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.
Interested 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
@@ -85,7 +101,7 @@ Any time you propose a code change, you should also include updates to the docum
#### Documentation
If your contribution changes any Jekyll behavior, make sure to update the documentation. Documentation lives in the `site/_docs` folder (spoiler alert: it's a Jekyll site!). If the docs are missing information, please feel free to add it in. Great docs make a great project. Include changes to the documentation within your pull request, and once merged, `jekyllrb.com` will be updated.
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
@@ -99,25 +115,39 @@ If your contribution changes any Jekyll behavior, make sure to update the docume
* Don't bump the Gem version in your pull request (if you don't know what that means, you probably didn't).
* You can use the command `script/console` to start a REPL to explore the result of
Jekyll's methods. It also provides you with helpful methods to quickly create a
site or configuration. [Feel free to check it out!](https://github.com/jekyll/jekyll/blob/master/script/console)
* Previously, we've used the WIP Probot app to help contributors determine whether their pull request is ready for review. Please use a [draft pull request](https://help.github.com/en/articles/about-pull-requests#draft-pull-requests) instead. When you're ready, [mark the pull request as ready for review](https://help.github.com/en/articles/changing-the-stage-of-a-pull-request)
## 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:
Jekyll supports loading data from [YAML](http://yaml.org/), [JSON](http://www.json.org/),
and [CSV](https://en.wikipedia.org/wiki/Comma-separated_values) files located in the `_data` directory.
Note that CSV files *must* contain a header row.
Jekyll supports loading data from [YAML](http://yaml.org/), [JSON](http://www.json.org/), [CSV](https://en.wikipedia.org/wiki/Comma-separated_values), and [TSV](https://en.wikipedia.org/wiki/Tab-separated_values) files located in the `_data` directory.
Note that CSV and TSV files *must* contain a header row.
This powerful feature allows you to avoid repetition in your templates and to
set site specific options without changing `_config.yml`.
@@ -19,9 +17,8 @@ Plugins/themes can also leverage Data Files to set configuration variables.
## The Data Folder
As explained on the [directory structure](../structure/) page, the `_data`
folder is where you can store additional data for Jekyll to use when generating
your site. These files must be YAML, JSON, or CSV files (using either
The `_data` folder is where you can store additional data for Jekyll to use when
generating your site. These files must be YAML, JSON, or CSV files (using either
the `.yml`, `.yaml`, `.json` or `.csv` extension), and they will be
accessible via `site.data`.
@@ -57,8 +54,8 @@ determines the variable name).
You can now render the list of members in a template:
```html
{% raw %}
```liquid
<ul>
{% for member in site.data.members %}
<li>
@@ -68,10 +65,10 @@ You can now render the list of members in a template:
</li>
{% endfor %}
</ul>
{% endraw %}
```
{% endraw %}
## Example: Organizations
## Subfolders
Data files can also be placed in sub-folders of the `_data` folder. Each folder
level will be added to a variable's namespace. The example below shows how
@@ -104,8 +101,8 @@ members:
The organizations can then be accessed via `site.data.orgs`, followed by the
file name:
```html
{% raw %}
```liquid
<ul>
{% for org_hash in site.data.orgs %}
{% assign org = org_hash[1] %}
@@ -117,24 +114,25 @@ file name:
</li>
{% endfor %}
</ul>
{% endraw %}
```
{% endraw %}
## Example: Accessing a specific author
Pages and posts can also access a specific data item. The example below shows how to access a specific item:
`_data/people.yml`:
```yaml
dave:
name: David Smith
twitter: DavidSilvaSmith
```
The author can then be specified as a page variable in a post's frontmatter:
The author can then be specified as a page variable in a post's frontmatter:
For information on how to build robust navigation for your site (especially if you have a documentation website or another type of Jekyll site with a lot of pages to organize), see [Navigation](/tutorials/navigation).
Sites built using Jekyll can be deployed in a large number of ways due to the static nature of the generated output. Here's some of the most common ways:
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:
Jekyll generates your static site to the `_site` directory by default. You can
transfer the contents of this directory to almost any hosting provider to get
your site live. Here are some manual ways of achieving this:
## rsync
Rsync is similar to scp except it can be faster as it will only send changed
parts of files as opposed to the entire file. You can learn more about using
rsync in the [Digital Ocean tutorial](https://www.digitalocean.com/community/tutorials/how-to-use-rsync-to-sync-local-and-remote-directories-on-a-vps).
## 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.
## FTP
Most traditional web hosting provider let you upload files to their servers over FTP. To upload a Jekyll site to a web host using FTP, 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.
## scp
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. Remember to make sure the contents of the generated `_site` folder get placed in the appropriate web root directory for your web server.
## Rack-Jekyll
[Rack-Jekyll](https://github.com/adaoraul/rack-jekyll/) allows you 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).
[Aerobatic](https://www.aerobatic.com) has custom domains, global CDN distribution, basic auth, CORS proxying, and a growing list of plugins all included.
Automating the deployment of a Jekyll site is simple. See their [Jekyll docs](https://www.aerobatic.com/docs/static-site-generators/#jekyll) for more details. Your built `_site` folder is deployed to their highly-available, globally distributed hosting service.
## AWS Amplify
The [AWS Amplify Console](https://console.amplify.aws) provides continuous deployment and hosting for modern web apps (single page apps and static site generators). Continuous deployment allows developers to deploy updates to their web app on every code commit to their Git repository. Hosting includes features such as globally available CDNs, 1-click custom domain setup + HTTPS, feature branch deployments, redirects, trailing slashes, and password protection.
Read this [step-by-step guide](https://medium.com/@FizzyInTheHall/build-and-publish-a-jekyll-powered-blog-easily-with-aws-amplify-529852042ab6) to deploy and host your Jekyll site on AWS Amplify.
## CloudCannon
[CloudCannon](https://cloudcannon.com) has everything you need to build, host
and update Jekyll websites. Take advantage of our global CDN, automated SSL,
continuous deployment and [more](https://cloudcannon.com/features/).
## GitHub Pages
Sites on GitHub Pages are powered by Jekyll behind the scenes, so if you’re looking for a zero-hassle, zero-cost solution, GitHub Pages are a great way to [host your Jekyll-powered website for free](/docs/github-pages/).
## Kickster
Use [Kickster](http://kickster.nielsenramon.com/) for 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.
Install the Kickster 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).
## Netlify
Netlify provides Global CDN, Continuous Deployment, one click HTTPS and [much more](https://www.netlify.com/features/), providing developers the most robust toolset available for modern web projects, without added complexity. Netlify supports custom plugins for Jekyll and has a free plan for open source projects.
Read this [Jekyll step-by-step guide](https://www.netlify.com/blog/2015/10/28/a-step-by-step-guide-jekyll-3.0-on-netlify/) to setup your Jekyll site on Netlify.
## 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).
The `include` tag allows you to include the content from another file stored in the `_includes` folder:
{% raw %}
```liquid
{% include footer.html %}
```
{% endraw %}
Jekyll will look for the referenced file (in this case, `footer.html`) in the `_includes` directory at the root of your source directory and insert its contents.
### Including files relative to another file
You can choose to include file fragments relative to the current file by using the `include_relative` tag:
{% raw %}
```liquid
{% include_relative somedir/footer.html %}
```
{% endraw %}
You won't need to place your included content within the `_includes` directory. Instead,
the inclusion is specifically relative to the file where the tag is being used. For example,
if `_posts/2014-09-03-my-file.markdown` uses the `include_relative` tag, the included file
must be within the `_posts` directory or one of its subdirectories.
Note that you cannot use the `../` syntax to specify an include location that refers to a higher-level directory.
All the other capabilities of the `include` tag are available to the `include_relative` tag,
such as variables.
### Using variables names for the include file
The name of the file you want to embed can be specified as a variable instead of an actual file name. For example, suppose you defined a variable in your page's front matter like this:
```yaml
---
title:My page
my_variable:footer_company_a.html
---
```
You could then reference that variable in your include:
{% raw %}
```liquid
{% if page.my_variable %}
{% include {{ page.my_variable }} %}
{% endif %}
```
{% endraw %}
In this example, the include would insert the file `footer_company_a.html` from the `_includes/footer_company_a.html` directory.
### Passing parameters to includes
You can also pass parameters to an include. For example, suppose you have a file called `note.html` in your `_includes` folder that contains this formatting:
The `{% raw %}{{ include.content }}{% endraw %}` is a parameter that gets populated when you call the include and specify a value for that parameter, like this:
{% raw %}
```liquid
{% include note.html content="This is my sample note." %}
```
{% endraw %}
The value of `content` (which is `This is my sample note`) will be inserted into the {% raw %}`{{ include.content }}`{% endraw %} parameter.
Passing parameters to includes is especially helpful when you want to hide away complex formatting from your Markdown content.
For example, suppose you have a special image syntax with complex formatting, and you don't want your authors to remember the complex formatting. As a result, you decide to simplify the formatting by using an include with parameters. Here's an example of the special image syntax you might want to populate with an include:
```html
<figure>
<ahref="http://jekyllrb.com">
<imgsrc="logo.png"style="max-width: 200px;"
alt="Jekyll logo"/>
</a>
<figcaption>This is the Jekyll logo</figcaption>
</figure>
```
You could templatize this content in your include and make each value available as a parameter, like this:
The result is the original HTML code shown earlier.
To safeguard situations where users don't supply a value for the parameter, you can use [Liquid's default filter](https://shopify.github.io/liquid/filters/default/).
Overall, you can create includes that act as templates for a variety of uses — inserting audio or video clips, alerts, special formatting, and more. Note that you should avoid using too many includes, as this will slow down the build time of your site. For example, don't use includes every time you insert an image. (The above technique shows a use case for special images.)
### Passing parameter variables to includes
Suppose the parameter you want to pass to the include is a variable rather than a string. For example, you might be using {% raw %}`{{ site.product_name }}`{% endraw %} to refer to every instance of your product rather than the actual hard-coded name. (In this case, your `_config.yml` file would have a key called `product_name` with a value of your product's name.)
The string you pass to your include parameter can't contain curly braces. For example, you can't pass a parameter that contains this: {% raw %}`"The latest version of {{ site.product_name }} is now available."`{% endraw %}
If you want to include this variable in your parameter that you pass to an include, you need to store the entire parameter as a variable before passing it to the include. You can use `capture` tags to create the variable:
{% raw %}
```liquid
{% capture download_note %}
The latest version of {{ site.product_name }} is now available.
{% endcapture %}
```
{% endraw %}
Then pass this captured variable into the parameter for the include. Omit the quotation marks around the parameter content because it's no longer a string (it's a variable):
description: Official guide to install Jekyll on macOS, GNU/Linux or Windows.
permalink: /docs/installation/
---
Jekyll is a [Ruby Gem](/docs/ruby-101/#gems) that can be installed on most systems.
## Requirements
* [Ruby](https://www.ruby-lang.org/en/downloads/) version **{{ site.data.ruby.min_version }}** or above, including all development headers (ruby version can be checked by running `ruby -v`)
* [RubyGems](https://rubygems.org/pages/download) (which you can check by running `gem -v`)
* [GCC](https://gcc.gnu.org/install/) and [Make](https://www.gnu.org/software/make/) (in case your system doesn't have them installed, which you can check by running `gcc -v`,`g++ -v` and `make -v` in your system's command line interface)
## Guides
For detailed install instructions have a look at the guide for your operating system.
* [macOS](/docs/installation/macos/)
* [Ubuntu Linux](/docs/installation/ubuntu/)
* [Other Linux distros](/docs/installation/other-linux)
That's it! Head over [rbenv command references](https://github.com/rbenv/rbenv#command-reference) to learn how to use different versions of Ruby in your projects.
## Install Jekyll
Now all that is left is installing [Bundler](/docs/ruby-101/#bundler) and Jekyll.
### Local Install
```sh
gem install --user-install bundler jekyll
```
and then get your Ruby version using
```sh
ruby -v
{{ site.data.ruby.current_version_output }}
```
Then append your path file with the following, replacing the `X.X` with the first two digits of your Ruby version.
```
export PATH=$HOME/.gem/ruby/X.X.0/bin:$PATH
```
To check your that you gem paths point to your home directory run:
```sh
gem env
```
And check that `GEM PATHS:` points to a path in your home directory
{: .note }
Every time you update Ruby to a version with a different first two digits, you will need to update your path to match.
### Global Install
{: .note .warning}
We strongly recommend against installing Ruby gems globally to avoid file permissions problems and using `sudo`.
#### On Mojave (10.14)
Because of SIP Protections in Mojave, you must run:
```sh
sudo gem install bundler
sudo gem install -n /usr/local/bin/ jekyll
```
#### Before Mojave (<10.14)
You only have to run:
```sh
sudo gem install bundler jekyll
```
## Problems?
Check out the [troubleshooting](/docs/troubleshooting/) page or [ask for help on our forum](https://talk.jekyllrb.com).
{% if example.output %}<p><code class="output">{{ example.output }}</code></p>{% endif %}
{% endfor -%}
</td>
</tr>
{% endfor %}
</tbody>
</table>
</div>
### Options for the `slugify` filter
The `slugify` filter accepts an option, each specifying what to filter.
The default is `default`. They are as follows (with what they filter):
-`none`: no characters
-`raw`: spaces
-`default`: spaces and non-alphanumeric characters
-`pretty`: spaces and non-alphanumeric characters except for `._~!$&'()+,;=@`
-`ascii`: spaces, non-alphanumeric, and non-ASCII characters
-`latin`: like `default`, except Latin characters are first transliterated (e.g. `àèïòü` to `aeiou`) {%- include docs_version_badge.html version="3.7.0" -%}.
### Detecting `nil` values with `where` filter {%- include docs_version_badge.html version="4.0" -%}
You can use the `where` filter to detect documents and pages with properties that are `nil` or `""`. For example,
```liquid
// Using `nil` to select posts that either do not have `my_prop` defined or `my_prop` has been set to `nil` explicitly.
### Binary operators in `where_exp` filter {%- include docs_version_badge.html version="4.0" -%}
You can use Liquid binary operators `or` and `and` in the expression passed to the `where_exp` filter to employ multiple
conditionals in the operation.
For example, to get a list of documents on English horror flicks, one could use the following snippet:
```liquid
{% raw %}{{ site.movies | where_exp: "item", "item.genre == 'horror' and item.language == 'English'" }}{% endraw %}
```
Or to get a list of comic-book based movies, one may use the following:
```liquid
{% raw %}{{ site.movies | where_exp: "item", "item.sub_genre == 'MCU' or item.sub_genre == 'DCEU'" }}{% endraw %}
```
### Standard Liquid Filters
For your convenience, here is the list of all [Liquid filters]({{ page.shopify_filter_url }}) with links to examples in the official Liquid documentation.
<h5>Jekyll processes all Liquid filters in code blocks</h5>
<p>If you are using a language that contains curly braces, you
will likely need to place <code>{% raw %}</code> and
<code>{% endraw %}</code> tags around your code.
Since {% include docs_version_badge.html version="4.0" %} you can add <code>render_with_liquid: false</code> in your front matter to disable Liquid entirely for a particular document.</p>
</div>
### Line numbers
There is a second argument to `highlight` called `linenos` that is optional.
Including the `linenos` argument will force the highlighted code to include line
numbers. For instance, the following code block would include line numbers next
to each line:
{% raw %}
```liquid
{% highlight ruby linenos %}
def foo
puts 'foo'
end
{% endhighlight %}
```
{% endraw %}
### Stylesheets for syntax highlighting
In order for the highlighting to show up, you’ll need to include a highlighting
stylesheet. For Pygments or Rouge you can use a stylesheet for Pygments, you
or from [its repository](https://github.com/jwarby/jekyll-pygments-themes).
Copy the CSS file (`native.css` for example) into your css directory and import
the syntax highlighter styles into your `main.css`:
```css
@import"native.css";
```
## Links
{: .note }
Since Jekyll {% include docs_version_badge.html version="v4.0"%} you don't need to prepend `link` and `post_url` tags with `site.baseurl`
### Linking to pages {#link}
To link to a post, a page, collection item, or file, the `link` tag will generate the correct permalink URL for the path you specify. For example, if you use the `link` tag to link to `mypage.html`, even if you change your permalink style to include the file extension or omit it, the URL formed by the `link` tag will always be valid.
You must include the file's original extension when using the `link` tag. Here are some examples:
{% raw %}
```liquid
{% link _collection/name-of-document.md %}
{% link _posts/2016-07-26-name-of-post.md %}
{% link news/index.html %}
{% link /assets/files/doc.pdf %}
```
{% endraw %}
You can also use the `link` tag to create a link in Markdown as follows:
{% raw %}
```liquid
[Link to a document]({% link _collection/name-of-document.md %})
[Link to a post]({% link _posts/2016-07-26-name-of-post.md %})
[Link to a page]({% link news/index.html %})
[Link to a file]({% link /assets/files/doc.pdf %})
```
{% endraw %}
The path to the post, page, or collection is defined as the path relative to the root directory (where your config file is) to the file, not the path from your existing page to the other page.
For example, suppose you're creating a link in `page_a.md` (stored in `pages/folder1/folder2`) to `page_b.md` (stored in `pages/folder1`). Your path in the link would not be `../page_b.html`. Instead, it would be `/pages/folder1/page_b.md`.
If you're unsure of the path, add `{% raw %}{{ page.path }}{% endraw %}` to the page and it will display the path.
One major benefit of using the `link` or `post_url` tag is link validation. If the link doesn't exist, Jekyll won't build your site. This is a good thing, as it will alert you to a broken link so you can fix it (rather than allowing you to build and deploy a site with broken links).
Note you cannot add filters to `link` tags. For example, you cannot append a string using Liquid filters, such as `{% raw %}{% link mypage.html | append: "#section1" %} {% endraw %}`. To link to sections on a page, you will need to use regular HTML or Markdown linking techniques.
### Linking to posts
If you want to include a link to a post on your site, the `post_url` tag will generate the correct permalink URL for the post you specify.
{% raw %}
```liquid
{% 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:
{% raw %}
```liquid
{% 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:
{% raw %}
```liquid
[Name of Link]({% post_url 2010-07-21-name-of-post %})
**This guide is for affinity team captains.** These special people are **team maintainers** of one of our [affinity teams][] and help triage and evaluate the issues and contributions of others. You may find what is written here interesting, but it’s definitely not for everyone.
{: .note .info }
## Affinity teams & their captains
@@ -14,11 +17,11 @@ Each affinity team has a few captains who manage the issues and pull requests fo
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.
Alternatively, you can email or otherwise reach out to [@oe](https://github.com/oe) 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.
No sweat at all! Email [@oe](https://github.com/oe) and ask to be removed. Alternatively, you should be able to go to your team's page on GitHub.com (go to https://github.com/jekyll, click "Teams", click the link to your team) and change your status to either "member" or leave the team.
We realize that being a captain is no easy feat so we want to make it a great experience. As always, communicate as much as you can with us about what is working, and what isn't. Thanks for dedicating some time to Jekyll! :sparkles:
**This guide is for maintainers.** These special people have **write access** to one or more of Jekyll's repositories and help merge the contributions of others. You may find what is written here interesting, but it’s definitely not for everyone.
{: .note .info }
# 1. Use Jekyll
Maintainers of Jekyll should be using it regularly. This is partly because you won't be a good maintainer unless you can put yourself in the shoes of our users but also because you may 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.
Maintainers of Jekyll should be using it regularly. This is partly because you won't be a good maintainer unless you can put yourself in the shoes of our users, but also because you may at some point decide to stop using Jekyll, and at that point you should also decide to stop being a maintainer and find other things to work on.
# 2. No Guilt About Leaving
All maintainers can stop working on Jekyll at any time without any guilt or explanation (like 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.
All maintainers can stop working on Jekyll at any time without any guilt or explanation (like at a job). We may still ask for your help with questions after you leave but you are under no obligation to answer them. If you create a big mess and then leave you still have no obligations but we may think less of you (or, realistically, probably just revert the problematic work). Also, you should probably take a break from Jekyll at least a few times a year.
This also means contributors should be consumers. If a maintainer finds they are not using a project in the real-world, they should reconsider their involvement with the project.
@@ -24,4 +27,4 @@ Jekyll gets a lot of feature requests, non-reproducible bug reports, usage quest
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/share/doc/homebrew/Maintainers-Avoiding-Burnout.md) for providing a perfect base for this document.
Thanks to [Homebrew's "Avoiding Burnout" document](https://github.com/Homebrew/brew/blob/master/docs/Maintainers-Avoiding-Burnout.md) for providing a perfect base for this document.
**This guide is for contributors.** These special people have contributed to one or more of Jekyll's repositories, but do not yet have write access to any. You may find what is written here interesting, but it’s definitely not for everyone.
{: .note .info }
So you want to become a maintainer of a Jekyll project? We'd love to have you! Here are some things we like to see from community members before we promote them to maintainers.
@@ -10,7 +13,7 @@ You want to maintain Jekyll? Use it often. Do weird things with it. Do normal th
## 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.md). Every maintainer loves an issue that is resolved before they get to it. :smiley:
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
@@ -22,7 +25,7 @@ As a maintainer, you will be reviewing pull requests which update code. You shou
## 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.md).
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!
@@ -32,4 +35,4 @@ We would love to expand the team and look forward to many more community members
# 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://help.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.
In addition to maintainers of our core and plugin code, the Jekyll team is comprised of moderators for our forums. These helpful community members take a look at the topics posted to [https://talk.jekyllrb.com](https://talk.jekyllrb.com) and ensure they are properly categorized and are acceptable under our Code of Conduct. If you would like to be a moderator, email one of the maintainers with links to where you have answered questions and a request to be added as a moderator. More help is always welcome.
**This guide is for Jekyll contributors and maintainers.** These special people contribute to one or more of Jekyll's repositories or help merge the contributions of others. You may find what is written here interesting, but it’s definitely not for everyone.
{: .note .info }
Hello! This is where we document various processes for maintaining Jekyll. Being a maintainer for any Jekyll project is a big responsibility, so we put together some helpful documentation for various tasks you might do as a maintainer.
- [Affinity teams & their captains](affinity-team-captain/)
- [Triaging an issue](triaging-an-issue/)
- [Reviewing a pull request](reviewing-a-pull-request/)
- [Merging a pull request](merging-a-pull-request/)
- [Avoiding burnout](avoiding-burnout/)
- [Special Labels](special-labels/)
- [Releasing a new version](releasing-a-new-version/)
Interested in becoming a maintainer? Here is some documentation for **contributors**:
**This guide is for maintainers.** These special people have **write access** to one or more of Jekyll's repositories and help merge the contributions of others. You may find what is written here interesting, but it’s definitely not for everyone.
{: .note .info }
## Code Review
All pull requests should be subject to code review. Code review is a [foundational value](https://blog.fullstory.com/what-we-learned-from-google-code-reviews-arent-just-for-catching-bugs-b125a13aa292) of good engineering teams. Besides providing validation of correctness, it promotes a sense of community and gives other maintainers understanding of all parts of the code base. In short, code review is crucial to a healthy open source project.
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/) 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.md) before merging.** Notably, the change must have tests if for code, and at least two maintainers must give it an OK.
**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
2. We like to provide a consistent paper trail in the `History.markdown` file for each release
To merge a pull request, leave a comment thanking the contributor, then add the special merge request:
@@ -27,15 +30,17 @@ 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
3. `+dev`– the category to which the changes belong.
The categories match the H3's in the history/changelog file, and they are:
The categories match the headings in the `History.markdown` file, and they are:
1. Major Enhancements (`+major`) – major updates or breaking changes to the code which necessitate a major version bump (v3 ~> v4)
2. Minor Enhancements (`+minor`) – minor updates (feature, enhancement) which necessitate a minor version bump (v3.1 ~> v3.2)
2. Minor Enhancements (`+minor`) – minor updates (with the labels `feature` or `enhancement`) which necessitate a minor version bump (v3.1 ~> v3.2)
3. Bug Fixes (`+bug`) – corrections to code which do not change or add functionality, which necessitate a patch version bump (v3.1.0 ~> v3.1.1)
4. Site Enhancements (`+site`) – changes to the source of https://jekyllrb.com, found in `site/`
5. Development Fixes (`+dev`) – changes which do not affect user-facing functionality or documentation, such as test fixes or bumping internal dependencies
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:
**This guide is for maintainers.** These special people have **write access** to one or more of Jekyll's repositories and help merge the contributions of others. You may find what is written here interesting, but it’s definitely not for everyone.
{: .note .info }
The most important thing to understand before making a release is that there's no need to feel nervous. Most things are revertable, and even if you do publish an incomplete gem version, we can always skip that one. Don't hestitate to contact the other maintainers if you feel unsure or don't know what to do next.
### Bump the version
The only important place you need to manually bump the version is in `lib/jekyll/version.rb`. Adjust that, and everything else should work fine.
### Update the history document
Replace the first header of the history document with a version milestone. This looks like the following:
```diff
-## HEAD
+## 3.7.1 / 2018-01-25
```
Adjust the version number and the date. The `## HEAD` heading will be regenerated next time a pull request is merged.
Once you've done this, update the website by running the following command:
```sh
bundle exec rake site:generate
```
This updates the website's changelog, and pushes the versions in various other places.
It's recommended that you go over the `History.markdown` file manually one more time, in case there are any spelling errors or such. Feel free to fix those manually, and after you're done generating the website changelog, commit your changes.
## Write a release post
In case this isn't done already, you can generate a new release post using the included `rake` command:
```sh
bundle exec rake site:releases:new[3.8.0]
```
where `3.8.0` should be replaced with the new version. Then, write the post. Be sure to thank all of the collaborators and maintainers who have contributed since the last release. You can generate a log of their names using the following command:
```sh
git shortlog -sn master...v3.7.2
```
where, again `v3.7.2` is the last release. Be sure to open a pull request for your release post.
### Push the version
Before you do this step, make sure the following things are done:
- You have permission to push a new gem version to RubyGems
- You're logged into RubyGems on your command line
- A release post has been prepared, and is ideally already live
- All of the prior steps are done, committed, and pushed to `master`
Really the only thing left to do is to run this command:
```sh
bundle exec rake release
```
This will automatically build the new gem, make a release commit and tag and then push the new gem to RubyGems. Don't worry about creating a GitHub release, @jekyllbot should take care of that.
And then, you're done! :tada: Feel free to celebrate!
If you have access to the [@jekyllrb](https://twitter.com/jekyllrb) Twitter account, you should tweet the release post from there. If not, just ask another maintainer to do it or to give you access.
### Build the docs
We package our documentation as a :gem: Gem for offline use.
**This guide is for maintainers.** These special people have **write access** to one or more of Jekyll's repositories and help merge the contributions of others. You may find what is written here interesting, but it’s definitely not for everyone.
{: .note .info }
## Respond Kindly
Above all else, please review a pull request kindly. Our community can only be strong if we make it a welcoming and inclusive environment. To further promote this, the Jekyll community is governed by a [Code of Conduct](../CONDUCT.markdown) by which all community members must abide.
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.
@@ -41,4 +44,3 @@ A pull request may be merged once two maintainers have reviewed the pull request
## Think Security
We owe it to our users to ensure that using a theme from the community or building someone else's site doesn't come with built-in security vulnerabilities. Things like where files may be read from and written to are important to keep secure. Jekyll is also the basis for hosted services such as [GitHub Pages](https://pages.github.com), which cannot upgrade when security issues are introduced.
**This guide is for maintainers.** These special people have **write access** to one or more of Jekyll's repositories and help merge the contributions of others. You may find what is written here interesting, but it’s definitely not for everyone.
{: .note .info }
We use a series of "special labels" on GitHub.com to automate handling of some parts of the pull request and issue process. @jekyllbot may automatically apply or remove certain labels based on actions taken by users or maintainers. Below are the labels and how they work:
@@ -14,4 +17,8 @@ These labels are used to indicate that the Git state of a pull request must chan
## `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.md#staleness-and-automatic-closure).
This label is automatically added and removed by @jekyllbot based on activity on an issue or pull request. The rules for this label are laid out in [Triaging an Issue: Staleness and automatic closure](../triaging-an-issue/#staleness-and-automatic-closure).
## `pinned`
This label is for @jekyllbot to ignore the age of the issue, which means that the `stale` label won't be automatically added, and the issue won't be closed after a while. This needs to be set manually, and should be set with care. (The `has-pull-request` label does the same thing, but shouldn't be used to _only_ keep an issue open)
**This guide is for maintainers.** These special people have **write access** to one or more of Jekyll's repositories and help merge the contributions of others. You may find what is written here interesting, but it’s definitely not for everyone.
{: .note .info }
Before evaluating an issue, it is important to identify if it is a feature
request or a bug. For the Jekyll project the following definitions are used
@@ -48,4 +51,4 @@ Is what they wanted to get something we want to happen? Sometimes a bug report i
### 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.
@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 behavior can be suppressed by setting the [`pinned` label](/docs/maintaining/special-labels/#pinned).
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.