Browse files

start pulling in docs from wiki

  • Loading branch information...
1 parent 967092a commit f3ffd137414e6f3d2d2b42869b7a08c87775dc89 @cobyism committed Jul 25, 2012
@@ -26,6 +26,9 @@ <h4>Basic Usage</h4>
<li class="{% if page.title == "Creating pages" %}current{% endif %}">
<a href="{{ site.url }}/docs/pages">Creating pages</a>
+ <li class="{% if page.title == "Blog migrations" %}current{% endif %}">
+ <a href="{{ site.url }}/docs/migrations">Blog migrations</a>
+ </li>
@@ -47,8 +50,8 @@ <h4>Deployment</h4>
<li class="{% if page.title == "Heroku" %}current{% endif %}">
<a href="{{ site.url }}/docs/heroku">Heroku</a>
- <li class="{% if page.title == "Manual (FTP)" %}current{% endif %}">
- <a href="{{ site.url }}/docs/manual">Manual (FTP)</a>
+ <li class="{% if page.title == "Manual deployment" %}current{% endif %}">
+ <a href="{{ site.url }}/docs/manual-deployment">Manual</a>
@@ -5,4 +5,69 @@ prev_section: structure
next_section: frontmatter
-Move along, people. Nothing to see here.
+Jekyll allows you to concoct your sites in any way you can dream up. The
+following is a list of the currently supported configuration options.
+These can all be specified by creating a `_config.yml` file in your
+site’s root directory. There are also flags for the `jekyll` executable
+which are described below next to their respective configuration
+options. The order of precedence for conflicting settings is this:
+1. Command-line flags
+2. Configuration file settings
+3. Defaults
+## Configuration Settings
+**Setting** **Config** **Flag** **Description**
+Default Configuration
+**Note** &mdash; You cannot use tabs in configuration files. This will
+either lead to parsing errors, or Jekyll will use the default settings.
+{% highlight yaml %}
+safe: false
+auto: false
+server: false
+server_port: 4000
+baseurl: /
+url: http://localhost:4000
+source: .
+destination: ./_site
+plugins: ./_plugins
+future: true
+lsi: false
+pygments: false
+markdown: maruku
+permalink: date
+ use_tex: false
+ use_divs: false
+ png_engine: blahtex
+ png_dir: images/latex
+ png_url: /images/latex
+ extensions: []
+ auto_ids: true,
+ footnote_nr: 1
+ entity_output: as_char
+ toc_levels: 1..6
+ use_coderay: false
+ coderay:
+ coderay_wrap: div
+ coderay_line_numbers: inline
+ coderay_line_numbers_start: 1
+ coderay_tab_width: 4
+ coderay_bold_every: 10
+ coderay_css: style
+{% endhighlight %}
@@ -1,8 +1,78 @@
layout: docs
title: Contributing
-prev_section: manual
+prev_section: manual-deployment
next_section: issues
-Move along, people. Nothing to see here.
+So you’ve got an awesome idea to throw into Jekyll. Great! Please keep
+the following in mind:
+- **Contributions will not be accepted without tests.**
+- 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]( and
+ [RR](
+- If it’s a brand new feature, make sure to create a new
+ [Cucumber]( feature and reuse
+ steps where appropriate. Also, whipping up some documentation in
+ your fork’s wiki would be appreciated, and once merged it will be
+ transferred over to the main wiki.
+Test Dependencies
+To run the test suite and build the gem you’ll need the following gems
+ $ [sudo] gem install shoulda redgreen rr rdiscount kramdown maruku RedCloth cucumber liquid
+You’ll also need [Pygments]( installed to run the
+You’ll also need “RedCarpet”, but not the latest version (2.x), because
+it is not compatible\
+ $ [sudo] gem install redcarpet ==--==version=1.17.2
+Before you start, run the tests and make sure that they pass (to confirm
+your environment is configured properly):
+ $ rake test
+ $ rake features
+Here’s the most direct way to get your work merged into the project:\
+\# Fork the project\
+\# Clone down your fork (
+`git clone git://<username>/jekyll.git` )\
+\# Create a topic branch to contain your change (
+`git checkout -b my_awesome_feature` )\
+\# Hack away, add tests. Not necessarily in that order.\
+\# Make sure everything still passes by running `rake`\
+\# If necessary, rebase your commits into logical chunks, without
+\# Push the branch up ( `git push origin my_awesome_feature` )\
+\# Create an issue with a description and link to your branch
+- 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
+ mojombo/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.
+Thanks! Hacking on Jekyll should be fun, and if for some reason it’s a
+pain to do let us know so we can fix it.
@@ -2,7 +2,7 @@
layout: docs
title: Heroku
prev_section: github-pages
-next_section: manual
+next_section: manual-deployment
Move along, people. Nothing to see here.
@@ -0,0 +1,120 @@
+layout: docs
+title: Manual deployment
+prev_section: heroku
+next_section: contributing
+Deploying Jekyll? No problem: Just copy the generated `_site` to
+somewhere that your favorite web server can serve it up. There’re also
+automated ways to do it, listed below. If you’ve created your own way,
+edit away!
+Post-update hook
+If you store your jekyll site in git, it’s pretty easy to automate the
+deployment process by setting up a post-update hook in your git
+repository, [like
+Post-receive hook
+This is where it’s at. You created a user account named deployer which
+has all the users public keys that are authorized to deploy in its
+\`authorized\_keys\` file right? Great, deploying Jekyll is this easy
+{% highlight bash %}
+laptop$ ssh
+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 %}
+Add the following lines to hooks/post-receive and be sure jekyll is
+installed on the server
+ <code>GIT_REPO=$HOME/myrepo.git
+ TMP_GIT_CLONE=$HOME/tmp/myrepo
+ PUBLIC_WWW=/var/www/myrepo
+ git clone $GIT_REPO $TMP_GIT_CLONE
+ jekyll --no-auto $TMP_GIT_CLONE $PUBLIC_WWW
+ exit
+ </code>
+Finally do the following on any users laptop that needs to be able to
+ <code>laptops$ git remote add deploy</code>
+Deploying is now as easy as telling nginx or apache to look at
+/var/www/myrepo and running the following:
+ <code>laptops$ git push deploy master</code>
+Another way to deploy your jekyll site is to use rake, highline, and
+net-ssh. A more complex example that deals with multiple branches used
+in [gitready](
+Just generate the `_site` and rsync it, e.g. with a `tasks/deploy`
+There’s even [a TextMate command]( to run
+this script.
+As sometimes you don’t have anything else than FTP to deploy your site
+(not dedicated hosting), with [glynn](,
+you can easily generate your jekyll powered website’s static files and
+send them to your host through ftp.
+Easy way to deploy your site on any server (EC2, Slicehost, Heroku, etc)
+with [rack-jekyll]( It also can
+run with [shotgun]( ,
+[rackup]( ,
+[unicorn]( , and more…
+See rack-jekyll’s [README](
+Read [this
+on how to deploy to Heroku
+Jekyll-Admin for Rails
+If you want to maintain Jekyll inside your existing Rails app,
+[Jekyll-Admin]( contains drop
+in code to make this possible. See Jekyll-Admin’s
+Amazon S3
+If you want to host your site in Amazon S3, you can do so with
+[jekyll-s3]( 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.
@@ -1,8 +0,0 @@
-layout: docs
-title: Manual (FTP)
-prev_section: heroku
-next_section: contributing
-Move along, people. Nothing to see here.
Oops, something went wrong.

0 comments on commit f3ffd13

Please sign in to comment.