Website Re-Development

11th August 2013 | Tags:

Until very recently, this web­site was pow­ered by Dru­pal. Now although Drupal’s great in a whole raft of sit­u­a­tions, there are times when either it’s overkill for some­thing small, or just doesn’t fit into one’s work­flow. I came to realise that both of these applied to this site, so when it came to re-​developing, I decided to aban­don Dru­pal for the site altogether.

In the end, I decided to rebuild the site using Jekyll, along with a few other tools along the way.

This post explains the moti­va­tions behind the deci­sion, what I did next and some of the chal­lenges I faced along the way.

The Need for Re-​development

There were sev­eral aspects that made re-​developing my site some­thing of a priority.

First, it wasn’t mobile-​friendly. I may have been able to get away with that some years ago when I first drafted the site, but now that’s just not accept­able. After weigh­ing the pros and cons of a respon­sive vs a sep­a­rate mobile site, I decided on the for­mer — and the only way to do that would be to start the front end build again from scratch.

Sec­ondly, the site was run­ning Dru­pal 6. When I first built the site, Seven was in the off­ing, but not yet secure or sta­ble enough for pro­duc­tion. Stay­ing with Dru­pal would have meant an upgrade, and mov­ing between ver­sions 6 and 7 isn’t trivial.

Lastly, the struc­ture of the site was no longer ideal. My work of late has included open-​source devel­op­ment and lots of writ­ing, so a port­fo­lio only told half the story.

Other Fac­tors


Though the entire site was content-​managed, the vast major­ity of my time was spent on the blog — the rest rarely changed. Although I had a WYSI­WYG edi­tor installed I was far more likely to use raw HTML, and often use the tools I use every day — such as Sub­lime Text — and then copy­ing between appli­ca­tions, rather than edit­ing in the browser. As such, it made sense from a work­flow point-​of-​view to switch to some­thing that closer resem­bles my devel­op­ment process.

I’ve also become quite a fan of Mark­down of late.


For such a sim­ple site, there sure was a lot of it.


There were time when the site ran pretty slow. Largely this was down to the fact that I have all sorts of projects run­ning on the same box, and also because there have been times when the site has taken some­thing of a ham­mer­ing — par­tic­u­larly whe I release a new arti­cle. I wanted my site to per­form the best it pos­si­bly could, with­out throw­ing server resources at the problem.


Then there was the final moti­va­tion — I wanted to try some­thing a lit­tle dif­fer­ent. There’s no doubt that mov­ing sites from a CMS to sta­tic is quite “cool” right now; maybe there was an ele­ment of that, but it’s also true that the vast major­ity of the projects I’m involved in use frame­works or CMS’s, and I wanted to try strip­ping back the com­plex­ity of those, and try some­thing new. Enter Jekyll, which although I’d looked at I hadn’t really used.

What had to Go

In mov­ing from a fully-​featured CMS to a sta­tic site, there were a num­ber of things that would have to go — or, at least, be re-​thought.


Most of my posts attracted some excel­lent com­ments. Clearly com­ments are some­thing that aren’t sup­ported with a sta­tic site, at least with­out using some­thing like Disqus.

How­ever, with com­ments you always have to weigh up the pros of invit­ing dis­cus­sion and gain­ing use­ful insight, with the effort involved in fight­ing spam. I used a num­ber of the tools at my dis­posal to help the fight on my Dru­pal site — pri­mar­ily, mod­er­a­tion and Mol­lom. I delib­er­ately opted against CAPTCHA — as well as being far from fool-​proof, I per­son­ally find them a sig­nif­i­cant hinderance.

Despite my best efforts, the sheer amount of spam — includ­ing a week of sus­tained attacks that had led me to dis­able com­ments any­way — made the deci­sion to put aisde the lack of a com­ment­ing sys­tem in my deci­sion to move to a sta­tic site.

Dynamic Image Re-​sizing

Drupal’s image styles (for­merly image­cache) enabled me to upload a sin­gle image for some­thing, and have the CMS take care of any nec­es­sary resiz­ing. There are solu­tions for Jekyll, but even then it became clear that this wasn’t a pri­or­ity. I also found that images weren’t always resized the way I wanted them, and set­ting the com­pres­sion is some­thing that varies accord­ing to the image — and can only, I feel, be done by eye. As such, los­ing this par­tic­u­lar piece of func­tion­al­ity wasn’t a big deal.

Other Fea­tures

Of course Dru­pal pro­vides many, many other fea­tures — either in core, via third-​party mod­ules, or by writ­ing your own. But I didn’t need any­thing else. I didn’t need to be able to switch themes, to trans­late con­tent, dynamic views or a hun­dred and one con­tent types. In fact, the sheer amount of unused func­tion­al­ity just added to the bloat.

Other Advan­tages

