Frank Taillandier
jekyllbot
parent
94baf09753
commit
688d0734b8
|
|
@ -25,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 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.
|
||||
|
||||
|
|
|
|||
|
|
@ -1545,7 +1545,7 @@
|
|||
* Internal: trigger hooks by owner symbol (#3871)
|
||||
* Update MIME types from mime-db (#3933)
|
||||
* Add header to site template `_config.yml` for clarity & direction (#3997)
|
||||
* Site template: add timezone offset to post date frontmatter (#4001)
|
||||
* Site template: add timezone offset to post date front matter (#4001)
|
||||
* Make a constant for the regex to find hidden files (#4032)
|
||||
* Site template: refactor github & twitter icons into includes (#4049)
|
||||
* Site template: add background to Kramdown Rouge-ified backtick code blocks (#4053)
|
||||
|
|
@ -1685,7 +1685,7 @@
|
|||
* Add a link on all the docs pages to "Improve this page". (#3510)
|
||||
* Add jekyll-auto-image generator to the list of third-party plugins (#3489)
|
||||
* Replace link to the proposed `picture` element spec (#3530)
|
||||
* Add frontmatter date formatting information (#3469)
|
||||
* Add front matter date formatting information (#3469)
|
||||
* Improve consistency and clarity of plugins options note (#3546)
|
||||
* Add permalink warning to pagination docs (#3551)
|
||||
* Fix grammar in Collections docs API stability warning (#3560)
|
||||
|
|
|
|||
|
|
@ -6,50 +6,47 @@ redirect_from: "/conduct/index.html"
|
|||
editable: false
|
||||
---
|
||||
|
||||
As contributors and maintainers of this project, and in the interest of
|
||||
fostering an open and welcoming community, we pledge to respect all people who
|
||||
contribute through reporting issues, posting feature requests, updating
|
||||
documentation, submitting pull requests or patches, and other activities.
|
||||
## Our Pledge
|
||||
|
||||
We are committed to making participation in this project a harassment-free
|
||||
experience for everyone, regardless of level of experience, gender, gender
|
||||
identity and expression, sexual orientation, disability, personal appearance,
|
||||
body size, race, ethnicity, age, religion, or nationality.
|
||||
In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, nationality, personal appearance, race, religion, or sexual identity and orientation.
|
||||
|
||||
## Our Standards
|
||||
|
||||
Examples of behavior that contributes to creating a positive environment include:
|
||||
|
||||
* Using welcoming and inclusive language
|
||||
* Being respectful of differing viewpoints and experiences
|
||||
* Gracefully accepting constructive criticism
|
||||
* Focusing on what is best for the community
|
||||
* Showing empathy towards other community members
|
||||
|
||||
Examples of unacceptable behavior by participants include:
|
||||
|
||||
* The use of sexualized language or imagery
|
||||
* Personal attacks
|
||||
* Trolling or insulting/derogatory comments
|
||||
* 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 other's private information, such as physical or electronic
|
||||
addresses, without explicit permission
|
||||
* Other unethical or unprofessional conduct
|
||||
* 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
|
||||
|
||||
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.
|
||||
## Our Responsibilities
|
||||
|
||||
By adopting this Code of Conduct, project maintainers commit themselves to
|
||||
fairly and consistently applying these principles to every aspect of managing
|
||||
this project. Project maintainers who do not follow or enforce the Code of
|
||||
Conduct may be permanently removed from the project team.
|
||||
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.
|
||||
|
||||
This Code of Conduct applies both within project spaces and in public spaces
|
||||
when an individual is representing the project or its community.
|
||||
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.
|
||||
|
||||
Instances of abusive, harassing, or otherwise unacceptable behavior may be
|
||||
reported by opening an issue or contacting a project maintainer. All complaints
|
||||
will be reviewed and investigated and will result in a response that is deemed
|
||||
necessary and appropriate to the circumstances. Maintainers are obligated to
|
||||
maintain confidentiality with regard to the reporter of an incident.
|
||||
## 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.
|
||||
|
||||
This Code of Conduct is adapted from the [Contributor Covenant][homepage],
|
||||
version 1.3.0, available at
|
||||
[http://contributor-covenant.org/version/1/3/0/][version]
|
||||
## Enforcement
|
||||
|
||||
[homepage]: http://contributor-covenant.org
|
||||
[version]: http://contributor-covenant.org/version/1/3/0/
|
||||
Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by opening an issue or contacting a project maintainer. The project team will review and investigate all complaints, and will respond in a way that it deems appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately.
|
||||
|
||||
Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership.
|
||||
|
||||
## Attribution
|
||||
|
||||
This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4, available at [https://www.contributor-covenant.org/version/1/4/code-of-conduct.html][version]
|
||||
|
||||
[homepage]: https://www.contributor-covenant.org/
|
||||
[version]: https://www.contributor-covenant.org/version/1/4/code-of-conduct.html
|
||||
|
|
|
|||
|
|
@ -209,7 +209,7 @@ you specified in your `_config.yml` (if present) and the following information:
|
|||
<p>Except for documents in hard-coded default collection <code>posts</code>, all documents in collections
|
||||
you create, are accessible via Liquid irrespective of their assigned date, if any, and therefore renderable.
|
||||
</p>
|
||||
<p>However documents are attempted to be written to disk only if the concerned collection
|
||||
<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>
|
||||
|
|
|
|||
|
|
@ -117,7 +117,7 @@ defaults:
|
|||
|
||||
### 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.
|
||||
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.
|
||||
|
||||
|
|
|
|||
|
|
@ -38,7 +38,7 @@ CircleCI detects when `Gemfile` is present is will automatically run `bundle ins
|
|||
|
||||
## 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:
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
title: "Travis CI"
|
||||
---
|
||||
|
||||
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.
|
||||
|
||||
|
|
@ -222,7 +222,7 @@ 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`.
|
||||
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.
|
||||
|
||||
|
|
|
|||
|
|
@ -29,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 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.
|
||||
|
||||
|
|
|
|||
|
|
@ -7,24 +7,12 @@ 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:
|
||||
|
||||
## 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, simply run the `jekyll build` command and copy the contents of the generated `_site` folder to the root folder of your hosting account. This is most likely to be the `httpdocs` or `public_html` folder on most hosting providers.
|
||||
|
||||
## 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. Just remember to make sure the contents of the generated `_site` folder get placed in the appropriate web root directory for your web server.
|
||||
|
||||
## 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).
|
||||
|
||||
## Rack-Jekyll
|
||||
|
||||
[Rack-Jekyll](https://github.com/adaoraul/rack-jekyll/) is an easy way to deploy your site on any Rack server such as Amazon EC2, Slicehost, Heroku, and so forth. It also can run with [shotgun](https://github.com/rtomayko/shotgun/), [rackup](https://github.com/rack/rack), [mongrel](https://github.com/mongrel/mongrel), [unicorn](https://github.com/defunkt/unicorn/), and [others](https://github.com/adaoraul/rack-jekyll#readme).
|
||||
|
||||
## Amazon S3
|
||||
|
||||
If you want to host your site in Amazon S3, you can do so by
|
||||
|
|
@ -34,3 +22,16 @@ 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).
|
||||
|
|
|
|||
|
|
@ -21,11 +21,11 @@ Sites on GitHub Pages are powered by Jekyll behind the scenes, so if you’re lo
|
|||
|
||||
## Kickster
|
||||
|
||||
Use [Kickster](http://kickster.nielsenramon.com/) for easy (automated) deploys to GitHub Pages when using unsupported plugins on GitHub Pages.
|
||||
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.
|
||||
|
||||
Setting up Kickster is very easy, just install the gem and you are good to go. More documentation can here found [here](https://github.com/nielsenramon/kickster#kickster). If you do not want to use the gem or start a new project you can just copy paste the deployment scripts for [Travis CI](https://github.com/nielsenramon/kickster/tree/master/snippets/travis) or [Circle CI](https://github.com/nielsenramon/kickster#automated-deployment-with-circle-ci).
|
||||
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
|
||||
|
|
|
|||
|
|
@ -71,14 +71,14 @@ front matter of a page or post.
|
|||
<ul>
|
||||
<li>
|
||||
Using <code>null</code> will produce a file without using a layout
|
||||
file. However this is overridden if the file is a post/document and has a
|
||||
file. This is overridden if the file is a post/document and has a
|
||||
layout defined in the <a href="/docs/configuration/front-matter-defaults/">
|
||||
front matter defaults</a>.
|
||||
</li>
|
||||
<li>
|
||||
Starting from version 3.5.0, using <code>none</code> in a post/document will
|
||||
produce a file without using a layout file regardless of front matter defaults.
|
||||
Using <code>none</code> in a page, however, will cause Jekyll to attempt to
|
||||
Using <code>none</code> in a page will cause Jekyll to attempt to
|
||||
use a layout named "none".
|
||||
</li>
|
||||
</ul>
|
||||
|
|
@ -116,7 +116,7 @@ front matter of a page or post.
|
|||
<div class="note">
|
||||
<h5>ProTip™: Render Posts Marked As Unpublished</h5>
|
||||
<p>
|
||||
To preview unpublished pages, simply run `jekyll serve` or `jekyll build`
|
||||
To preview unpublished pages, run `jekyll serve` or `jekyll build`
|
||||
with the `--unpublished` switch. Jekyll also has a handy <a href="/docs/posts/#drafts">drafts</a>
|
||||
feature tailored specifically for blog posts.
|
||||
</p>
|
||||
|
|
@ -204,7 +204,7 @@ These are available out-of-the-box to be used in the front matter for a post.
|
|||
<h5>ProTip™: Don't repeat yourself</h5>
|
||||
<p>
|
||||
If you don't want to repeat your frequently used front matter variables
|
||||
over and over, just define <a href="/docs/configuration/front-matter-defaults/" title="Front Matter defaults">defaults</a>
|
||||
over and over, define <a href="/docs/configuration/front-matter-defaults/" title="Front Matter defaults">defaults</a>
|
||||
for them and only override them where necessary (or not at all). This works
|
||||
both for predefined and custom variables.
|
||||
</p>
|
||||
|
|
|
|||
|
|
@ -56,7 +56,7 @@ Be sure to run `bundle update` often.
|
|||
### Project Page URL Structure
|
||||
|
||||
Sometimes it's nice to preview your Jekyll site before you push your `gh-pages`
|
||||
branch to GitHub. However, the subdirectory-like URL structure GitHub uses for
|
||||
branch to GitHub. The subdirectory-like URL structure GitHub uses for
|
||||
Project Pages complicates the proper resolution of URLs. In order to assure your
|
||||
site builds properly, use the handy [URL filters](/docs/liquid/filters/):
|
||||
|
||||
|
|
|
|||
|
|
@ -4,6 +4,15 @@ permalink: "/docs/history/"
|
|||
note: This file is autogenerated. Edit /History.markdown instead.
|
||||
---
|
||||
|
||||
## 3.8.4 / 2018-09-18
|
||||
{: #v3-8-4}
|
||||
|
||||
### Bug Fixes
|
||||
{: #bug-fixes-v3-8-4}
|
||||
|
||||
- 3.8.x: security: fix `include` bypass of `EntryFilter#filter` symlink check ([#7228]({{ site.repository }}/issues/7228))
|
||||
|
||||
|
||||
## 3.8.3 / 2018-06-05
|
||||
{: #v3-8-3}
|
||||
|
||||
|
|
@ -137,6 +146,15 @@ note: This file is autogenerated. Edit /History.markdown instead.
|
|||
- Allow front matter defaults to be applied properly to documents gathered under custom `collections_dir` ([#6885]({{ site.repository }}/issues/6885))
|
||||
|
||||
|
||||
## 3.7.4 / 2018-09-07
|
||||
{: #v3-7-4}
|
||||
|
||||
### Bug Fixes
|
||||
{: #bug-fixes-v3-7-4}
|
||||
|
||||
- Security: fix `include` bypass of EntryFilter#filter symlink check ([#7224]({{ site.repository }}/issues/7224))
|
||||
|
||||
|
||||
## 3.7.3 / 2018-02-25
|
||||
{: #v3-7-3}
|
||||
|
||||
|
|
@ -318,6 +336,15 @@ note: This file is autogenerated. Edit /History.markdown instead.
|
|||
- Fix permalink icon markup in news-item layout ([#6639]({{ site.repository }}/issues/6639))
|
||||
|
||||
|
||||
## 3.6.3 / 2018-09-18
|
||||
{: #v3-6-3}
|
||||
|
||||
### Bug Fixes
|
||||
{: #bug-fixes-v3-6-3}
|
||||
|
||||
- 3.6.x: security: fix `include` bypass of `EntryFilter#filter` symlink check ([#7229]({{ site.repository }}/issues/7229))
|
||||
|
||||
|
||||
## 3.6.2 / 2017-10-21
|
||||
{: #v3-6-2}
|
||||
|
||||
|
|
|
|||
|
|
@ -127,7 +127,7 @@ The result is the original HTML code shown earlier.
|
|||
|
||||
To safeguard situations where users don't supply a value for the parameter, you can use [Liquid's default filter](https://shopify.github.io/liquid/filters/default/).
|
||||
|
||||
Overall, you can create includes that act as templates for a variety of uses — inserting audio or video clips, alerts, special formatting, and more. However, note that you should avoid using too many includes, as this will slow down the build time of your site. For example, don't use includes every time you insert an image. (The above technique shows a use case for special images.)
|
||||
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
|
||||
|
||||
|
|
|
|||
|
|
@ -17,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:
|
||||
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ Pages are the most basic building block for content. They're useful for standalo
|
|||
content (content which is not date based or is not a group of content such as staff
|
||||
members or recipes).
|
||||
|
||||
The simplest way of adding a page is just to add an HTML file in the root
|
||||
The simplest way of adding a page is to add an HTML file in the root
|
||||
directory with a suitable filename. You can also write a page in Markdown using
|
||||
a `.md` extension which converts to HTML on build. For a site with
|
||||
a homepage, an about page, and a contact page, here’s what the root directory
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ title: Filters
|
|||
permalink: /docs/plugins/filters/
|
||||
---
|
||||
|
||||
Filters are simply modules that export their methods to liquid.
|
||||
Filters are modules that export their methods to liquid.
|
||||
All methods will have to take at least one parameter which represents the input
|
||||
of the filter. The return value will be the output of the filter.
|
||||
|
||||
|
|
|
|||
|
|
@ -21,8 +21,8 @@ end
|
|||
|
||||
Jekyll provides hooks for <code>:site</code>, <code>:pages</code>,
|
||||
<code>:posts</code>, and <code>:documents</code>. In all cases, Jekyll calls
|
||||
your hooks with the container object as the first callback parameter. However,
|
||||
all `:pre_render` hooks and the`:site, :post_render` hook will also provide a
|
||||
your hooks with the container object as the first callback parameter.
|
||||
All `:pre_render` hooks and the`:site, :post_render` hook will also provide a
|
||||
payload hash as a second parameter. In the case of `:pre_render`, the payload
|
||||
gives you full control over the variables that are available while rendering.
|
||||
In the case of `:site, :post_render`, the payload contains final values after
|
||||
|
|
|
|||
|
|
@ -41,7 +41,7 @@ You have 3 options for installing plugins:
|
|||
<h5>Plugins on GitHub Pages</h5>
|
||||
<p>
|
||||
<a href="https://pages.github.com/">GitHub Pages</a> is powered by Jekyll.
|
||||
However, all Pages sites are generated using the <code>--safe</code> option
|
||||
All Pages sites are generated using the <code>--safe</code> option
|
||||
to disable plugins (with the exception of some
|
||||
<a href="https://pages.github.com/versions">whitelisted plugins</a>) for
|
||||
security reasons. Unfortunately, this means
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ provides everything you need to turn it into a blog.
|
|||
## The Posts Folder
|
||||
|
||||
The `_posts` folder is where your blog posts live. You typically write posts
|
||||
in [Markdown](https://daringfireball.net/projects/markdown/), however HTML is
|
||||
in [Markdown](https://daringfireball.net/projects/markdown/), HTML is
|
||||
also supported.
|
||||
|
||||
## Creating Posts
|
||||
|
|
@ -97,9 +97,9 @@ Linking to a PDF for readers to download:
|
|||
|
||||
## Displaying an index of posts
|
||||
|
||||
Creating an index of posts on another page is easy thanks to
|
||||
Creating an index of posts on another page should be easy thanks to
|
||||
[Liquid](https://docs.shopify.com/themes/liquid/basics) and its tags. Here’s a
|
||||
basic example of how to create a list of links to your blog posts:
|
||||
simple example of how to create a list of links to your blog posts:
|
||||
|
||||
{% raw %}
|
||||
```html
|
||||
|
|
@ -162,7 +162,7 @@ For tags it's exactly the same except the variable is `site.tags`.
|
|||
## Post excerpts
|
||||
|
||||
You can access a snippet of a posts's content by using `excerpt` variable on a
|
||||
post. By default this is the first paragraph of content in the post however it
|
||||
post. By default this is the first paragraph of content in the post, however it
|
||||
can be customized by setting a `excerpt_separator` variable in front matter or
|
||||
`_config.yml`.
|
||||
|
||||
|
|
@ -204,7 +204,7 @@ create a `_drafts` folder in your site's root and create your first draft:
|
|||
| |-- a-draft-post.md
|
||||
```
|
||||
|
||||
To preview your site with drafts, simply run `jekyll serve` or `jekyll build`
|
||||
To preview your site with drafts, run `jekyll serve` or `jekyll build`
|
||||
with the `--drafts` switch. Each will be assigned the value modification time
|
||||
of the draft file for its date, and thus you will see currently edited drafts
|
||||
as the latest posts.
|
||||
|
|
|
|||
|
|
@ -62,7 +62,7 @@ following metadata:
|
|||
</table>
|
||||
</div>
|
||||
|
||||
Note that in the above table, `file` can be anything. It's simply an arbitrarily set variable used in your own logic (such as in a for loop). It isn't a global site or page variable.
|
||||
Note that in the above table, `file` can be anything. It's an arbitrarily set variable used in your own logic (such as in a for loop). It isn't a global site or page variable.
|
||||
|
||||
## Add front matter to static files
|
||||
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ title: Blogging
|
|||
position: 8
|
||||
---
|
||||
You might be wondering how you can have a blog without a database. In true
|
||||
Jekyll style, blogging is powered by text files and is easy to set up.
|
||||
Jekyll style, blogging is powered by text files only.
|
||||
|
||||
## Posts
|
||||
|
||||
|
|
|
|||
|
|
@ -15,3 +15,10 @@ If you're looking for support for Jekyll, there are a lot of options:
|
|||
* 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).
|
||||
|
||||
Happy Jekyllin'!
|
||||
|
|
|
|||
|
|
@ -25,7 +25,7 @@ In the case of Minima, you see only the following files in your Jekyll site dire
|
|||
|
||||
The `Gemfile` and `Gemfile.lock` files are used by Bundler to keep track of the required gems and gem versions you need to build your Jekyll site.
|
||||
|
||||
Gem-based themes make it easy for theme developers to make updates available to anyone who has the theme gem. When there's an update, theme developers push the update to RubyGems.
|
||||
Gem-based themes make it easier for theme developers to make updates available to anyone who has the theme gem. When there's an update, theme developers push the update to RubyGems.
|
||||
|
||||
If you have the theme gem, you can (if you desire) run `bundle update` to update all gems in your project. Or you can run `bundle update <THEME>`, replacing `<THEME>` with the theme name, such as `minima`, to just update the theme gem. Any new files or updates the theme developer has made (such as to stylesheets or includes) will be pulled into your project automatically.
|
||||
|
||||
|
|
@ -149,7 +149,7 @@ end
|
|||
|
||||
Either way, don't forget to `bundle update`.
|
||||
|
||||
However, if you're publishing on GitHub Pages you should update only your `_config.yml` as GitHub Pages doesn't load plugins via Bundler.
|
||||
If you're publishing on GitHub Pages you should update only your `_config.yml` as GitHub Pages doesn't load plugins via Bundler.
|
||||
|
||||
Finally, remove references to the theme gem in `Gemfile` and configuration. For example, to remove `minima`:
|
||||
|
||||
|
|
@ -208,7 +208,7 @@ If you're publishing your Jekyll site on [GitHub Pages](https://pages.github.com
|
|||
|
||||
## Creating a gem-based theme
|
||||
|
||||
If you're a Jekyll theme developer (rather than just a consumer of themes), you can package up your theme in RubyGems and allow users to install it through Bundler.
|
||||
If you're a Jekyll theme developer (rather than a consumer of themes), you can package up your theme in RubyGems and allow users to install it through Bundler.
|
||||
|
||||
If you're unfamiliar with creating Ruby gems, don't worry. Jekyll will help you scaffold a new theme with the `new-theme` command. Run `jekyll new-theme` with the theme name as an argument.
|
||||
|
||||
|
|
|
|||
|
|
@ -30,7 +30,7 @@ On Red Hat, CentOS, and Fedora systems you can do this by running:
|
|||
sudo yum install ruby-devel
|
||||
```
|
||||
|
||||
If you installed the above - specifically on Fedora 23 - but the extensions would still not compile, you are probably running a Fedora image that misses the `redhat-rpm-config` package. To solve this, simply run:
|
||||
If you installed the above - specifically on Fedora 23 - but the extensions would still not compile, you are probably running a Fedora image that misses the `redhat-rpm-config` package. To solve this, run:
|
||||
|
||||
```sh
|
||||
sudo dnf install redhat-rpm-config
|
||||
|
|
@ -152,9 +152,9 @@ Password:
|
|||
Once this is done, the `jekyll new` command should work properly for
|
||||
your user account.
|
||||
|
||||
### Jekyll & Mac OS X 10.11
|
||||
### Jekyll & macOS
|
||||
|
||||
With the introduction of System Integrity Protection, several directories
|
||||
With the introduction of System Integrity Protection in v10.11, several directories
|
||||
that were previously writable are now considered system locations and are no
|
||||
longer available. Given these changes, there are a couple of simple ways to get
|
||||
up and running. One option is to change the location where the gem will be
|
||||
|
|
@ -171,7 +171,7 @@ done as follows:
|
|||
ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
|
||||
```
|
||||
|
||||
Once Homebrew is installed, the second step is easy:
|
||||
Once Homebrew is installed, the second step is to run:
|
||||
|
||||
```sh
|
||||
brew install ruby
|
||||
|
|
@ -260,12 +260,12 @@ specified elsewhere.
|
|||
does not have a valid date in front matter.
|
||||
```
|
||||
|
||||
Simply adding `vendor/bundle` to the `exclude:` list will solve this problem but will lead to having other sub-directories under `/vendor/` (and also `/node_modules/`, if present) be processed to the destination folder `_site`.
|
||||
Adding `vendor/bundle` to the `exclude:` list will solve this problem but will lead to having other sub-directories under `/vendor/` (and also `/node_modules/`, if present) be processed to the destination folder `_site`.
|
||||
|
||||
|
||||
The proper solution is to incorporate the default setting for `exclude:` rather than override it completely:
|
||||
|
||||
For versions upto `v3.4.3`, the `exclude:` setting must look like following:
|
||||
For versions up to `v3.4.3`, the `exclude:` setting must look like following:
|
||||
|
||||
```yaml
|
||||
exclude:
|
||||
|
|
@ -279,7 +279,7 @@ exclude:
|
|||
- any_additional_item # any user-specific listing goes at the end
|
||||
```
|
||||
|
||||
From `v3.5` onward, `Gemfile` and `Gemfile.lock` are also excluded by default. So, in most cases there is no need to define another `exclude:` array in the config file. So an existing definition can either be modified as above, or removed completely, or simply commented out to enable easy edits in future.
|
||||
From `v3.5` onward, `Gemfile` and `Gemfile.lock` are also excluded by default. So, in most cases there is no need to define another `exclude:` array in the config file. So an existing definition can either be modified as above, or removed completely, or commented out to enable easy edits in future.
|
||||
|
||||
|
||||
## Markup Problems
|
||||
|
|
|
|||
|
|
@ -53,9 +53,9 @@ relative permalinks. Relative permalink backwards-compatibility was removed in v
|
|||
### Draft Posts
|
||||
|
||||
Jekyll now lets you write draft posts, and allows you to easily preview how
|
||||
they will look prior to publishing. To start a draft, simply create a folder
|
||||
they will look prior to publishing. To start a draft, create a folder
|
||||
called `_drafts` in your site's source directory (e.g., alongside `_posts`),
|
||||
and add a new markdown file to it. To preview your new post, simply run the
|
||||
and add a new markdown file to it. To preview your new post, run the
|
||||
`jekyll serve` command with the `--drafts` flag.
|
||||
|
||||
<div class="note info">
|
||||
|
|
@ -72,7 +72,7 @@ and add a new markdown file to it. To preview your new post, simply run the
|
|||
Rather than passing individual flags via the command line, you can now pass
|
||||
an entire custom Jekyll config file. This helps to distinguish between
|
||||
environments, or lets you programmatically override user-specified
|
||||
defaults. Simply add the `--config` flag to the `jekyll` command, followed
|
||||
defaults. Add the `--config` flag to the `jekyll` command, followed
|
||||
by the path to one or more config files (comma-delimited, no spaces).
|
||||
|
||||
#### As a result, the following command line flags are now deprecated:
|
||||
|
|
@ -119,7 +119,7 @@ Often, you'll want the ability to run a Jekyll site in multiple places,
|
|||
such as previewing locally before pushing to GitHub Pages. Jekyll 1.0 makes
|
||||
that easier with the new `--baseurl` flag. To take advantage of this
|
||||
feature, first add the production `baseurl` to your site's `_config.yml`
|
||||
file. Then, throughout the site, simply prefix relative URLs
|
||||
file. Then, throughout the site, prefix relative URLs
|
||||
with `{% raw %}{{ site.baseurl }}{% endraw %}`.
|
||||
When you're ready to preview your site locally, pass along the `--baseurl`
|
||||
flag with your local baseurl (most likely `/`) to `jekyll serve` and Jekyll
|
||||
|
|
|
|||
Loading…
Reference in New Issue