Reading Time Estimator, Flat File Data, Github-Friendly Tags and More
It’s been about a year since I first tinkered with Jekyll, but only in the last few months that I built a couple sites in it and got familiar with its kinks and a few cool techniques, which I wanted to collect and share.
Reading Time Estimator
Wouldn’t it be cool to have a reading time estimate like they have on Medium, on your little Jekyll blog? I thought so. Turns out it’s ridiculously easy to do, with the built-in word counter filter used by Jekyll’s templating engine, Liquid.
Drop the following into your post template, wherever you’d like it – say between the post title and page content.
<!-- drop this into your post.html or other page template -->
<div id="reading-time"></div>
<span id="wordcount" style="display:none">{{ content | number_of_words }}</span>
view rawjekyll-reading-time-template.html hosted with ❤ by GitHub
Then drop this into a JavaScript file getting loaded into your site:
// reading time
$('#reading-time').html(function(){
var wordcount = $('#wordcount').text();
timetoread = Math.round(wordcount / 200);
readmessage = timetoread + " min read";
return readmessage;
});
view rawjekyll-reading-time.js hosted with ❤ by GitHub
And you’re done!
The script assumes that you read at 200 words per minute, which of course not everyone does. This is probably a conservative estimate.
Tags on Github Pages
So you want to host your site for free on Github Pages, which means no plugins. But you also want tags. How do you do this? By pushing the Liquid templating engine and Jekyll’s flat-file data abilities.
This resourceful hack is documented here on Minddust (follow the link for the code).
It’s not the cleanest, and it relies on the kind of template logic you’re probably trying to get away from if you’re say, coming to web frameworks and Jekyll from PHP. The manual configuration is annoying, but it kind of forces you to think carefully about tags and avoid tag bloat. I didn’t really care, it’s a way to get tags working and dodge the no-plugins limitation on Github Pages.
Drafts and Unpublishing
Jekyll has a _drafts folder which you can use for works in progress. This is nice to have, but I usually prefer to keep things simple by having drafts in the _posts folder and just editing the file’s metadata. Maybe it’s just me, but the presence of the drafts folder made me think at first I needed to put drafts there. Let me spare you – you don’t.
You just need to have a line in your post metadata for setting the value of published to true or false. Like so:
--- layout: post published: true title: Jekyll Hacks subheading: Reading Time Estimator, Flat File Data, Github-Friendly Tags and More ---
Fun With Data Files
One of the coolest things about Jekyll and its flat-file magic is the ability to very quickly create and output data. Just drop a cleanly formatted YAML, JSON or even a CSV file in the _data folder, and you’re ready to go – your data is waiting for you in site.data to output into templates.
Say you wanted to have a page with a list of links you maintained, but do it without manually editing HTML every time.
You could create a file in the _data folder called links.yml and start with something like this:
- name: hexual url: http://hexu.al about: Visual browser for words that make hex codes - name: Frameless Grid url: http://framelessgrid.com about: Concept for an adaptive grid system
Then, you can go right into using that data in a template. The site.data template variable holds everything in the _data folder, using dot notation and the filename – so with links.yml our data is in site.data.links. In the root directory, a file called links.html could get this thrown in it:
---
layout: default
title: Links
published: true
---
<div class="links container">
<ul>
{% for link in site.data.links %}
<li>
<a href="{{ link.url }}">
{{ link.name }}
</a>
<br>
<span>{{ link.about }}</span>
</li>
{% endfor %}
</ul>
</div>
Like with a NoSQL data store, there’s no schema to worry about, no migrations, so you can add, remove and edit this data freely. Of course, it has its limitations too. If you wanted to add a notes field and create and output notes about your links, it wouldn’t be very convenient to edit all that in a big yaml file. Then again, you could also nest data files in directories as a solution for keeping things organized, as covered on Jekyll’s doc page about working with data files.
One of the interesting possibilities is that you might want to just use Jekyll for this purpose primarily – say, as a lightweight generator for a microsite based on displaying information that came from somewhere else, with CSS and JavaScript to spice things up.
A bunch of CSV files of public city data, for example. Or cool stuff you have for some reason sitting locked up in Excel files – export to CSV, then throw in Jekyll’s _data folder.
It’s really wide open for experimentation since it’s incredibly fast and flexible to get up and running. Jekyll is a “text transformation engine” – and for anything where your needs stop short of a database, it’s quite the swiss army knife.