One of the prob­lems with a CMS is that as well as hav­ing to keep a backup — prefer­ably in source con­trol! — of all your code, there’s also the data­base to worry about. Indeed, with Dru­pal in addi­tion to all the con­tent being stored in the data­base, so too is much of the con­fig­u­ra­tion (for­tu­nately, Dru­pal 8 is chang­ing this). So that’s two things to worry about, and with a data­base that means sched­uled back­ups. It’s also much more com­plex to use ver­sion con­trol with SQl sumps. With a sta­tic site, there are no such prob­lems — the whole thing; tem­plates, code, and con­tent is in one place and can be safely stored away in Git.

I’ve reworked the design slightly, replaced all the CSS and under­ly­ing HTML, and tidied up some of the visuals.

Source-​code Highlighting

I use a lot of code sam­ples in my posts, so source-​code high­light­ing was a must. For­tu­nately, Jekyll sup­ports it by default using Pyg­ments.

That said, there are a few steps required to make it work — the actual steps will depend on your sys­tem, and what you already have installed.

First, I had to install Pyg­ments. I installed on a Mac, so I already had Python installed, so I sim­ply had to do this:

sudo easy_install pygments

I also needed to ensure it was installed in my _config.yml file:

pygments: true

The next thing I needed to do was cre­ate the css file:

pygmentize -S default -f html > css/pygments.css

And the step I for­got for a while, lead­ing to much unec­es­sary head-​scratching — includ­ing the CSS in my layout!

At first, I strug­gled to get PHP code to high­light. Turns out that by default, Pyg­ments expects <?php tags, unless you use the startinline option:

{{ "{{% highlight php startinline "}}%}}

Using Pyg­ments — which for­mats source-​code using CSS — solved one of the prob­lems I had with my exist­ing site, which was that the Javascript-​based solu­tion I was using was a lit­tle tem­pre­men­tal. It also caused prob­lems on mobile — though to be fair, I do find code quite dif­fi­cult to read on mobiles regard­less. Using CSS to for­mat the code seems much more nat­ural than using a plugin.


To use CMS par­lance, Jekyll only sup­ports one “con­tent type”, and that’s blog posts. In my old site, my port­fo­lio was com­prised of a “project” con­tent type, and I felt it would be eas­ier to man­age if I had some­thing sim­i­lar in this ver­sion of the site.




In _plugins/unident.rb:

module Jekyll
  module UnindentFilter
    def unindent input

Liquid::Template.register_filter Jekyll::UnindentFilter


Twit­ter Feed

Another chal­lenge I faced was the Twit­ter feed, that appears on the front page of the site.

Because it was a sta­tic site and this involved dynamic con­tent, it made sense to explore a client-​side solu­tio; i.e., Javascript.

Only a few months pre­vi­ous, this would have been a dod­dle — how­ever, my web­site rede­vel­op­ment came shortly after Twit­ter finally retired the old REST API — requir­ing devel­op­ers to use OAuth, even if all you want to do is fetch a pub­lic timeline.

The prob­lem with OAuth, of course, is that your cre­den­tials need to be kept well out of view — which makes things dif­fi­cult if you’re build­ing a client-​side application.

My solu­tion — as sug­gested by this excel­lent arti­cle — was to build a sim­ple proxy.

As such, instead of fetch­ing the data from Twit­ter, my JQuery code sim­ply needed to pass the required URL to my proxy, and then that would be respon­si­ble for mak­ing the call to Twit­ter, authen­ti­cat­ing using OAuth.

The next chal­lenge was to for­mat the tweets. For this I found Remy Sharp’s twit­ter­lib. How­ever, the for­mat method was unsuit­able, because it added avatars — unec­es­sary for one person’s time­line, I feel — and the for­mat didn’t fit the site. Instead, I used the method twitterlib.ify.clean. Here’s the code in full:

    $.getJSON('/twitter-proxy.php?url='+encodeURIComponent('statuses/user_timeline.json?screen_name=lukaswhite&count=2&include_rts=false&exclude_replies=true'), function(d){
        var html = '
    '; for (var i=0,len=d.length; i' + twitterlib.ify.clean(d[i].text); html += ' — ' + twitterlib.time.datetime(d[i].created_at) + ''; // + '">' + twitterlib.time.relative(d[i].created_at) + ''; html += ''; } html += '
'; $('#tweets').html(html); }); });
require 'date'

module Jekyll
  module NiceDate
    def nice_date(input)
      d = input.strftime("%e")
      self.ordinalize(d.to_i) + input.strftime(" %B, %Y")
    def ordinalize(number)
      if (11..13).include?(number % 100)
        case number % 10
          when 1; "#{number}st"
          when 2; "#{number}nd"
          when 3; "#{number}rd"
          else    "#{number}th"




No comments yet.

Links and images are allowed, but please note that rel="nofollow" will be automactically appended to any links.