jekyll 2.2.0 → 2.3.0

data/site/docs/continuous-integration.md

@@ -1,177 +0,0 @@
----
-layout: docs
-title: Continuous Integration
-prev_section: deployment-methods
-next_section: troubleshooting
-permalink: /docs/continuous-integration/
----
-
-You can easily 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][0], with [GitHub][1] integration for pull requests. Paid
-alternatives exist for private repositories.
-
-[0]: https://travis-ci.org/
-[1]: https://github.com/
-
-## 1. Enabling Travis and GitHub
-
-Enabling Travis builds for your GitHub repository is pretty simple:
-
-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.
-3. Click the slider on the right so it says "ON" and is a dark grey.
-4. Optionally configure the build by clicking on the wrench icon. Further
-   configuration happens in you `.travis.yml` file. More details on that
-   below.
-
-## 2. The Test Script
-
-The simplest test script simply 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.
-
-When testing Jekyll output, there is no better tool than [html-proofer][2].
-This tool checks your resulting site to ensure all links and images exist.
-Utilize it either with the convenient `htmlproof` command-line executable,
-or write a Ruby script which utilizes the gem.
-
-### The HTML Proofer Executable
-
-{% highlight bash %}
-#!/usr/bin/env bash
-set -e # halt script on error
-
-bundle exec jekyll build
-bundle exec htmlproof ./_site
-{% endhighlight %}
-
-Some options can be specified via command-line switches. Check out the
-`html-proofer` README for more information about these switches, or run
-`htmlproof --help` locally.
-
-### The HTML Proofer Library
-
-You can also invoke `html-proofer` in Ruby scripts (e.g. in a Rakefile):
-
-{% highlight ruby %}
-#!/usr/bin/env ruby
-
-require 'html/proofer'
-HTML::Proofer.new("./_site").run
-{% endhighlight %}
-
-Options are given as a second argument to `.new`, and are encoded in a
-symbol-keyed Ruby Hash. More information about the configuration options,
-check out `html-proofer`'s README file.
-
-[2]: https://github.com/gjtorikian/html-proofer
-
-## 3. Configuring Your Travis Builds
-
-This file is used to configure your Travis builds. Because Jekyll is built
-with Ruby and requires RubyGems to install, we use the Ruby language build
-environment. Below is a sample `.travis.yml` file, and what follows that is
-an explanation of each line.
-
-{% highlight yaml %}
-language: ruby
-rvm:
-- 2.1
-script: ./script/cibuild
-
-# branch whitelist
-branches:
-  only:
-  - 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
-{% endhighlight %}
-
-Ok, now for an explanation of each line:
-
-{% highlight yaml %}
-language: ruby
-{% endhighlight %}
-
-This line tells Travis to use a Ruby build container. It gives your script
-access to Bundler, RubyGems, and and Ruby runtime.
-
-{% highlight yaml %}
-rvm:
-- 2.1
-{% endhighlight %}
-
-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.
-
-{% highlight yaml %}
-script: ./script/cibuild
-{% endhighlight %}
-
-Travis allows you to run any arbitrary shell script to test your site. One
-convention is to put all scripts for your project in the `script`
-directory, and to call your test script `cibuild`. This line is completely
-customizable. If your script won't change much, you can write your test
-incantation here directly:
-
-{% highlight yaml %}
-script: jekyll build && htmlproof ./_site
-{% endhighlight %}
-
-The `script` directive can be absolutely any valid shell command.
-
-{% highlight yaml %}
-# branch whitelist
-branches:
-  only:
-  - gh-pages     # test the gh-pages branch
-  - /pages-(.*)/ # test every branch which starts with "pages-"
-{% endhighlight %}
-
-You want to ensure the Travis builds for your site are being run only on
-the branch or branches which contain your site. One means of ensuring this
-isolation is including a branch whitelist in your Travis configuration
-file. By specifying the `gh-pages` branch, you will ensure the associated
-test script (discussed above) is only executed on site branches. If you use
-a pull request flow for proposing changes, you may wish to enforce a
-convention for your builds such that all branches containing edits are
-prefixed, exemplified above with the `/pages-(.*)/` regular expression.
-
-The `branches` directive is completely optional.
-
-{% highlight yaml %}
-env:
-  global:
-  - NOKOGIRI_USE_SYSTEM_LIBRARIES=true # speeds up installation of html-proofer
-{% endhighlight %}
-
-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 increase the install time of Nokogiri by setting the
-environment variable `NOKOGIRI_USE_SYSTEM_LIBRARIES` to `true`.
-
-## 4. Gotchas
-
-### Exclude `vendor`
-
-Travis bundles all gems in the `vendor` directory on its build servers,
-which Jekyll will mistakenly read and explode on. To avoid this, exclude
-`vendor` in your `_config.yml`:
-
-{% highlight yaml %}
-exclude: [vendor]
-{% endhighlight %}
-
-### Questions?
-
-This entire guide is open-source. Go ahead and [edit it][3] if you have a
-fix or [ask for help][4] if you run into trouble and need some help.
-
-[3]: https://github.com/jekyll/jekyll/edit/master/site/docs/continuous-integration.md
-[4]: https://github.com/jekyll/jekyll-help#how-do-i-ask-a-question

