This is a 🔦 documentation change.
## Summary
The install documentation for WSL offers to install Ruby through
BrightBox. However, BrightBox does not support Ubuntu Jammy (which is
the default for latest WSL builds). Instead, this commit just redirects
the WSL user to the Ubuntu installation procedure to avoid duplicate
documentation.
This is a 🐛 bug fix.
## Summary
The `release-please.yml` workflow doesn't make sense in forked
repositories. Let's restrict its execution to jekyll/jekyll only.
I did not expect a "workflow failed" notification soon after catching up
with the upstream in my forked repo:
<img width="1542" height="961" alt="image"
src="https://github.com/user-attachments/assets/5049f2ca-1b1b-42b8-b6ea-4c91ce66a6c3"
/>
This is a 🙋 feature or enhancement.
This is a 🔨 code refactoring.
## Summary
Improve and streamline our release processes with some extra automation
and a bit more rigor around PRs/commits.
## Context
With Jekyll 4.4 released, and under the assumption that the next release
will indeed be 5.0, I think it makes a lot of sense to take some time
and evaluate our development practices and streamline the process of
shipping. We generally go a long time (four months between 4.3.4 and
4.4.0, two years between 4.3.0 and 4.4.0) between releases and this is
my attempt at trying to improve that. While this PR is currently
incomplete, if there's interest in going this direction, I'll make time
over the next few days to clean it up and get it ready to actually ship.
In order to do this, I'm relying on the
[`release-please`](https://github.com/googleapis/release-please-action)
action from Google to do the majority of the heavy lifting. Please read
the release-please README in order to learn how release-please works and
what it does. In order to make it easier to adopt release-please, I've
made two additional changes. ~~The first is to rename `History.markdown`
to `CHANGELOG.md` since that's what `release-please` works with out of
the box.~~ The other is to add two new github actions workflows to run
release-please and to enforce conventional commit conventions on PR
titles. Because we squash merge, the PR title becomes the commit message
and `release-please` uses the commit messages to know when to bump the
version number.
One potential caveat with this is that it may become harder to maintain
stable branches. My point of view on this is that we've done a
relatively poor job of maintaining them regardless and I think it's more
important to release often, even if we end up bumping major or minor
version numbers more frequently than before. My stance on this is that
version bumps have no inherent goodness or badness. They are a
communication mechanism. We should let go of having to wait a certain
amount of time to do major version bumps or avoid work because it would
cause a major version bump, for example.
### Process changes
The use of release-please means that we can stop using jekyllbot to do
the merges and update History.markdown for us, as release-please will
take care of that when we cut the release. We will also no longer need
labels on PRs as the use of conventional commits will explain exactly
what is changing.
The process for releasing becomes:
- Merge the docs PR
- Merge the automatically generated release-please PR, which will
trigger the workflows to do the tagging, releasing, gem publishing, etc.
### Remaining work to do:
- [x] Change the pull request settings to only allow squash merges, as
jekyllbot enforces this for us today.
- [x] ~Update the site publishing process to pull from `CHANGELOG.md`
instead of `History.markdown`~ No longer needed.
- [x] Integrate jekyllbot into release-please (the release-please PRs
will be made by jekyllbot). This allows actions to be triggered on the
release-please PRs.
- [x] Test the workflows to make sure they generate a PR correctly.
- [x] ~Integrate the release publishing workflow into release-please
when it creates a release.~ Happens automatically with the existing
workflows.
This is a 🔦 documentation change.
I've adjusted the documentation to include a note that Gemfile is
already installed if the reader has completed step 1 in this tutorial. I
thought it was kind of confusing to see instructions on adding a Gemfile
when I had already done that step in the first part of the tutorial.
---------
Co-authored-by: Matt Rogers <mattr-@github.com>
Restore existing behavior in v4.3.x wherein a scope with path
`_*/**/index.md` matches `_label/index.md` as well instead of just
`_label/dir/index.md`.
This is a documentation change to update the current version of Ruby to the
latest as of today: 3.3.5
As for the macOS docs, I updated the supported macOS versions to be in line with what Homebrew supports. I also removed `xz` from the prerequisites that need to be installed with Homebrew since it gets installed automatically when you install ruby-install.
Co-authored-by: Moncef Belyamani <git@rubyonmac.dev>
* Remove duplicate entries pertaining to changes to `3.9-stable` and `3.10-stable` under HEAD.
* Re-arrange headings to follow documented order of priority:
Minor Enhancements > Bug Fixes > Development Fixes > Documentation Changes
Psych 5 has stopped bundling `libyaml` and expects it to be installed on the host system prior
to being invoked.
Since we don't have a direct dependency on the Psych gem (it gets included in the gem bundle
as a dependency of the `rdoc` gem), lock psych gem to v4.x instead of installing `libyaml` in our
development / CI environment.
gem "matrix" is no longer a default gem from Ruby 3.1 onward.
Adding the gem to Gemfile is necessary until `classifier-reborn` adds it as a dependency.
Avoiding RUBY_VERSION constraints to ensure the gem is used on older Ruby versions in CI matrix
While adding `JEKYLL_LOG_LEVEL`, I also found out that `JEKYLL_NO_BUNDLER_REQUIRE` wasn't mentioned in the docs.
I am not sure it belong to this exact place in the doc, so I followed the only env variables example I could find in the doc (`JEKYLL_ENV`)
This diff closes#8480
Explain the choice between installation with Homebrew and rbenv. Mention the other Ruby version managers (asdf, chruby, rvm). Provide a link to a guide that gives more detail and explains the benefits and drawbacks of installation with Homebrew and various version managers. (I'm proposing this addition because there have been frequent questions on Reddit /r/ruby and Stack Overflow by users who installed Ruby for Jekyll with Homebrew and later needed to switch Ruby versions).
Was a bit confused when I saw "mutually exclusive" regarding `error_mode` and (`strict_variables`, `strict_filters`), then to see both sets turned on.
Perhaps "orthogonal" (they don't affect each other) is slightly better wording than "mutually exclusive" (they can't "exist" at the same time)?
During Fedora 34 development, Jekyll 4.2.0 has been tested against
dependency versions outside of current definitions. This commit
relaxes constraints to allow some versions that were found compatible:
* `mercenary` was 0.3.6 in Fedora, works correctly. Nothing in
[changelist][1] indicates problems, either.
* `terminal-table` was 1.8.0 in Fedora, then updated directly to
3.0.0. Both were tested and found to work well. The [changelist][2]
also shows that breaking changes between terminal-table 1 and 3 are
either deprecation of very old Ruby runtimes or tiny changes to
terminal output.
[1]: https://github.com/jekyll/mercenary/blob/master/History.markdown
[2]: https://github.com/tj/terminal-table/blob/master/History.rdoc
* Add PATH to Zsh for newer macOSs
Apple switched the default shell to Zsh with Catalina, so updating the PATH in .bash_profile will not have effect for relevant users, and is increasingly now the legacy approach.
This commit adds instructions to echo the PATH to .zshenv, the Zsh equivalent of .bash_profile, as well as to check which version of macOS the user is using.
* Update PATH in local macOS documentation
The [W3C validator](https://validator.w3.org/feed/check.cgi) says:
> This feed is valid, but interoperability with the widest range of feed readers could be improved by implementing the following recommendations.
With the added line, this should be fixed.
Enable new Lint/DeprecatedOpenSSLConstant cop
Additionally:
* Enable Layout/EmptyLinesAroundAttributeAccessor cop
* Sort configuration by cop names alphabetically
* Add a blank line to separate various departments
* Can use `git ls-files` directly without the `-z` option.
* Can consequently use a readable variable `$INPUT_RECORD_SEPARATOR` instead
of cryptic string `"\x0"` to generate array of paths.
Co-authored-by: Frank Taillandier <frank.taillandier@gmail.com>
* Revert "Pass require path to sub-process when running `bundle install` (#7618)"
This reverts commit 43b9f13b1a.
* Revert "Update history to reflect merge of #7618 [ci skip]"
This reverts commit 2c605bfeb3.
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!
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
@@ -4,30 +4,30 @@ Hi there! Interested in contributing to Jekyll? We'd love your help. Jekyll is a
## Where to get help or report a problem
See [the support guidelines](https://jekyllrb.com/docs/support/)
See the [support guidelines](https://jekyllrb.com/docs/support/)
## Ways to contribute
Whether you're a developer, a designer, or just a Jekyll devotee, there are lots of ways to contribute. Here's a few ideas:
* [Install Jekyll on your computer](https://jekyllrb.com/docs/installation/) and kick the tires. Does it work? Does it do what you'd expect? If not, [open an issue](https://github.com/jekyll/jekyll/issues/new) and let us know.
* Comment on some of the project's [open issues](https://github.com/jekyll/jekyll/issues). Have you experienced the same problem? Know a workaround? Do you have a suggestion for how the feature could be better?
* Read through [the documentation](https://jekyllrb.com/docs/home/), and click the "improve this page" button, any time you see something confusing, or have a suggestion for something that could be improved.
* Browse through [the Jekyll discussion forum](https://talk.jekyllrb.com/), and lend a hand answering questions. There's a good chance you've already experienced what another user is experiencing.
* Find [an open issue](https://github.com/jekyll/jekyll/issues) (especially [those labeled `help-wanted`](https://github.com/jekyll/jekyll/issues?q=is%3Aopen+is%3Aissue+label%3Ahelp-wanted)), and submit a proposed fix. If it's your first pull request, we promise we won't bite, and are glad to answer any questions.
* Help evaluate [open pull requests](https://github.com/jekyll/jekyll/pulls), by testing the changes locally and reviewing what's proposed.
- [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 workaround? Do you have a suggestion for how the feature could be better?
- Read through the [documentation](https://jekyllrb.com/docs/home/), and click the "improve this page" button, any time you see something confusing, or have a suggestion for something that could be improved.
- Browse through the [Jekyll discussion forum](https://talk.jekyllrb.com/), and lend a hand answering questions. There's a good chance you've already experienced what another user is experiencing.
- Find an [open issue](https://github.com/jekyll/jekyll/issues) (especially [those labeled `help-wanted`](https://github.com/jekyll/jekyll/issues?q=is%3Aopen+is%3Aissue+label%3Ahelp-wanted)), and submit a proposed fix. If it's your first pull request, we promise we won't bite, and are glad to answer any questions.
- Help evaluate [open pull requests](https://github.com/jekyll/jekyll/pulls), by testing the changes locally and reviewing what's proposed.
## Submitting a pull request
### Pull requests generally
* The smaller the proposed change, the better. If you'd like to propose two unrelated changes, submit two pull requests.
- The smaller the proposed change, the better. If you'd like to propose two unrelated changes, submit two pull requests.
* The more information, the better. Make judicious use of the pull request body. Describe what changes were made, why you made them, and what impact they will have for users.
- The more information, the better. Make judicious use of the pull request body. Describe what changes were made, why you made them, and what impact they will have for users.
* Pull requests are easy and fun. If this is your first pull request, it may help to [understand GitHub Flow](https://guides.github.com/introduction/flow/).
- If 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.
- If you're submitting a code contribution, be sure to read the [code contributions](#code-contributions) section below.
### Submitting a pull request via github.com
@@ -49,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.
@@ -76,11 +76,12 @@ If you ever need to update our documentation with an icon that is not already av
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
- 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:
- Fix paths in the `@font-face {}` declaration by adding `../` before `fonts/FontAwesome.*` like so:
`('../fonts/Fontawesome.woff?9h6hxj')`.
### Adding plugins
@@ -89,7 +90,7 @@ If you want to add your plugin to the [list of plugins](https://jekyllrb.com/doc
## 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
@@ -101,19 +102,21 @@ If your contribution changes any Jekyll behavior, make sure to update the docume
#### Tests
* If you're creating a small fix or patch to an existing feature, a simple test is more than enough. You can usually copy/paste from an existing example in the `tests` folder, but if you need you can find out about our tests suites [Shoulda](https://github.com/thoughtbot/shoulda/tree/master) and [RSpec-Mocks](https://github.com/rspec/rspec-mocks).
- If you're creating a small fix or patch to an existing feature, a simple test is more than enough. You can usually copy/paste from an existing example in the `tests` folder, but if you need you can find out about our tests suites [Shoulda](https://github.com/thoughtbot/shoulda/tree/master) and [RSpec-Mocks](https://github.com/rspec/rspec-mocks).
* If it's a brand new feature, create a new [Cucumber](https://github.com/cucumber/cucumber/) feature, reusing existing steps where appropriate.
- If it's a brand new feature, create a new [Cucumber](https://github.com/cucumber/cucumber/) feature, reusing existing steps where appropriate.
### Code contributions generally
* Jekyll uses the [Rubocop](https://github.com/bbatsov/rubocop) static analyzer to ensure that contributions follow the [GitHub Ruby Styleguide](https://github.com/styleguide/ruby). Please check your code using `script/fmt` and resolve any errors before pushing your branch.
- Jekyll uses the [Rubocop](https://github.com/bbatsov/rubocop) static analyzer to ensure that contributions follow the [GitHub Ruby Styleguide](https://github.com/styleguide/ruby). Please check your code using `script/fmt` and resolve any errors before pushing your branch.
* Don't bump the Gem version in your pull request (if you don't know what that means, you probably didn't).
- 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)
- 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)
Both `script/test` and `script/cucumber` can be run without arguments to
run its entire respective suite.
## Visual Studio Code Development Container
If you've got [Visual Studio Code](https://code.visualstudio.com/) with the [Remote Development Extension Pack](https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.vscode-remote-extensionpack) installed then simply opening this repository in Visual Studio Code and following the prompts to "Re-open In A Development Container" will get you setup and ready to go with a fresh environment with all the requirements installed.
## A thank you
Thanks! Hacking on Jekyll should be fun. If you find any of this hard to figure out, let us know so we can improve our process or documentation!
[dictionary.txt](dictionary.txt) | Replacement dictionary (creating this file will override the default dictionary) | one word per line | [dictionary](https://github.com/check-spelling/check-spelling/wiki/Configuration#dictionary)
[allow.txt](allow.txt) | Add words to the dictionary | one word per line (only letters and `'`s allowed) | [allow](https://github.com/check-spelling/check-spelling/wiki/Configuration#allow)
[reject.txt](reject.txt) | Remove words from the dictionary (after allow) | grep pattern matching whole dictionary words | [reject](https://github.com/check-spelling/check-spelling/wiki/Configuration-Examples%3A-reject)
[only.txt](only.txt) | Only check matching files (applied after excludes) | perl regular expression | [only](https://github.com/check-spelling/check-spelling/wiki/Configuration-Examples%3A-only)
[patterns.txt](patterns.txt) | Patterns to ignore from checked lines | perl regular expression (order matters, first match wins) | [patterns](https://github.com/check-spelling/check-spelling/wiki/Configuration-Examples%3A-patterns)
[candidate.patterns](candidate.patterns) | Patterns that might be worth adding to [patterns.txt](patterns.txt) | perl regular expression with optional comment block introductions (all matches will be suggested) | [candidates](https://github.com/check-spelling/check-spelling/wiki/Feature:-Suggest-patterns)
[line_forbidden.patterns](line_forbidden.patterns) | Patterns to flag in checked lines | perl regular expression (order matters, first match wins) | [patterns](https://github.com/check-spelling/check-spelling/wiki/Configuration-Examples%3A-patterns)
[expect.txt](expect.txt) | Expected words that aren't in the dictionary | one word per line (sorted, alphabetically) | [expect](https://github.com/check-spelling/check-spelling/wiki/Configuration#expect)
[advice.md](advice.md) | Supplement for GitHub comment when unrecognized words are found | GitHub Markdown | [advice](https://github.com/check-spelling/check-spelling/wiki/Configuration-Examples%3A-advice)
Note: you can replace any of these files with a directory by the same name (minus the suffix)
and then include multiple files inside that directory (with that suffix) to merge multiple files together.
# Update Lorem based on your content (requires `ge` and `w` from https://github.com/jsoref/spelling; and `review` from https://github.com/check-spelling/check-spelling/wiki/Looking-for-items-locally )
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/).
[About First Timers Only](https://www.firsttimersonly.com/).
### 🤔 What you will need to know.
@@ -12,7 +12,7 @@ Nothing. This issue is meant to welcome you to Open Source :) We are happy to wa
- [ ] 👌 **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 recieve an email inviting you to join the Jekyll organization.
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.
# Use only 'java' to analyze code written in Java, Kotlin or both
# Use only 'javascript' to analyze code written in JavaScript, TypeScript or both
# Learn more about CodeQL language support at https://aka.ms/codeql-docs/language-support
steps:
- name:Checkout repository
uses:actions/checkout@v4
# Initializes the CodeQL tools for scanning.
- name:Initialize CodeQL
uses:github/codeql-action/init@v2
with:
languages:${{ matrix.language }}
# If you wish to specify custom queries, you can do so here or in a config file.
# By default, queries listed here will override any specified in a config file.
# Prefix the list here with "+" to use these queries and those in the config file.
# For more details on CodeQL's query packs, refer to: https://docs.github.com/en/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/configuring-code-scanning#using-queries-in-ql-packs
# queries: security-extended,security-and-quality
# Autobuild attempts to build any compiled languages (C/C++, C#, Go, Java, or Swift).
# If this step fails, then you should remove it and run the build manually (see below)
- name:Autobuild
uses:github/codeql-action/autobuild@v2
# ℹ️ Command-line programs to run using the OS shell.
# 📚 See https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstepsrun
# If the Autobuild fails above, remove it and uncomment the following three lines.
# modify them (or add more) to build your code if your project, please refer to the EXAMPLE below for guidance.
Jekyll is a simple, blog-aware, static site generator perfect for personal, project, or organization sites. Think of it like a file-based CMS, without all the complexity. Jekyll takes your content, renders Markdown and Liquid templates, and spits out a complete, static website ready to be served by Apache, Nginx or another web server. Jekyll is the engine behind [GitHub Pages](https://pages.github.com), which you can use to host sites right from your GitHub repositories.
@@ -22,39 +15,67 @@ 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/)
* Have questions? Check out our official forum community [Jekyll Talk](https://talk.jekyllrb.com/) and [`#jekyll` Channel on Libera IRC](https://libera.chat)
## Diving In
* [Migrate](https://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](CODE_OF_CONDUCT.markdown) adapted from the Ruby on Rails code of
[code of conduct](https://jekyllrb.com/docs/conduct/) adapted from the Ruby on Rails code of
conduct.
Please adhere to this code of conduct in any interactions you have in the
Jekyll community. It is strictly enforced on all official Jekyll
repositories, websites, and resources. If you encounter someone violating
these terms, please let one of our core team members [Olivia](mailto:olivia@jekyllrb.com?subject=Jekyll%20CoC%20Violation), [Pat](mailto:pat@jekyllrb.com?subject=Jekyll%20CoC%20Violation), [Matt](mailto:matt@jekyllrb.com?subject=Jekyll%20CoC%20Violation) or [Parker](mailto:parker@jekyllrb.com?subject=Jekyll%20CoC%20Violation) 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)
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
Not everything is a post or a page. Maybe you want to document the various
methods in your open source project, members of a team, or talks at a
conference. Collections allow you to define a new type of document that behave
like Pages or Posts do normally, but also have their own unique properties and
namespace.
Collections are a great way to group related content like members of a team or
talks at a conference.
## Using Collections
## Setup
To start using collections, follow these 3 steps:
* [Step 1: Tell Jekyll to read in your collection](#step1)
* [Step 2: Add your content](#step2)
* [Step 3: Optionally render your collection's documents into independent files](#step3)
### Step 1: Tell Jekyll to read in your collection {#step1}
Add the following to your site's `_config.yml` file, replacing `my_collection`
with the name of your collection:
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:
- my_collection
- staff_members
```
You can optionally specify metadata for your collection in the configuration:
In this case `collections` is defined as a sequence (i.e., array) with no additional metadata defined for each collection.
You can optionally specify metadata for your collection by defining `collections` as a mapping (i.e., hashmap) instead of sequence, and then defining additional fields in it:
```yaml
collections:
my_collection:
foo:bar
staff_members:
people:true
```
Default attributes can also be set for a collection:
```yaml
defaults:
- scope:
path:""
type:my_collection
values:
layout:page
```
{: .note .info}
When defining a collection as a sequence, its pages will not be rendered by
default. To enable this, <code>output: true</code> must be specified on the
collection, which requires defining the collection as a mapping. For more
information, see the section <a href="#output">Output</a>.
<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>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>
### Step 2: Add your content {#step2}
<div class="note warning">
<h5>Be sure to move drafts and posts into custom collections directory</h5>
Create a corresponding folder (e.g. `<source>/_my_collection`) and add
documents. YAML front matter is processed if the front matter exists, and everything
after the front matter is pushed into the document's `content` attribute. If no YAML front
matter is provided, Jekyll will not generate the file in your collection.
<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/' | relative_url }})
and the contents will not undergo further processing. If front matter is provided,
Jekyll will process the file contents into the expected output.
Regardless of whether front matter exists or not, Jekyll will write to the destination
directory (e.g. `_site`) only if `output: true` has been 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*.
```
<em>
Do note that in spite of being considered as a collection internally, the above
doesn't apply to [posts](/docs/posts/). Posts with a valid filename format will be
marked for processing even if they do not contain front matter.
</em>
<div class="note info">
<h5>Be sure to name your directories correctly</h5>
@@ -70,190 +84,118 @@ your <code>_config.yml</code> file, with the addition of the preceding <code>_</
</p>
</div>
### Step 3: Optionally render your collection's documents into independent files {#step3}
## Output
If you'd like Jekyll to create a public-facing, rendered version of each
document in your collection, set the `output` key to `true` in your collection
metadata in your`_config.yml`:
```yaml
collections:
my_collection:
output:true
```
This will produce a file for each document in the collection.
For example, if you have `_my_collection/some_subdir/some_doc.md`,
it will be rendered using Liquid and the Markdown converter of your
choice and written out to `<dest>/my_collection/some_subdir/some_doc.html`.
If you wish a specific page to be shown when accessing `/my_collection/`,
simply add `permalink: /my_collection/index.html` to a page.
To list items from the collection, on that page or any other, you can use:
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
You can configure a collection to show future items by setting the `future` metadata to `true` in the collection's configuration.
```yaml
collections:
staff_members:
future:true
```
each of the following `permalink` configurations will produce the document structure shown below it.
## Permalinks
* **Default**
Same as `permalink: /:collection/:path`.
There are special [permalink variables for collections]({{ '/docs/permalinks/#collections' | relative_url }}) to
help you control the output url for the entire collection.
```
_site/
├── my_collection
│ └── some_subdir
│ └── some_doc.html
...
```
* `permalink: pretty`
Same as `permalink: /:collection/:path/`.
## Custom Sorting of Documents {%- include docs_version_badge.html version="4.0" -%}
{: #custom-sorting-of-documents}
```
_site/
├── my_collection
│ └── some_subdir
│ └── some_doc
│ └── index.html
...
```
* `permalink: /doc/:path`
By default, two documents in a collection are sorted by their `date` attribute when both of them have the `date` key in their front matter. However, if either or both documents do not have the `date` key in their front matter, they are sorted by their respective paths.
```
_site/
├── doc
│ └── some_subdir
│ └── some_doc.html
...
```
* `permalink: /doc/:name`
You can control this sorting via the collection's metadata.
```
_site/
├── doc
│ └── some_doc.html
...
```
* `permalink: /:name`
### Sort By Front Matter Key
```
_site/
├── some_doc.html
...
```
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:
### Template Variables
```yaml
collections:
tutorials:
sort_by:lesson
```
<div class="mobile-side-scroller">
<table>
<thead>
<tr>
<th>Variable</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr>
<td>
<p><code>:collection</code></p>
</td>
<td>
<p>Label of the containing collection.</p>
</td>
</tr>
<tr>
<td>
<p><code>:path</code></p>
</td>
<td>
<p>Path to the document relative to the collection's directory.</p>
</td>
</tr>
<tr>
<td>
<p><code>:name</code></p>
</td>
<td>
<p>The document's base filename, with every sequence of spaces
and non-alphanumeric characters replaced by a hyphen.</p>
</td>
</tr>
<tr>
<td>
<p><code>:title</code></p>
</td>
<td>
<p>
The <code>:title</code> template variable will take the
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/' | relative_url }})
## Reporting Security Vulnerabilities
Find something in our codebase that could be exploited by malicious elements?
Consult our [Security Policy]({{ '/docs/security/' | relative_url }}) to see if a product version is considered *outdated* and how to report
the situation responsibly.
## Where to get support
If you're looking for support for Jekyll, there are a lot of options:
* Read the [Jekyll Documentation]({{ '/docs/' | relative_url }})
* 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 #jekyll on [Libera](irc://irc.libera.chat/#jekyll).
There are a bunch of helpful community members on these services who are 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/' | relative_url }})
* [How to file a bug]({{ '/docs/community/bug/' | relative_url }})
* [Guide for maintaining Jekyll]({{ '/docs/maintaining/' | relative_url }})
## Jekyllconf
[Watch videos]({{ '/jekyllconf/' | relative_url }}) 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).
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
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>
<p class="description">SSL Public certificate.</p>
</td>
<td class="align-center">
<p><code class="flag">--ssl-cert</code></p>
</td>
</tr>
</tbody>
</table>
</div>
<div class="note warning">
<h5>Do not use tabs in configuration files</h5>
<p>
This will either lead to parsing errors, or Jekyll will revert to the
default settings. Use spaces instead.
</p>
</div>
## Custom WEBrick Headers
You can provide custom headers for your site by adding them to `_config.yml`
```yaml
# File: _config.yml
webrick:
headers:
My-Header:My-Value
My-Other-Header:My-Other-Value
```
### Defaults
We provide by default `Content-Type` and `Cache-Control` response headers: one
dynamic in order to specify the nature of the data being served, the other
static in order to disable caching so that you don't have to fight with Chrome's
aggressive caching when you are in development mode.
## Specifying a Jekyll environment at build time
In the build (or serve) arguments, you can specify a Jekyll environment and value. The build will then apply this value in any conditional statements in your content.
For example, suppose you set this conditional statement in your code:
```liquid
{% raw %}
{% if jekyll.environment == "production" %}
{% include disqus.html %}
{% endif %}
{% endraw %}
```
When you build your Jekyll site, the content inside the `if` statement won't be run unless you also specify a `production` environment in the build command, like this:
```sh
JEKYLL_ENV=production jekyll build
```
Specifying an environment value allows you to make certain content available only within specific environments.
The default value for `JEKYLL_ENV` is `development`. Therefore if you omit `JEKYLL_ENV` from the build arguments, the default value will be `JEKYLL_ENV=development`. Any content inside `{% raw %}{% if jekyll.environment == "development" %}{% endraw %}` tags will automatically appear in the build.
Your environment values can be anything you want (not just `development` or `production`). Some elements you might want to hide in development environments include Disqus comment forms or Google Analytics. Conversely, you might want to expose an "Edit me in GitHub" button in a development environment but not include it in production environments.
By specifying the option in the build command, you avoid having to change values in your configuration files when moving from one environment to another.
## Front Matter defaults
Using [YAML Front Matter](../frontmatter/) is one way that you can specify configuration in the pages and posts for your site. Setting things like a default layout, or customizing the title, or specifying a more precise date/time for the post can all be added to your page or post front matter.
Often times, you will find that you are repeating a lot of configuration options. Setting the same layout in each file, adding the same category - or categories - to a post, etc. You can even add custom variables like author names, which might be the same for the majority of posts on your blog.
Instead of repeating this configuration each time you create a new post or page, Jekyll provides a way to set these defaults in the site configuration. To do this, you can specify site-wide defaults using the `defaults` key in the `_config.yml` file in your 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>Please stop and rerun `jekyll serve` command.</h5>
<p>
The <code>_config.yml</code> master configuration file contains global configurations
and variable definitions that are read once at execution time. Changes made to <code>_config.yml</code>
during automatic regeneration are not loaded until the next execution.
</p>
<p>
Note <a href="../datafiles">Data Files</a> are included and reloaded during automatic regeneration.
</p>
</div>
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](../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](../collections/) with the name `my_collection`.
It is also possible to use glob patterns 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"
```
### Precedence
Jekyll will apply all of the configuration settings you specify in the `defaults` section of your `_config.yml` file. However, you can choose to override settings from other scope/values pair by specifying a more specific path for the scope.
You can see that in the 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 site is built.
## Default Configuration
Jekyll runs with the following configuration options by default. Alternative
settings for these options can be explicitly specified in the configuration
file or on the command-line.
<div class="note warning">
<h5>There are two unsupported kramdown options</h5>
<p>
Please note that both <code>remove_block_html_tags</code> and
<code>remove_span_html_tags</code> are currently unsupported in Jekyll due
to the fact that they are not included within the kramdown HTML converter.
Jekyll runs with the following configuration options by default. Alternative
settings for these options can be explicitly specified in the configuration
file or on the command-line.
<div class="note info">
<h5>Be aware of directory paths</h5>
<p>
In general, make directory path values in configuration keys like <code>plugins_dir</code> relative to the current working directory, not the site source. The <code>sass</code> configuration key is an exception, where values must be relative to the site source.
</p>
</div>
```yaml
# Where things are
source :.
destination :./_site
collections_dir :.
plugins_dir :_plugins# takes an array of strings and loads plugins in that order
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/' | relative_url }}">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/' | relative_url }}) 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/' | relative_url }}) 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
Liquid's response to errors can be configured by setting `error_mode`. The
options are
-`lax` --- Ignore all errors.
-`warn` --- Output a warning on the console for each error. (default)
-`strict` --- Output an error message and stop the build.
Within _config.yml, the default configuration is as follows:
```yaml
liquid:
error_mode:warn
```
The above example depicts the "warn" value, which is already set by default- `error_mode: warn`. This results in any issues being called out during the build process however will continue to build if possible.
You can also configure Liquid's renderer to catch non-assigned variables and
non-existing filters by setting `strict_variables` and / or `strict_filters`
to `true` respectively. {% include docs_version_badge.html version="3.8.0" %}
Do note that while `error_mode` configures Liquid's parser, the `strict_variables`
and `strict_filters` options configure Liquid's renderer and are consequently
orthogonal.
An example of setting these variables within _config.yml is as follows:
```yaml
liquid:
error_mode:strict
strict_variables:true
strict_filters:true
```
Configuring as described above will stop your build/serve from happening and call out the offending error and halt. This is helpful when desiring to catch liquid-related issues by stopping the build or serve process and allowing you to deal with any issues.
The various Markdown renderers supported by Jekyll sometimes have extra options
available.
## Kramdown
Kramdown is the default Markdown renderer for Jekyll, and often works well with no additional configuration. However, it does support many configuration options.
### Kramdown Processor
By default, Jekyll uses the [GitHub Flavored Markdown (GFM) processor](https://github.com/kramdown/parser-gfm) for Kramdown. (Specifying `input: GFM` is fine, but redundant.) GFM supports a couple additional Kramdown options, documented by [kramdown-parser-gfm](https://github.com/kramdown/parser-gfm). These options can be used directly in your Kramdown Jekyll config, like this:
```yaml
kramdown:
gfm_quirks:[paragraph_end]
```
You can also change the processor used by Kramdown (as specified for the `input` key in the [Kramdown RDoc](https://kramdown.gettalong.org/rdoc/Kramdown/Document.html#method-c-new)). For example, to use the non-GFM Kramdown processor in Jekyll, add the following to your configuration.
```yaml
kramdown:
input:Kramdown
```
Documentation for Kramdown parsers is available in the [Kramdown docs](https://kramdown.gettalong.org/parser/kramdown.html). If you use a Kramdown parser other than Kramdown or GFM, you'll need to add the gem for it.
### Syntax Highlighting (CodeRay)
To use the [CodeRay](http://coderay.rubychan.de/) syntax highlighter with Kramdown, you need to add a dependency on the `kramdown-syntax-coderay` gem. For example, `bundle add kramdown-syntax-coderay`. Then, you'll be able to specify CodeRay in your `syntax_highlighter` config:
```yaml
kramdown:
syntax_highlighter:coderay
```
CodeRay supports several of its own configuration options, documented in the [kramdown-syntax-coderay docs](https://github.com/kramdown/syntax-coderay) which can be passed as `syntax_highlighter_opts` like this:
```yaml
kramdown:
syntax_highlighter:coderay
syntax_highlighter_opts:
line_numbers:table
bold_every:5
```
### Advanced Kramdown Options
Kramdown supports a variety of other relatively advanced options such as `header_offset` and `smart_quotes`. These are documented in the [Kramdown configuration documentation](https://kramdown.gettalong.org/options.html) and can be added to your Kramdown config like this:
```yaml
kramdown:
header_offset:2
```
<div class="note warning">
<h5>There are several unsupported kramdown options</h5>
<p>
Please note that Jekyll uses Kramdown's HTML converter. Kramdown options used only by other converters, such as <code>remove_block_html_tags</code> (used by the RemoveHtmlTags converter), will not work.
</p>
</div>
## 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).
### 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:
Jekyll comes bundled with [jekyll-sass-converter](https://github.com/jekyll/jekyll-sass-converter) plugin. By default, Jekyll will look for Sass partials in the `_sass` directory relative to your site's `source` directory.
You can further configure the plugin by adding options to your Jekyll config under the `sass` attribute. See the [plugin's documentation](https://github.com/jekyll/jekyll-sass-converter#usage) for details and for its default values.
{:.note .info}
If you see a warning in VSCode regarding `@import "main";`, you may ignore it as the same does not affect the functionality of the SCSS code in Jekyll. However, Jekyll 4 does not allow importing a `main` sass partial (`_sass/main.scss`) from a sass page of a same name, viz. `css/main.scss`.
<div class="note info">
<p>
Note that directory paths specified in the <code>sass</code> configuration
are resolved relative to your site's <code>source</code>, not relative to the location of the <code>_config.yml</code> file.
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.
@@ -12,12 +12,12 @@ Building, testing, and deploying your Jekyll-generated website can quickly be do
To start building your project on CircleCI, all you need to do is 'follow' your project from CircleCI's website:
1. Visit the 'Add Projects' page: <https://circleci.com/add-projects>
1. 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.
1. The first build will start on its own. You can start telling CircleCI how to build your project by creating a [.circleci/config.yml][3] file in the root of your repository.
@@ -28,22 +28,24 @@ The easiest way to manage dependencies for a Jekyll project (with or without Cir
```ruby
source'https://rubygems.org'
ruby'2.4.0'
ruby'2.7.4'
gem'jekyll'
gem'html-proofer'
gem"jekyll"
gem"html-proofer"
```
CircleCI detects when `Gemfile` is present is will automatically run `bundle install` for you in the `dependencies` phase.
```yaml
- step:
run:bundle install
```
## 3. Testing
The most basic test that can be run is simply seeing if `jekyll build` actually works. This is a blocker, a dependency if you will, for other tests you might run on the generate site. So we'll run Jekyll, via Bundler, in the `dependencies` phase.
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
- step:
run:bundle exec jekyll build
```
### HTML Proofer
@@ -54,33 +56,76 @@ With your site built, it's useful to run tests to check for valid HTML, broken l
Continuous Integration (CI) enables you to publish your Jekyll generated website with confidence by automating the quality assurance and deployment processes. You can quickly get started using CI with one of the providers below:
[Razorops][razorops-homepage] is a complete container native CI/CD solution handling all aspects of the software lifecycle from the moment a commit is created until it is deployed to production.
Razorops has all the capabilities that you would expect from a CI/CD platform such as
Razorops is a single solution that implements the whole pipeline from start to deployment.
With [Razorops][razorops-homepage] you can set up your Jekyll websites project's build, test, and deploy steps just in 15 min. It supports [GitHub][github-homepage], [Bitbucket][bitbucket-homepage], and [GitLab][gitlab-homepage] repositories. The following guide will show you how to set up a free environment to build, test and deploy your Jekyll project.
1. Log in at [https://razorops.com/][razorops-homepage] with your GitHub/Bitbucket or GitLab account
2. Create a pipeline, choose your Git provider and select your Jekyll Project
3. Add .razorops.yaml file in your root directory of your project
4. Add environment var and your deployment is ready
5. Add build and deployment steps as shown in this post [How to Deploy a Static Website to AWS S3 with Razorops CI/CD][deploy-s3]
## 2. How it works
Whenever you make a push to the selected branch, your steps auto runs as defined in .razorops.yaml file
```yaml
tasks:
build-and-deploy:
steps:
- checkout
# commands to build jekyll website
- commands:
- bundle install
- JEKYLL_ENV=production bundle exec jekyll build
# Commands to upload static pages folder to AWS S3 or ftp
# Set AWS access key & secrets environment variables under
# Razorops dashboard project pipelines
- commands:
- aws s3 rm s3://$AWS_S3_BUCKET --recursive
- aws s3 cp _site s3://$AWS_S3_BUCKET --recursive
if:branch == 'main'
```
Build step generates _site folder as Jekyll default and during deploy you will able to ship code to s3 or any ftp server you can define any command to ship your website code to server.
Razorops is FREE for opensource projects, Try it Now
You can easily test your website build against one or more versions of Ruby.
You can test your website build against one or more versions of Ruby.
The following guide will show you how to set up a free build environment on
[Travis][travis], with [GitHub][github] integration for pull requests.
@@ -11,7 +11,7 @@ The following guide will show you how to set up a free build environment on
## 1. Enabling Travis and GitHub
Enabling Travis builds for your GitHub repository is pretty simple:
To enable Travis builds for your GitHub repository:
1. Go to your profile on travis-ci.org: https://travis-ci.org/profile/username
2. Find the repository for which you're interested in enabling builds.
@@ -21,7 +21,7 @@ Enabling Travis builds for your GitHub repository is pretty simple:
## 2. The Test Script
The simplest test script simply runs `jekyll build` and ensures that Jekyll
The simplest test script runs `jekyll build` and ensures that Jekyll
doesn't fail to build the site. It doesn't check the resulting site, but it
does ensure things are built properly.
@@ -34,7 +34,7 @@ Save the commands you want to run and succeed in a file: `./script/cibuild`
### The HTML Proofer Executable
```sh
```bash
#!/usr/bin/env bash
set -e # halt script on error
@@ -76,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"
@@ -90,7 +90,7 @@ Your `.travis.yml` file should look like this:
```yaml
language:ruby
rvm:
- 2.3.3
- 2.6.3
before_script:
- chmod +x ./script/cibuild# or do this locally and commit
@@ -105,11 +105,16 @@ branches:
- gh-pages # test the gh-pages branch
- /pages-(.*)/# test every branch which starts with "pages-"
env:
global:
- NOKOGIRI_USE_SYSTEM_LIBRARIES=true# speeds up installation of html-proofer
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:
@@ -123,12 +128,13 @@ access to Bundler, RubyGems, and a Ruby runtime.
```yaml
rvm:
- 2.3.3
- 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:
@@ -177,18 +183,6 @@ prefixed, exemplified above with the `/pages-(.*)/` regular expression.
The `branches` directive is completely optional. Travis will build from every
push to any branch of your repo if leave it out.
```yaml
env:
global:
- NOKOGIRI_USE_SYSTEM_LIBRARIES=true# speeds up installation of html-proofer
```
Using `html-proofer`? You'll want this environment variable. Nokogiri, used
to parse HTML files in your compiled site, comes bundled with libraries
which it must compile each time it is installed. Luckily, you can
dramatically decrease the install time of Nokogiri by setting the
environment variable `NOKOGIRI_USE_SYSTEM_LIBRARIES` to `true`.
<div class="note warning">
<h5>Be sure to exclude <code>vendor</code> from your
<code>_config.yml</code></h5>
@@ -200,14 +194,21 @@ environment variable `NOKOGIRI_USE_SYSTEM_LIBRARIES` to `true`.
exclude:[vendor]
```
By default you should supply the `sudo: false` command to Travis. This command
explicitly tells Travis to run your build on Travis's [container-based
infrastructure](https://docs.travis-ci.com/user/workers/container-based-infrastructure/#Routing-your-build-to-container-based-infrastructure). Running on the container-based infrastructure can often times
speed up your build. If you have any trouble with your build, or if your build
does need `sudo` access, modify the line to `sudo: required`.
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
sudo:false
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
@@ -227,3 +228,6 @@ fix or [ask for help][4] if you run into trouble and need some help.
@@ -8,30 +8,30 @@ Hi there! Interested in contributing to Jekyll? We'd love your help. Jekyll is a
## Where to get help or report a problem
See [the support guidelines](https://jekyllrb.com/docs/support/)
See the [support guidelines](https://jekyllrb.com/docs/support/)
## Ways to contribute
Whether you're a developer, a designer, or just a Jekyll devotee, there are lots of ways to contribute. Here's a few ideas:
* [Install Jekyll on your computer](https://jekyllrb.com/docs/installation/) and kick the tires. Does it work? Does it do what you'd expect? If not, [open an issue](https://github.com/jekyll/jekyll/issues/new) and let us know.
* Comment on some of the project's [open issues](https://github.com/jekyll/jekyll/issues). Have you experienced the same problem? Know a workaround? Do you have a suggestion for how the feature could be better?
* Read through [the documentation](https://jekyllrb.com/docs/home/), and click the "improve this page" button, any time you see something confusing, or have a suggestion for something that could be improved.
* Browse through [the Jekyll discussion forum](https://talk.jekyllrb.com/), and lend a hand answering questions. There's a good chance you've already experienced what another user is experiencing.
* Find [an open issue](https://github.com/jekyll/jekyll/issues) (especially [those labeled `help-wanted`](https://github.com/jekyll/jekyll/issues?q=is%3Aopen+is%3Aissue+label%3Ahelp-wanted)), and submit a proposed fix. If it's your first pull request, we promise we won't bite, and are glad to answer any questions.
* Help evaluate [open pull requests](https://github.com/jekyll/jekyll/pulls), by testing the changes locally and reviewing what's proposed.
- [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 workaround? Do you have a suggestion for how the feature could be better?
- Read through the [documentation](https://jekyllrb.com/docs/home/), and click the "improve this page" button, any time you see something confusing, or have a suggestion for something that could be improved.
- Browse through the [Jekyll discussion forum](https://talk.jekyllrb.com/), and lend a hand answering questions. There's a good chance you've already experienced what another user is experiencing.
- Find an [open issue](https://github.com/jekyll/jekyll/issues) (especially [those labeled `help-wanted`](https://github.com/jekyll/jekyll/issues?q=is%3Aopen+is%3Aissue+label%3Ahelp-wanted)), and submit a proposed fix. If it's your first pull request, we promise we won't bite, and are glad to answer any questions.
- Help evaluate [open pull requests](https://github.com/jekyll/jekyll/pulls), by testing the changes locally and reviewing what's proposed.
## Submitting a pull request
### Pull requests generally
* The smaller the proposed change, the better. If you'd like to propose two unrelated changes, submit two pull requests.
- The smaller the proposed change, the better. If you'd like to propose two unrelated changes, submit two pull requests.
* The more information, the better. Make judicious use of the pull request body. Describe what changes were made, why you made them, and what impact they will have for users.
- The more information, the better. Make judicious use of the pull request body. Describe what changes were made, why you made them, and what impact they will have for users.
* Pull requests are easy and fun. If this is your first pull request, it may help to [understand GitHub Flow](https://guides.github.com/introduction/flow/).
- If 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.
- If you're submitting a code contribution, be sure to read the [code contributions](#code-contributions) section below.
### Submitting a pull request via github.com
@@ -53,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.
@@ -80,11 +80,12 @@ If you ever need to update our documentation with an icon that is not already av
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
- 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:
- Fix paths in the `@font-face {}` declaration by adding `../` before `fonts/FontAwesome.*` like so:
`('../fonts/Fontawesome.woff?9h6hxj')`.
### Adding plugins
@@ -93,7 +94,7 @@ If you want to add your plugin to the [list of plugins](https://jekyllrb.com/doc
## 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
@@ -105,19 +106,21 @@ If your contribution changes any Jekyll behavior, make sure to update the docume
#### Tests
* If you're creating a small fix or patch to an existing feature, a simple test is more than enough. You can usually copy/paste from an existing example in the `tests` folder, but if you need you can find out about our tests suites [Shoulda](https://github.com/thoughtbot/shoulda/tree/master) and [RSpec-Mocks](https://github.com/rspec/rspec-mocks).
- If you're creating a small fix or patch to an existing feature, a simple test is more than enough. You can usually copy/paste from an existing example in the `tests` folder, but if you need you can find out about our tests suites [Shoulda](https://github.com/thoughtbot/shoulda/tree/master) and [RSpec-Mocks](https://github.com/rspec/rspec-mocks).
* If it's a brand new feature, create a new [Cucumber](https://github.com/cucumber/cucumber/) feature, reusing existing steps where appropriate.
- If it's a brand new feature, create a new [Cucumber](https://github.com/cucumber/cucumber/) feature, reusing existing steps where appropriate.
### Code contributions generally
* Jekyll uses the [Rubocop](https://github.com/bbatsov/rubocop) static analyzer to ensure that contributions follow the [GitHub Ruby Styleguide](https://github.com/styleguide/ruby). Please check your code using `script/fmt` and resolve any errors before pushing your branch.
- Jekyll uses the [Rubocop](https://github.com/bbatsov/rubocop) static analyzer to ensure that contributions follow the [GitHub Ruby Styleguide](https://github.com/styleguide/ruby). Please check your code using `script/fmt` and resolve any errors before pushing your branch.
* Don't bump the Gem version in your pull request (if you don't know what that means, you probably didn't).
- 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)
- 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)
Both `script/test` and `script/cucumber` can be run without arguments to
run its entire respective suite.
## Visual Studio Code Development Container
If you've got [Visual Studio Code](https://code.visualstudio.com/) with the [Remote Development Extension Pack](https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.vscode-remote-extensionpack) installed then simply opening this repository in Visual Studio Code and following the prompts to "Re-open In A Development Container" will get you setup and ready to go with a fresh environment with all the requirements installed.
## A thank you
Thanks! Hacking on Jekyll should be fun. If you find any of this hard to figure out, let us know so we can improve our process or documentation!
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](https://yaml.org), [JSON](https://www.json.org/json-en.html), [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`.
@@ -18,10 +17,9 @@ 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 `.yml`, `.yaml`, `.json` or `.csv` extension), and they will be
The `_data` folder is where you can store additional data for Jekyll to use when
generating your site. These files must be YAML, JSON, TSV or CSV files (using either
the `.yml`, `.yaml`, `.json`, `.tsv`, or `.csv` extension), and they will be
accessible via `site.data`.
## Example: List of members
@@ -44,15 +42,15 @@ In `_data/members.yml`:
Or `_data/members.csv`:
```text
```
name,github
Eric Mill,konklone
Parker Moore,parkr
Liu Fengyun,liufengyun
```
This data can be accessed via `site.data.members` (notice that the filename
determines the variable name).
This data can be accessed via `site.data.members` (notice that the file's *basename* determines the variable name and
therefore one should avoid having data files with the same basename but different extensions, in the same directory).
You can now render the list of members in a template:
@@ -70,10 +68,7 @@ You can now render the list of members in a template:
```
{% endraw %}
{: .note .info }
If your Jekyll site has a lot of pages, such as with documentation websites, see the detailed examples in [how to build robust navigation for your site]({% link _tutorials/navigation.md %}).
## Example: Organizations
## 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
@@ -134,7 +129,7 @@ dave:
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:
{% raw %}
```liquid
@@ -152,4 +147,31 @@ author: dave
```
{% endraw %}
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).
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/' | relative_url }}).
## CSV/TSV Parse Options
The way Ruby parses CSV and TSV files can be customized with the `csv_reader` and `tsv_reader`
configuration options. Each configuration key exposes the same options:
`converters`: What [CSV converters](https://ruby-doc.org/stdlib-2.5.0/libdoc/csv/rdoc/CSV.html#Converters) should be
used when parsing the file. Available options are `integer`, `float`, `numeric`, `date`, `date_time` and
`all`. By default, this list is empty.
`encoding`: What encoding the files are in. Defaults to the site `encoding` configuration option.
`headers`: Boolean field for whether to parse the first line of the file as headers. When `false`, it treats the
first row as data. Defaults to `true`.
Examples:
```yaml
csv_reader:
converters:
- numeric
- datetime
headers:true
encoding:utf-8
tsv_reader:
converters:
- all
headers:false
```
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.