Weird, @jekyllrb builds taking almost 2x/3x to build in v3.3 Testing another build/deploy now to confirm extended times.
Impressed with v1 of Jekyll Admin, a GUI for writing/editing posts locally. https://github.com/jekyll/jekyll-admin Looking forward to expansion of API
I’ve been following Manton Reece’s blog and his development of a microblogging service. The first thing that caught my attention was when he discussed supporting webmentions.
Today he outline he is building on top of Jekyll. One interesting thing is that he’s adding XML-RPC. Considering my recent advances in implementing micropub here, I guess I was secretly hoping that was something he was baking into his new platform and MarsEdit was going to add it. Maybe in the future. Regardless of the technology, I’m excited for another platform that gives people the opportunity to own their voice and step out of the feed lots of the corporate web.
Speaking of micropub and Jekyll, Pelle released his project today. It’s still in early development, and requires deploying to Heroku, but is what I’m using here. My goals now are to add support to my Jekyll-IndieWeb project and help document setting it up.
All in all, I’m bullish on Jekyll, and hope these advances and the addition of theme gems in 3.2 continue to broaden the appeal of the platform. Perhaps to the point I could find work developing and supporting it. But that is for another post.
I started a project soon after I began embracing the IndieWeb for the Jekyll platform, Jekyll IndieWeb (A less than inspiring project name I’m afraid to say.) My initial goals were to have a framework for myself that was fully microformats 2 compliant to build my own site off of and to share a starting point for anyone new to having their own website and wanting to embrace IndieWeb themselves.
So far I know of one person who is using it, which is encouragement enough to continue looking at ways to improve it. In the upcoming release of Jekyll, themes will be supported. While considered a minor enhancement, I think its a major milestone for Jekyll. Previously, there was no simple way to change the look and feel of your site without manually copying files into your install. Most theme projects are packaged as standalone Jekyll builds.
So that said, my plan moving forward to is to package the microformated theme, complete with the same config options as a Gem under the name “Crier” (as in town crier. Not sure it’s anymore imaginative than the original project.) The original GitHub project will switch to the Gem once the new version is released, but will stay as a standalone Jekyll install for anyone who wants to get started from scratch. Also, Tom began working implementing a webmention gem for sending while at IndieWeb Summit 2016. With the help of Bear in the IndieWeb community, I hope to have a tutorial and example of using continuous integration to build and deploy a site back to GitHub allowing the sending of webmentions along with the already supported receiving.
I would love to hear from anyone else interested in the project or using it, and what else you would like to see. Long term goal is micropub support.
One artifact of Jekyll that has bothered me is the redundant blank lines in the rendered HTML. In my case, I was seeing hundreds of blank lines creating the page navigation at the top of the page. It doesn’t affect what the visitor sees, but for developers who use Jekyll poor source is a bad practice. Also imagine someone new to Jekyll and HTML in general trying to view source to debug an issue. Turns out the problem is with the Liquid template language Jekyll uses. Seems the Liquid community have been discussing the issue for 3 years without a solution.
My first approach to solving this was to use a Ruby gem HTML Beautifier. It works great, but for a site like mine with over 500 posts with a lot of tag pages, it increases the build time exponentially. To the point I’ve seen Travis time out due to the long process. Today I went looking for another solution and stumbled upon this gist – remove empty lines. It concerned me the plugin would increase the build time in Jekyll vs in Travis, but was pleasantly surprised it added no noticeable overhead and produces much cleaner HTML output.
Now I get quick build times and cleaner source.
Figure for my own reference I should document the updates I’ve made to the site the last month.
I’ve written before that my primary goal with the reboot of this site is to embrace IndieWeb. The first step was receiving webmentions, then sending them. Also in the process I, started an indiewebified Jekyll theme (which I’m using on this site at the time of writing.) Part of that was to have better microformats in the markup.
The big itch that I wanted to scratch was implementing micropub to free myself from Twitter (something I’ve failed at thus far). With the help of Pelle Wessman who shared n bit of yet to be public “glue” to pull together his other tools, I set up my own micropub endpoint on a Heroku.1 I still need to workout adding a syndication endpoint for Twitter so I can auto-tweet notes, but that is coming.
Once that was in place, I was able to use the tools Aaron Perecki built, Quill and OwnYourGram. Quill is a web based micropub publishing app, and OwnYourGram is a service that helps you PESOS your Instagram photos to your own site2.
A lot of the experiments I’ve been doing here might be overkill for a simple blog, but are great ways to expose myself to new technologies. I’ve long had an Amazon Web Services s3 bucket set up as a CDN, but had never found a workflow to efficiently use it. With the my current build/deploy process with Travis, a copy of the Instagram photo is saved to my GitHub repository via micropub. In the build script, the image is copied to the s3 bucket, then linked to the CDN.
The primary reason to use the CDN was I went through the steps to get 100% on Google Pagespeed (last I checked). Since the site is primarily text and is already static it ranked pretty well, but I went ahead and configured loading critical CSS3. (I had set that up with my old Habari theme, but Google’s added a step to async load the remaining CSS). I also had to tweak caching in nginx, which while I was in there, I went ahead and set up http/2. The primary reason I moved back from GitHub pages to my VPS was to serve the site over https with a free LetsEncrypt SSL certificate.
Finally, I went back and forth on analytics. I don’t need them, but it’s nice to see what visitors are looking for and at. I poked around at some self hosted options, ultimately decided for now that for the people who don’t want to share data with Google, there are browser tools to block sending the data, which I’m OK with, therefore using GA here isn’t forcing anyone into it.
I still want to do a fresh design, but only after last few kinks in Jekyll-IndieWeb theme are fixed. I’ll still use the markup as the foundation, just present it differently. As always, if you have any questions, hit me on Twitter @miklb or leave a webmention and I’ll do my best to reply.
Until last night, I was under the impression you had to store all of your posts as markdown files in a single directory called
_posts unless you changed that in your
_config.yml file (and even then, my assumption was it was still a single directory.) That said, I still sought out whether there was a way to organize them by at least year within that single folder. I’ve been blogging for 11 years this spring, and while sporadic at times, that is still a lot of posts. When I need to reference a new one, or look for something from the past, having them by year would be nice.
tl;dr yes, you can arbitrarily organize under the
_posts folder however you want. All Jekyll looks for are markdown files with FrontMatter.
What I also learned, and isn’t well documented 1 is that you can create top level folders each with their own
_posts sub-folder and Jekyll will read from each one, appending that folder name to the generated url for the post, i.e. a folder
2016-04-26-post-title would yield a URL of
example.com/foo/post-title (varying by your permalink structure). Those top level folders are then treated as categories, allowing for more filtration within your templates and site organization. I can see other ways of using them, especially as I continue to move towards a more Indieweb way of doing things and more tweets originating from this site.
I intend to contribute my discoveries to the official documentation as soon as I can.
Hint: it’s hidden under
In a longer discussion about the recent pitch by Medium to content creators to move to their platform and options for new companies to build a site on, this nugget on whether Jekyll is an option:
Only usable by developers. About as accessible as improv Klingon slam poetry to anybody else.
Also note, I have a blank variable for summary. Since I’m using webmentions, I use the summary as the text for a tweet, which would be different than an excerpt. Some of this may change when I redo the site redesign, but for now, it’s how I roll.
var title = '%filltext:name=Title%'; slug = title.replace(/[^\w\s]/gi, ''); var newslug = title.split(" ").join("-"); var dt = new Date(); TextExpander.appendOutput("---\n"); TextExpander.appendOutput("layout: post \n"); TextExpander.appendOutput("title: " + '"' +title + '"'+ "\n"); TextExpander.appendOutput("tags: \n"); TextExpander.appendOutput("published: true \n"); TextExpander.appendOutput("permalink: ") +TextExpander.appendOutput(newslug.toLowerCase()); + TextExpander.appendOutput(" \n"); TextExpander.appendOutput("date: ") + TextExpander.appendOutput(dt.getFullYear() + "-" +(dt.getMonth() +1) + "-" + dt.getDate()) + TextExpander.appendOutput("\n"); TextExpander.appendOutput("summary: \n"); TextExpander.appendOutput("--- \n"); // %filltop%
If you can’t tell by previous posts, I’ve been working on getting
Webmentions to work with my new Jekyll site. I think I’ve finally nailed. If you take a look at my initial post on moving to Jekyll, there’s a link for a tutorial on using Travis CI to build a branch and move the flat files into the mater branch to be served on GitHub. With the help of a Aaron Gustafson’s Webmention.io plugin I finally have it working. The trick was that the rakefile was firing in the build process too fast, so webmention.io couldn’t find the post on my domain, thus not sending the mention. My probably not so elegant solution was to put a
sleep 2m in my shell script to slow things down and let GitHub catchup before firing the rakefile and sending the mentions. This post will be my final test. If all goes well, I will try and write up a more detailed explanation of what I’ve done since there’s still a lot missing for doing this with a Jekyll site.
I’ve officially made the change from Habari to Jekyll. I will certainly have more to share on the move, both a post-mortem on Habari, as well as the process I’m using currently for using Jekyll.
My basic workflow currently is serving the page from GitHub pages, however I’m using Travis CI to build the site and publish to master branch1 , there by bypassing the restrictions of gh-pages (specifically, their need for using –safe mode and not up-to-date version of Jekyll). Currently my use case would probably work within their parameters, however I had already started using 3.x and at the time of writing GitHub is using 2.x.
More importantly to me, I want to be able to blog from my phone. It something that I feel has limited me in sharing interesting items I come across as well as stopping me from making time to put thoughts down as they come. I had originally wrote up some thoughts on using iOS and Jekyll, but later came across a better workflow2.
Finally, there are still some wonkiness around, I’m sure my Atom feed is broken and am not sure how to redirect that yet using GitHub. I doubt I had many subscribers, so if you stumble on this and previously read my random posts, you may need to update while I investigate options. Certainly there are some styling issues that I want to address as well as some under the hood improvements.
I have been researching and thinking seriously about moving away from database driven blog engines to static file blogging for quite awhile. My extensive research has me convinced for my ideal workflow, Jekyll will be the answer—except for my goal to somewhat easily blog from my phone. All of the front matter could be handled by TextExpander snippets or custom keyboard shortcuts in Drafts or Editorial. The issue has been that with an iOS device, you are basically confined to using Dropbox or iCloud for the text/markdown files. Wanting to keep everything in a Git repo under version control, I hadn’t found a way to automagically push a Dropbox file to a Git repo without having an always on machine at home using some listening app like Hazel to do this. While that isn’t out of the question, I want something straight from the device.
Extensive Googling finally led me to Zappier. Similar to IFTTT, they have a Github/Dropbox workflow that allows you to send a pull request to Github when a new file is added to a directory in Dropbox. And while if I was simply using Github pages to host a Jekyll site, that would be the end to a simple solution.
However, I still want to host my own data on my own VPS (more on that later). Enter Jekyll Hook, which, while not seemingly for the faint of heart, allows one to run their own “Github Pages” on their own server.
So, while all untested at this point, on paper it seems I can have a dedicated Dropbox folder synced with an iOS editor that when a markdown file is saved to it, Zapier will attempt to send a pull request and merge it to a Github hosted repo of my blog [footnote, possibly need to have iOS app to approve pull request but option is in the recipe for the workflow. I assume it will work save for any previous files by same name causing a merge conflict]. From that, the Jekyll Hook script/solution will fire and rebuild the the site, all without leaving the convenience of my iOS device.
Potential magic I tell you.