start pulling in docs from wiki

_includes/docs_contents.html

@@ -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>
+      <li class="{% if page.title == "Blog migrations" %}current{% endif %}">
+        <a href="{{ site.url }}/docs/migrations">Blog migrations</a>
+      </li>
     </ul>
     <h4>Customization</h4>
     <ul>
@@ -47,8 +50,8 @@ <h4>Deployment</h4>
       <li class="{% if page.title == "Heroku" %}current{% endif %}">
         <a href="{{ site.url }}/docs/heroku">Heroku</a>
       </li>
-      <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>
       </li>
     </ul>
     <h4>Miscellaneous</h4>

_posts/2012-07-19-configuration.md

@@ -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** — 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
+
+maruku:
+  use_tex:    false
+  use_divs:   false
+  png_engine: blahtex
+  png_dir:    images/latex
+  png_url:    /images/latex
+
+rdiscount:
+  extensions: []
+
+kramdown:
+  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 %}

_posts/2012-07-19-contributing.md

@@ -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](http://github.com/thoughtbot/shoulda/tree/master) and
+    [RR](http://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 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
+installed:
+
+    $ [sudo] gem install shoulda redgreen rr rdiscount kramdown maruku RedCloth cucumber liquid
+
+You’ll also need [Pygments](http://pygments.org/) installed to run the
+features.\
+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
+
+Workflow
+--------
+
+Here’s the most direct way to get your work merged into the project:\
+\# Fork the project\
+\# Clone down your fork (
+`git clone git://github.com/<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
+errors\
+\# Push the branch up ( `git push origin my_awesome_feature` )\
+\# Create an issue with a description and link to your branch
+
+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
+    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.
+
+Finally…
+--------
+
+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.
+

_posts/2012-07-19-heroku.md

@@ -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.

_posts/2012-07-19-manual-deployment.md

@@ -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
+this](http://web.archive.org/web/20091223025644/http://www.taknado.com/en/2009/03/26/deploying-a-jekyll-generated-site/).
+
+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
+then:
+
+{% highlight bash %}
+laptop$ ssh deployer@myserver.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 %}
+
+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
+    rm -Rf $TMP_GIT_CLONE
+    exit
+    </code>
+
+Finally do the following on any users laptop that needs to be able to
+deploy
+
+    <code>laptops$ git remote add deploy deployer@myserver.com:~/myrepo.git</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>
+
+BOOM!
+
+Rake
+----
+
+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](https://github.com/gitready/gitready/blob/en/Rakefile).
+
+rsync
+-----
+
+Just generate the `_site` and rsync it, e.g. with a `tasks/deploy`
+[shell
+script](http://github.com/henrik/henrik.nyh.se/blob/master/tasks/deploy).
+
+There’s even [a TextMate command](http://gist.github.com/214959) to run
+this script.
+
+ftp
+---
+
+As sometimes you don’t have anything else than FTP to deploy your site
+(not dedicated hosting), with [glynn](http://github.com/dmathieu/glynn),
+you can easily generate your jekyll powered website’s static files and
+send them to your host through ftp.
+
+Rack-Jekyll
+-----------
+
+Easy way to deploy your site on any server (EC2, Slicehost, Heroku, etc)
+with [rack-jekyll](http://github.com/bry4n/rack-jekyll/). It also can
+run with [shotgun](http://github.com/rtomakyo/shotgun/) ,
+[rackup](http://github.com/rack/rack) ,
+[mongrel](http://github.com/mongrel/mongrel),
+[unicorn](http://github.com/defunkt/unicorn/) , and more…
+
+See rack-jekyll’s [README](http://github.com/bry4n/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
+
+Jekyll-Admin for Rails
+----------------------
+
+If you want to maintain Jekyll inside your existing Rails app,
+[Jekyll-Admin](http://github.com/zkarpinski/Jekyll-Admin) contains drop
+in code to make this possible. See Jekyll-Admin’s
+[README](http://github.com/zkarpinski/Jekyll-Admin/blob/master/README)
+
+Amazon S3
+---------
+
+If you want to host your site in Amazon S3, you can do so with
+[jekyll-s3](https://github.com/versapay/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.