First, update your _config.yml and set future to false. By doing this, jekyll will not publish any post with future date.

future: false

Setup a cronjob to check and rebuild the site if there’re posts to be published. Since I already setup a hook on post-receive (trigger on receving a git push) to rebuild the site, I’m going to set a cronjob to execute this script instead of writing something new. The content of the post-receive looks like this.

# post-receive
#!/bin/bash -l
GIT_REPO=$HOME/repos/myblog.git
TMP_GIT_CLONE=$HOME/tmp/git/myblog
PUBLIC_WWW=/var/www/myblog

git clone $GIT_REPO $TMP_GIT_CLONE
jekyll build --source $TMP_GIT_CLONE --destination $PUBLIC_WWW
rm -Rf $TMP_GIT_CLONE
exit

Cronjob that execute post-receive every hour at 0 minute, everyday.

@hourly /path/to/my/post-receive

The only downside of this is you need to be able to setup cronjob. GitHub Pages and shared hostings are probably not going to work in this case. You will need to verify this yourself.

I find this the easiest way to install Discourse on OS X for local development purpose. The idea is this: you install Ubuntu as a VM and setup Discourse on top of that.

Install Vagrant

Setup Vagrant is as easy as double click the installer and a couple of next click. I have a license for Parallels 9 so I use Parallels as default provider. You can use VMWare if you own one or VirtualBox for free if you don’t feel like paying.

I use puphpet’s Ubuntu 14.04 x64 as base box but literally, anything Ubuntu 14.04 would work. Ubuntu 14.04 is recommended version by Discourse.

You can use PuPHPet online GUI configurator to create a configuration of your own.

vagrant plugin install vagrant-parallels
mkdir discourse-local
cd discourse-local
vagrant init puphpet/ubuntu1404-x64
vagrant up --provider=parallels
vagrant ssh

Install Discourse with Docker

Follow this tutorial on Discourse Meta to setup Discourse on your Vagrant box.

Discourse should be up and running on your Vagrant box’s IP address after this.

I did a quick search for full-text search solutions for jekyll (or any static websites). A notable fews have come up in search result:

• jekyll-lunr-js-search

• index_tank

• tapir

lunr-js-search

A quick look at the plugin’s dependency, I give up right away even though I only need that on search page. For the very same reason I opted for jekyll - a static site generator, I want my site to load as fast as possible. Adding a bunch of dependencies like that is against the purpose. I rather go for DuckDuckGo as I’m currently doing.

Dependencies for the jQuery plugin are as follows.

• jQuery
• lunr.js
• Mustache.js
• date.format.js
• URI.js

index_tank

Too bad the service is no longer available.

tapir

The most decent service I found so far. You sign up, add your feed URL so that the service can start indexing your website, add jQuery and tapir.js and you’re good to go.

Search API:

api/1/search.json?token=******&query=*****
/api/1/search.json?token=******&query=*****&callback=myCallback

tapir.js looks like a pretty short and simple js file. Adding jQuery dependency on it, is totally overkill.

Exercise for next week: I’m going to replace DuckDuckGo search with Tapir’s search in a few days once I’m done converting Tapir’s jQuery plugin to a pure js solution.

We’re on track to roll out SSL for all CloudFlare customers by mid-October. When we do, the number of sites that support HTTPS on the Internet will more than double. That they’ll also rank a bit higher is pretty cool too.

CloudFlare is the coolest free CDN option out there. They responds so quick to the new Google’s HTTPS as a ranking signal.

Content is the king but making the site a bit more SEO-friendly (or should I say Google-friendly?) doesn’t hurt.

Load speed

Relevant link: Optimize the hell out of your website for PageSpeed.

Sitemap

Help Google’s bots crawl your site better. jekyll provides it as a plugin.

Structure data markup

Use Google’s structure data markup helper to generate structure data markup code. Use structure data testing tool to verify it afterward.

SSL

Google recently announced that they are taking HTTPS as a ranking signal. StartSSL offers free SSL that is included in root SSL of most major browers. CloudFlare is also going to offer free-SSL to all customers (mid-October). I’m going to wait for CloudFlare a bit since I’m already using CloudFlare for this blog.

Jekyll plugin directory Wiki

I believe blogging help me learn better. In order to write about a subject, first I have to understand it throughly. Blogging is a way to documentating all your thought, your understanding into words.

Many people I talked with afraid of being wrong on the Internet. Don’t be. I do it all the time. I learnt a lot from the feedbacks.

If the feedback is right, you then learn something new, which is great. That’s the whole point, right!

If you’re wrong, please don’t get offended. A feedback could be wrong but it will also help you understand the subject better and get better at defending your view. Either way, it helps.

Actually, being wrong may actually speed up the learning process.

“The best way to get the right answer on the Internet is not to ask a question, it’s to post the wrong answer.”

– Cunningham’s Law

You will be surprised at number of people can’t wait to prove you wrong.

I was wondering if anyone has created one like this before and stumbled across this issue on octopress repo. imathis came up with this proposition for paginated post.

• The primary page would be the standard post url.

• Successive pages would be at post-url/2/index.html, etc.

• The atom feed will still show the full un-broken post.

• A unified post will live at post-url/all/index.html containing a print-friendly, un-broken version of the post.

• Pagination at the bottom will like to each page followed by a link to post-url/all/.

• Posts will have paginate: true in their YAML header to enable this feature.

• Posts will be broken up by html comments like <!--page-->.

• The un-broken post will add visual page divisions, probably an <hr>.

• There will be a way to direct read-later services (like Instapaper) to the un-broken post page.

I don’t actually need this plugin as my posts are mostly short posts but I will take this as a fun exercise over this weekend or next. The plugin will be available on GitHub later.

jekyll documentation is actually a very good source if you want to learn about writing a jekyll plugin. I highly recommend you to read that first. There are many examples at the end of the page as well.

Jekyll has a plugin system with hooks that allow you to create custom generated content specific to your site. You can run custom code for your site without having to modify the Jekyll source itself.

In general, plugins you make will fall into one of three categories:

• Generators
• Converters
• Tags and liquid filters

We shall try with liquid filter first today, which is the easiest one IMO. In this tutorial, we will create a plugin that convert [x] and [] into emoji icon checkbox.

Filters are simply 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.

Create a file named Checked.rb in your _plugins folder with content as below.

module Jekyll
  module Checked
    def checked(text)
      text.sub(%r{\[x\]}i, '<span class="ballot_box_with_check"></span>').sub(%r{\[\]}i, '<span class="ballot_box"></span>')
    end
  end
end

Liquid::Template.register_filter(Jekyll::Checked)

We just created a module with a method that take a string as param and replace [x] and [] with a span tag with respective class.

We will then apply this filter on post content (or anything you want to apply this filter on).

{% content | checked %}

In your css file:

.ballot_box_with_check:before {
  content: "\2611\ ";
}

.ballot_box:before {
  content: "\2610\ ";
}

The result looks something like this

And there you have it: your very first jekyll plugin. Be sure to check back for more jekyll tutorials :) .

Very cool idea by @randymorris. Basically, actual source will now live in the source branch and generated content (_site folder) will be in master instead.

1. Make changes in the source branch
2. Build and test the site locally
3. Commit changes to source branch
4. git publish-website which consists of the following steps

git branch -D master
git checkout -b master
git filter-branch --subdirectory-filter _site/ -f
git checkout source
git push --all origin

This is actually similar to the approach: develope locally and rsync _site folder with your VPS/host public folder but works with GitHub Pages.