While we certainly spent a lot of time updating the look and feel of our site, we spent just as much time behind the curtain re-building our new home from the ground up. As we started to analyze our needs for the new site, it was imperative to take a hard look at the old site and find out where some of our biggest pain points were.
The last version of our website was built on WordPress. That worked for us at the time, but we found that we were constantly hacking it to achieve our desired results. We had a highly customized WordPress site, but it was difficult to maintain (I can’t tell you how many times we overwrote the comment styling whenever upgraded to the latest WordPress release). And because of our unique blog layout, posting was never as easy as it should’ve been. The result? We didn’t post or make updates to the site often enough, and that was a major problem for us. We also knew we needed some kind of versioning control, just as we did for every client project we worked on, but setting up versioning on a CMS seemed to be problematic. After our review, we had our goals:
- The new site needed to be easy to update and maintain
- It was important to be able to post frequently, and from any device
- Keep everything under version control
- Minimize database calls to keep the site as speedy as possible
We were starting with a clean slate for this build. In the past, either myself or Matt would be working on code. This time, we had multiple people across multiple companies working in parallel. That could get messy quick. As a result, versioning was critical to keep things protected and productive for everyone.
We’re big fans of using GitHub for source control on client projects, and since Epic Labs feels the same way, that decision was easy. Using GitHub, every developer has their own branch of the codebase, so everyone can work individually without stepping on anyones toes.
Practicing what we preach
With the last site, publishing was a bit of a nightmare. Since we had a highly customized WordPress build, posting anything to the blog almost certainly meant we touched code. Granted, we liked the way things looked, but we stopped publishing things because it was difficult. We wanted something easier. Tumblr to the rescue!
We’ve been designing and building premium themes for Tumblr for a few years now. As such, we’ve become big fans of how easy they make posting articles, images, music, and videos. Since our last blog featured those types of posts, Tumblr was a no-brainer. But if we were going to move away from WordPress for powering the blog, did we really need WordPress for the rest of our site?
Say goodbye to the CMS
After making the decision to use Tumblr for the blog, we decided to ditch our Content Management System. It was overkill for us. Using a CMS like WordPress or Expression Engine is great for client projects — it’s easy for them to update their site without needing to know how to code. However, we don’t have that same limitation and we found that a lot of the time, a CMS would just get in our way and slow us down. We decided that a static site would be easier for us to maintain (and likely much faster) since there wasn’t a database getting in the way.
However, a few months into the project, we were working on Twitter commenting for our blog with our pals at Epic Labs. We ran into a few snags, and Nic Rosental suggested that we may at a minimum, want to use a framework to allow for future growth.
The Twitter commenting feature required a level of back-end functionality that could’ve been accomplished with pretty much any framework or straight-up server side language; but building for one feature would have simply been short-sighted. We love and trust CodeIgniter. We felt it was lightweight enough to drive a mostly static site, but still has enough chops to handle any future feature requests.
Since we were just using static page templates for all the pages up to that point, switching things over to CodeIgniter didn’t slow us down and gave us some added muscle when we needed it. A win for everyone!
Recipe for success
Of course there was a lot more that went into the building of the new 45royale site, but these three fixes solved some of our glaring issues. We’re now able to post to the blog painlessly and can quickly update site content and design whenever the need arises. Having a framework allows us flexibility in the future, and having everything versioned protects our hard work. All of these things combined set us up for success and we couldn’t be happier with the final product.