ControlGroup.com: Built Using Jekyll

Originally published on controlgroup.com

If you’ve been to our website recently, you may have noticed there have been a lot of changes. There is no server or CMS powering our website anymore, with the exception of the blog, which will soon change.

The pragmatic reality of a company website, beyond its blog, are such that content doesn’t need to be changed more than once or twice a week. So in the interest of speed and ease of maintenance, we chose Jekyll. Sure, I am most comfortable with a CMS, and that would have been a safe bet for my first public-facing work I would play a major part in the production of. Luckily at Control Group, knowing a tool isn’t a compelling enough reason to use it, so I invested a bit of time learning Jekyll.

Jekyll satisfied all of our wishes, but some things required extra finesse/hackery, especially since it was designed to be “blog aware” rather than for entire company websites. If you’re a designer/web coder mutt like me, there are certain holes in the available documentation that I felt could have been explained better. Many things I figured out were very duh-worthy and would have benefitted from a less pedestrian understanding of Ruby. But with some decent Googling skills, I usually found the answer…Thank you stackoverflow posts, blogs, Github issues, and other miscellany; I couldn’t do it without you. Regardless, there’s a lot of great documentation on Jekyll.

Pros

It’s fun!

Nothing gave me more satisfaction than having to build and iterate based on our specific needs. It was frustrating at times, but figuring out what we could place in the YAML front matter, and having layout dependent choices made based on them, was nothing short of wonderful once you get it.

It’s fast and secure. Version control FTW.

CG deals with servers “on the reg” for many of our clients, but it would be nice to have one less instance to concern ourselves with watching. Having a solution that didn’t require the heavy lifting of a CMS meant there would be no software to update, no cron tasks, nothing but a bit of AWS S3 goodness. We serve it using a CDN (Amazon CloudFront) to speed up our already fast site and add additional security.

Cons

No plugins can be run on GitHub pages because of security reasons.

Sure, I can run Ruby plugins on my local machine (say, to generate category pages) and push the static HTML generated, but this went against one of our major requirements. We chose Jekyll with the hopes that content could be edited by anyone on the GitHub website without server/local machine intervention needed to keep plugin-generated content up to date.

Markdown is a fickle mistress.

I used the default markup interpreter engine for Jekyll which is Maruku, but as far as I know, they all have their caveats. Just one seemingly harmless unencoded ampersand was enough to make Jekyll get all Hyde on you.
Another big markdown offender is allowfullscreen, something you probably never noticed is in every video embed code in existence. Including it will throw you an error. Removing the offending attribute is the simple enough solution, and fortunately, it doesn’t seem to remove the video’s ability to go fullscreen.