data/site/docs/contributing.md

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

data/site/docs/datafiles.md

@@ -1,108 +0,0 @@
----
-layout: docs
-title: Data Files
-prev_section: collections
-next_section: assets
-permalink: /docs/datafiles/
----
-
-In addition to the [built-in variables](../variables/) available from Jekyll,
-you can specify your own custom data that can be accessed via the [Liquid
-templating system](https://wiki.github.com/shopify/liquid/liquid-for-designers).
-
-Jekyll supports loading data from [YAML](http://yaml.org/) and [JSON](http://www.json.org/) files located in the
-`_data` directory.
-
-This powerful feature allows you to avoid repetition in your templates and to
-set site specific options without changing `_config.yml`.
-
-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 files (using either the `.yml`, `.yaml` or `.json`
-extension) and they will be accessible via `site.data`.
-
-## Example: List of members
-
-Here is a basic example of using Data Files to avoid copy-pasting large chunks of
-code in your Jekyll templates:
-
-In `_data/members.yml`:
-
-{% highlight yaml %}
-- name: Tom Preston-Werner
-  github: mojombo
-
-- name: Parker Moore
-  github: parkr
-
-- name: Liu Fengyun
-  github: liufengyun
-{% endhighlight %}
-
-This data can be accessed via `site.data.members` (notice that the filename
-determines the variable name).
-
-You can now render the list of members in a template:
-
-{% highlight html %}
-{% raw %}
-<ul>
-{% for member in site.data.members %}
-  <li>
-    <a href="https://github.com/{{ member.github }}">
-      {{ member.name }}
-    </a>
-  </li>
-{% endfor %}
-</ul>
-{% endraw %}
-{% endhighlight %}
-
-## Example: Organizations
-
-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 bellow shows how GitHub organizations could be defined separately in a file under the `orgs` folder:
-
-In `_data/orgs/jekyll.yml`:
-
-{% highlight yaml %}
-username: jekyll
-name: Jekyll
-members:
-  - name: Tom Preston-Werner
-    github: mojombo
-
-  - name: Parker Moore
-    github: parkr
-{% endhighlight %}
-
-In `_data/orgs/doeorg.yml`:
-
-{% highlight yaml %}
-username: doeorg
-name: Doe Org
-members:
-  - name: John Doe
-    github: jdoe
-{% endhighlight %}
-
-The organizations can then be accessed via `site.data.orgs`, followed by the file name:
-
-{% highlight html %}
-{% raw %}
-<ul>
-{% for org_hash in site.data.orgs %}
-{% assign org = org_hash[1] %}
-  <li>
-    <a href="https://github.com/{{ org.username }}">
-      {{ org.name }}
-    </a>
-    ({{ org.members | size }} members)
-  </li>
-{% endfor %}
-</ul>
-{% endraw %}
-{% endhighlight %}

data/site/docs/deployment-methods.md

@@ -1,127 +0,0 @@
----
-layout: docs
-title: Deployment methods
-prev_section: github-pages
-next_section: troubleshooting
-permalink: /docs/deployment-methods/
----
-
-Sites built using Jekyll can be deployed in a large number of ways due to the static nature of the generated output. A few of the most common deployment techniques are described below.
-
-## Web hosting providers (FTP)
-
-Just about any traditional web hosting provider will let you upload files to their servers over FTP. To upload a Jekyll site to a web host using FTP, simply run the `jekyll` command and copy 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.
-
-### FTP using Glynn
-
-There is a project called [Glynn](https://github.com/dmathieu/glynn), which lets you easily generate your Jekyll powered website’s static files and
-send them to your host through FTP.
-
-## Self-managed web server
-
-If you have direct access yourself to the deployment web server yourself, the process is essentially the same, except you might have other methods available to you (such as `scp`, or even direct filesystem access) for transferring the files. Just remember to make sure the contents of the generated `_site` folder get placed in the appropriate web root directory for your web server.
-
-## Automated methods
-
-There are also a number of ways to easily automate the deployment of a Jekyll site. If you’ve got another method that isn’t listed below, we’d love it if you [contributed](../contributing/) so that everyone else can benefit too.
-
-### Git post-update hook
-
-If you store your Jekyll site in [Git](http://git-scm.com/) (you are using version control, right?), it’s pretty easy to automate the
-deployment process by setting up a post-update hook in your Git
-repository, [like
-this](http://web.archive.org/web/20091223025644/http://www.taknado.com/en/2009/03/26/deploying-a-jekyll-generated-site/).
-
-### Git post-receive hook
-
-To have a remote server handle the deploy for you every time you push changes using Git, you can create a user account which has all the public keys that are authorized to deploy in its `authorized_keys` file. With that in place, setting up the post-receive hook is done as follows:
-
-{% highlight bash %}
-laptop$ ssh deployer@example.com
-server$ mkdir myrepo.git
-server$ cd myrepo.git
-server$ git --bare init
-server$ cp hooks/post-receive.sample hooks/post-receive
-server$ mkdir /var/www/myrepo
-{% endhighlight %}
-
-Next, add the following lines to hooks/post-receive and be sure Jekyll is
-installed on the server:
-
-{% highlight bash %}
-GIT_REPO=$HOME/myrepo.git
-TMP_GIT_CLONE=$HOME/tmp/myrepo
-PUBLIC_WWW=/var/www/myrepo
-
-git clone $GIT_REPO $TMP_GIT_CLONE
-jekyll build -s $TMP_GIT_CLONE -d $PUBLIC_WWW
-rm -Rf $TMP_GIT_CLONE
-exit
-{% endhighlight %}
-
-Finally, run the following command on any users laptop that needs to be able to
-deploy using this hook:
-
-{% highlight bash %}
-laptops$ git remote add deploy deployer@example.com:~/myrepo.git
-{% endhighlight %}
-
-Deploying is now as easy as telling nginx or Apache to look at
-`/var/www/myrepo` and running the following:
-
-{% highlight bash %}
-laptops$ git push deploy master
-{% endhighlight %}
-
-### Jekyll-hook
-
-You can also use jekyll-hook, a server that listens for webhook posts from
-GitHub, generates a website with Jekyll, and moves it somewhere to be
-published. Use this to run your own GitHub Pages-style web server.
-
-This method is useful if you need to serve your websites behind a firewall,
-need extra server-level features like HTTP basic authentication or want to
-host your site directly on a CDN or file host like S3.
-
-Setup steps are fully documented
-[in the `jekyll-hook` repo](https://github.com/developmentseed/jekyll-hook).
-
-### Rake
-
-Another way to deploy your Jekyll site is to use [Rake](https://github.com/jimweirich/rake), [HighLine](https://github.com/JEG2/highline), and
-[Net::SSH](https://github.com/net-ssh/net-ssh). A more complex example of deploying Jekyll with Rake that deals with multiple branches can be found in [Git Ready](https://github.com/gitready/gitready/blob/cdfbc4ec5321ff8d18c3ce936e9c749dbbc4f190/Rakefile).
-
-### rsync
-
-Once you’ve generated the `_site` directory, you can easily rsync it using a `tasks/deploy` shell script similar to [this deploy script here](https://github.com/henrik/henrik.nyh.se/blob/master/tasks/deploy). You’d obviously need to change the values to reflect your site’s details. There is even [a matching TextMate command](http://gist.github.com/214959) that will help you run
-this script from within Textmate.
-
-
-## Rack-Jekyll
-
-[Rack-Jekyll](https://github.com/adaoraul/rack-jekyll/) is an easy way to deploy your site on any Rack server such as Amazon EC2, Slicehost, Heroku, and so forth. It also can run with [shotgun](https://github.com/rtomayko/shotgun/), [rackup](https://github.com/rack/rack), [mongrel](https://github.com/mongrel/mongrel), [unicorn](https://github.com/defunkt/unicorn/), and [others](https://github.com/adaoraul/rack-jekyll#readme).
-
-Read [this post](http://blog.crowdint.com/2010/08/02/instant-blog-using-jekyll-and-heroku.html) on how to deploy to Heroku using Rack-Jekyll.
-
-## Jekyll-Admin for Rails
-
-If you want to maintain Jekyll inside your existing Rails app, [Jekyll-Admin](https://github.com/zkarpinski/Jekyll-Admin) contains drop in code to make this possible. See Jekyll-Admin’s [README](https://github.com/zkarpinski/Jekyll-Admin/blob/master/README) for more details.
-
-## Amazon S3
-
-If you want to host your site in Amazon S3, you can do so with
-[s3_website](https://github.com/laurilehmijoki/s3_website) application. It will
-push your site to Amazon S3 where it can be served like any web server,
-dynamically scaling to almost unlimited traffic. This approach has the
-benefit of being about the cheapest hosting option available for
-low-volume blogs as you only pay for what you use.
-
-## OpenShift
-
-If you'd like to deploy your site to an OpenShift gear, there's [a cartridge
-for that](https://github.com/openshift-cartridges/openshift-jekyll-cartridge).
-
-<div class="note">
-  <h5>ProTip™: Use GitHub Pages for zero-hassle Jekyll hosting</h5>
-  <p>GitHub Pages are powered by Jekyll behind the scenes, so if you’re looking for a zero-hassle, zero-cost solution, GitHub Pages are a great way to <a href="../github-pages/">host your Jekyll-powered website for free</a>.</p>
-</div>