Leaving Drupal behind

It's been nearly 6 months since my last update. That's way too long a time for the internet to be without my opinion.

In that time, TripleFun has released more games, I've been busy with a 18 month old, and in the midst of all that, I've been wanting to change my site. As anyone with a kid can tell you, the free hours when you can work on your own projects start coming in shorter and shorter supply. So after a long time working an hour here, an hour there, as well as going to bed between 2am and 3am every night for the last two weeks straight in a bid to push it over the line, this is my new look website! It's also the first time I have a site that works on mobile. And only about 5 years too late...

So what's wrong with Drupal?

I haven't been super happy with Drupal for a while now. It was always a bit overkill for what I used it for, in any case, but in no particular order:

• It can be sloooow. It has built in caching etc, and my host provides its own caching layer etc, but accessing the admin pages was a right pain in the ass
• When I originally wanted to update my site, I tried moving to Drupal 7 (from 6). First, their migration tool didn't work, then I realised that all the internals had changed, including templating (which you use to style your site). Having already gone through re-learning the entire API once when I moved from 5 to 6, the prospect of doing it again made my procrastination kick into overdrive
• Also, once you change to the next version of the CMS, you need to go through all the modules that you have and check if they've been updated, and if they haven't, try and find replacements (or write them yourself). Hmmm...
• Drupal's made to be a one-size-fits-all for any type of site that you want to do - it supports multi-users, forums, books, you name it. Mostly I wanted it to show up some pages. The most useful features that I was using were the site search and the comments system. Having a huge CMS just for that was overkill
• In the last year or so there were a number of vulnerabilities found in both 6 and 7. In fairness, they were fixed quick enough, but that meant upgrading, which meant going through all of the above, re-learning everything etc. When I don't use the majority of the features, I was finding myself having to do more work just to have the basics, or go around with the thought that your site is broken (not that this is a high profile site or anything)

When I finally made the decision to upgrade my site (no easy task once I actually sat down and figured out everything that'd have to change), it was a question of what do go with. I was looking at a number of different micro-CMS and even toying with the idea of making one (the curse of being a programmer is that when you see a problem you always think that you could do it better), when a colleague suggested I go with a static site and pointed me towards Jekyll.

When moving from a dynamic site to a static one, there are a number of main problems, namely:

• Getting your content out
• Having a form where people can contact you (very important, otherwise how will you ever know about the myriad of opportunities to get your site on the first page of Google?)
• Dealing with comments
• Site search

Content

To get my content in a static form, I took a look at the database (Jekyll does provide importers, but it didn't work for me). I know next to nothing about MySQL, but it wasn't too hard to find all the different pieces of content (nodes, menus, files, comments, etc) and figure out what all the keys stood for (Drupal does love its ids - nid, mid, pid, fid, they've got all the letters.

I downloaded all the relevant tables and chairs and whatnot as XML, so I could import it into Flash. Because, ladies and gentlemen, it's not dead yet.

I wrote a tool that basically took all the XML and transformed them into Jekyll compliant HTML pages. It added the right Liquid Front Matter, cleaned up the HTML, found dead links, cleaned up the code samples, and pretty much anything else I didn't want to do by hand.

This part took mere months.

Contact form

There are a number of sites that will handle contact forms for you, but I wanted to keep my site as plugin-free as possible, and as ever, I listened to myself when I thought "how hard can it be?"

Basically a form (a snazzy HTML5 one no less!) collects the data, sends it to a super secret PHP file, which uses a Gmail account to email it to me. Using PHP is going against the super secret static mantra a bit, but I'm rebellious like that

Comments

Again, there are a number of sites that will handle this, such as Disqus, but I've always thought that if stuff like this is important for you, you should be the one to handle it. Otherwise you're just creating value for someone else.

Happily the code for handling comments is pretty similar to that of the contact form, with the small tweak that I send myself the HTML code needed to just plug the comment in. Comments for a post are held in their own include file, and are built with the rest of the site, so it's relatively easy. It also has the added benefit of having Gmail weed out all the spam.

Site search

This one was a bit awkward. If you want to go for ease of use, and you don't mind sending people off-site, then you can just have an input that sends the query to google with a site:divillysausages.com appended to the end of it. Google also have a custom search plugin that you can add easily enough, but you don't have a great amount of control over the styling etc.

After searching around a bit, I came across Tapir which scrapes your RSS and you can query easily enough with JavaScript. I wrote a controller for my tool to generate the necessary PHP code to push all the old content (I couldn't get it to work with a simple Ajax call, and I was running into char limits when going via jsonp). After that, I have some JS on my search page that makes the query, and then displays the results, even clipping out relevant parts in the content returned, just like Google, which is the sign of a professional.

They're also pretty approachable via Twitter, so I'd highly recommend them.

Designing the site

I wanted the site to be quick, use as much of the latest technology as was feasible, and also work on mobile. Taking a critical look at my then current design, I dropped everything that wasn't strictly necessary, including social plugins like the Facebook Like button.

This might not be to everyone's taste, but I was finding that waiting for external JS, CSS and iFrames to load was adding loads (relatively speaking) to the overall page weight and render time. Remember that time when Facebook went down and half the sites on the web stopped rendering because they were all waiting on social plugins to stop blocking? Yeah.

My thoughts are that if the reader is on mobile, sharing is pretty much in-built these days, and if they're on a laptop/desktop, they can move their ass to copy and paste the URL. No-ones going to say "Wellll, sugar. I was going to post this delightful site to all my friends, but they don't have a like or share button, and copypasta is for peasants."

I also ignored pretty much everything IE except for the current one on my computer (11?). Going by Google Analytics, not very many people visit my site with IE anyway, and seeing as it's my site, blow that for a lark if I'm going to be wasting my time making stuff work in crappy browsers. I embed normalize.css in my stylesheet and that's it.

All my JS is split up, so only code that can happen on most pages is in the main.js file, while the rest is page specific. I have some simple shell functions in my head so that I can still call JS methods in my content. It just stores the call and parameters so that when the main.js file is loaded, we can execute it there.

I also made the decision to my SWF image and video slideshows with a JS gallery and YouTube. This simplifies things (I was providing non-Flash alternatives anyway), but it was necessary for getting my site to work on mobile. Obviously there's games that are SWFs, but you should at least generally cop that before clicking on the link.

Release day

If you've ever released anything, you'll know the best time to do it is around 11pm.

Predictably, everything broke.

My 301 (hint: permanent) redirects that worked on local decided that instead of escaping, those backslashes were part of the new URL (I adapted the Jekyll style rather than keep old URLs). Some of my CSS and JS decided not to work. And, of course, my custom comments/contact page didn't work altogether.

I finally traced that last one down to the external ports not being open. A quick support ticket with my host (*cough* referrer link), and they opened it up for me. No joke, but the initial reply came about 30 seconds after I posted the ticket, so hats off to them.

A new era

So there you have it. After months of toiling into the wee hours (not fun), I now have a site that, for the first time actually works on mobile, and is pretty quick about it as well. Google keeps telling me I need to inline critical CSS for above-the-fold content, so maybe I'll get around to that some day.

I quite like this iteration; the previous site was a dark theme, so I went all out with spacing and minimalism, while using colour around the images to give the page a splash of life. Incidentally, the pattern for behind the image comes from Subtle Patterns, which is a great resource if you're looking to give something a bit of texture.

Whew, long post.