Atomic Smash homepage splash

How to survive a WordPress Hackathon

Words byAnthony HartnellMarch 2, 2018

On Friday 23rd February 2018 I took part in Europe’s first do_action WordPress hackathon in Bristol, situated at Desk Lodge. We were tasked to build a new website for Third Sector Solutions in a single day and our team consisted of:

  • Daniel Reading – Project Manager
  • Tim Sheppard – Content Editor / Storyteller
  • Klara Kucerova – Frontend Developer
  • Dom McLoughlin – Designer
  • Tom Hartnell – Frontend/Backend Developer
  • Me (below) – Backend Developer

Anthony Hartnell sitting in a chair at the Bristol 2018 do_action WordPress hackathon.


I’ve created this blog post to highlight my thoughts from the day and share some tips and suggestions of how I would work differently next time.

Throw away your code

I spent a lot of time before the hackathon thinking about how to build the perfect  frontend/backend development framework to use on the day. It was going to be a super slim Twig/Timber theme with BrowserSync and gulp for the JS and Sass all wrapped in a responsive grid system using Susy. It then occurred to me that building a bespoke system in a templating language that is lesser known (generally) could be a problem when we hand over the project, tying them into finding Timber/Twig developers for potential future updates. My colleague Adam suggested I check out the Underscores Wordpress theme which is a stripped back, barely-styled theme with the latest HTML5 boilerplate code and over 100 contributors.

I downloaded the project and added the gulp/browserSync integration from the previous iteration and although it’s a very impressive project it was quite daunting to me that I had no prior understanding of the codebase which would be useful on the day.

My other colleague David gave me some great advice and told me that his experience of a hackathon resulted in very little time being available to spend on coding and that a good portion of my day would probably be spent planning and collaborating with the team, remaining flexible where possible.

It was great advice so, I threw away the code!

The best thing about starting over was that we could all begin at the same level and I could work directly with the team to determine how we could adapt one of the many free WordPress themes on the official directory. Based on our clients’ needs we used the filter to find a theme with a carousel and good header/nav.

The WordPress Theme Directory filtering system

Picture of the WordPress theme directory filter.

Our theme called Catch Kathmandu seemed the perfect fit and all our content and image edits could be easily changed using the WordPress Customizer. There were only a few minimal PHP changes that needed to be made.

We made the decision early on to just write plain vanilla CSS at the bottom of the stylesheet as it would just be way easier to implement and we wouldn’t have to change how styles were loaded.

Be prepared to adapt

Communicating back and forth between email became quite time consuming and hard to track as the day went on which is where I realised Slack would have fitted in nicely. Being able to send individuals the resources they need while maintaining a group chat to keep track of progress would have worked well. In the end it’s down to preference but having a multi-user, reactive app like Google Docs for example always works better in group situations I believe.

Don't rely on Airdrop

Our designer Dom (@dommcloughlin) had created some fantastic new graphics for the website with a full brand refresh. In order to send the design assets around, we had the idea of using Airdrop to sync them across our team who were mostly Mac based but, frustratingly, mine didn’t work despite having the same OS version as everyone else. We resorted to using a combination of weTransfer, email and a USB stick.

Use git for code sharing

We actually had three developers on the team – Klara (@pxandbeyond) and Tom (@tomhartnell) doing front end CSS tweaks and myself doing the backend PHP work. Git was essential to our code collaboration and seeing as we were all on Bitbucket, I created the repo and invited them onto the project. We just let each other know when we were committing and I would occasionally upload the theme manually to the staging server with the cPanel file upload utility.

Take regular screenshots

As some of the content was written on the fly and entered directly into the Customizer we didn’t have a record of it anywhere except for on the screen at the time. There were a few times that I wished I had captured my screen as a backup because I lost connection once and the content disappeared when it reloaded the page. Tim (@timsheppard), our content editor was doing a fantastic job of gathering all the content across the many original pages so I worked quite closely with him towards the end of the day.

Prepare the staging server as soon as possible

Daniel (@minddoodlecom) had gathered all our site requirements beforehand in Mind Doodle so it was easy to get the details when we needed them. Our Siteground shared hosting server was allocated to us before the event giving and I logged in to the cPanel interface. After lunch I got cracking on setting this up with a public domain which we could access as a team and see the progress. I used the WordPress installation tool to set up the site but I couldn’t log in because the temporary domain needed enabling before I could login to wp-admin. I had to contact the live chat support for them to turn on this feature (!?) but it ate into our time a bit and I had to ask another team for help.

Because the client already had an existing website, accessing the staging server could only be achieved with a temporary domain. I wished I’d logged in before the event and set this up to free up some time.

Organise your computer

When files are flying around between the team it’s easy for everything to get messy and you’ll most likely have far too many desktop windows open. One lesser known tip I’d thought of is to create a folder for the project, somewhere obvious like the desktop and change the default download folder from your browsers and applications to that folder.

Take regular breaks

At the start of the day we made sure to have a coffee and keep hydrated and fed with the various treats on offer. We’d had our team introduction and kick off meeting so all knew what we needed to be getting on with and the day took its natural progressions towards lunchtime. The lunch provided was fantastic with a huge selection of amazingly tasty pizzas and it was a great chance to socialise and review where we were and where we needed to get to. Towards the end of the day I was walking around a lot more to chat to the team and I went back and embedded myself at my desk. It started to get quite hot and stuffy in the room but all I could think of was the work I needed to do so I didn’t break for a refreshments- it was a fuss to go off and get water even though it was just across the room! Pack a water bottle so you don’t have to make many trips.

I found 4pm to be the hardest part of the day- just 1.5 hours before finishing. The last rush to finish before our presentations left me feeling pretty exhausted at the end of the day. It was both very rewarding and mentally exhausting at the same time.


What I’ve realised at the end of the day is not to strive for perfection but to strive for great communication and to have something to show at the end of the day. Be proud of what you’ve achieved when the day is over! It may not be the rockstar website you dreamed you’d build but you can still work on it after the hackathon is over.

I believe that the most valuable help comes afterwards when your client/organisation needs to use what you’ve built. This doesn’t have to involve spending hours of time training them to use it as a simple document outlining how to change text and media on various parts of the website will go a long way.

I would definitely do this event again and a lot of the success went to the organisers and sponsors for creating a smooth experience. I found everyone to be really willing to help each other and keep it light hearted.

Even if you don’t feel you’re ready to take on a hackathon, giving your time to help others in any capacity is very rewarding and you learn so much, not to mention it’s a great chance to meet and learn with lots of new people.

Check it out at

Final result

Image of for the Bristol 2018 do_action Wordpress hackathon.
Profile picture ofAnthony Hartnell

Anthony HartnellDeveloper

Anthony works in the development team and enjoys creating plugins and integrating maps, libraries and other APIs into Wordpress.

Go back to top

Keep up to date with Atomic news