Building a Multi-Site Template System with Statamic

Curtis Bowman posted this in
Inside Rocket Media
on October 7th, 2014

Custom websites are expensive.

And we work with a lot of small- to medium-sized businesses who can’t afford a fully custom site.

This budget hurdle often prevented these companies from benefitting from our other services (such as blogging and content creation, social media, and internet marketing).

We wanted to lower the cost of entry for these clients while still boosting their web presence and giving them a quality, responsive website.

To do that, we decided to build a website system that used a set of core files to power individual node sites. These sites would have custom content and a shared front-end design that we could customize with individual client colors and branding.

Choosing the CMS

We wanted a content management system (CMS) that was robust but not complicated.

We were looking for something that:

  • Didn’t have a database
  • Could be used to power multiple sites from one central location
  • Didn’t require a lot of upfront learning
  • Was PHP-based

Wordpress & SquareSpace

We first looked at a couple of popular, already-built CMSs that we could theme: Wordpress and SquareSpace.

Wordpress has a database, so that was strike one. It also seemed like a little more than we’d need for these simple websites. Plus, it would be more difficult to keep all the sites up to date because they’d all need their own install of Wordpress.

SquareSpace had many of the same strikes against it. Also, we found there would be a steep learning curve to build custom templates since we weren’t familiar with their theming system.

Static site generators

Since the websites didn’t need any complicated features, like event calendars or e-commerce abilities, we also looked at offerings other than typical CMSs.

There’s been a lot of interest in static site generators in the web development world recently. Static site generators typically have no database component. Instead they rely on static files for content. Some don’t even have a web interface for updating on the fly. You just run a program on your computer that generates HTML files for you and then upload them to a server, and that’s your site.

We didn’t want to go quite that primitive. Fortunately there’s a plethora of different static site generators and simplified CMS options.

The solution: Statamic

After a bit of research we decided to use a fairly new CMS called Statamic. The name is a portmanteau of the words static and dynamic since it is a hybrid of the 2 ideas as a CMS.

Statamic stores content files as static markdown files. The system reads the markdown files and generates HTML files inside of a template for display in a web browser. Statamic also has a simple backend so you can update your site content from anywhere instead of relying on a program on a single computer that holds all your source files.

Creating the template sites using Statamic

Once we decided on a CMS, the next step was to set up our installation so that all the websites could use the single install of Statamic.

A shared file system

We had to do a little finagling to set up Statamic to run a bunch of websites with the same core files. But it boiled down to setting up symlinks in each individual site that pointed to the centralized statamic _app, _add-ons, _themes, admin folders, and all the subfolders (except for users) in the _config folder.

This makes it simple to upgrade all the sites at once. If there is an update to the Statamic system, we only have to upgrade the centralized core files and all the sites are upgraded!

We also set up the sites to share common theme/template files. Any template upgrades or bug fixes can be automatically deployed across all sites. We also have the ability to build more templates in the future which can be assigned on a per site basis.

Customizing each theme

Each individual site still needs to be somewhat customizable, of course.

Each company has a unique logo and brand colors. We can customize these things with individual, overriding stylesheets. The styles are set up in SASS. All we have to do is pick new colors, set them in one file and build them in grunt and the entire site colors are changed.

Each site also has a separate Statamic config file. This file defines various customizable options such as:

  • Contact phone numbers and addresses
  • Affiliate company logos
  • Social media links

And each site also has unique content files. These files integrate with the central core files to create individual sites that live and work on their own.

Scripts

We maintain development and production environments with the core and theme files so we can work on upgrades and bug fixes without exploding our live sites. These are managed by Git so changes can be pulled in easily.

We wrote a simple bash script to swap the symlinks for a testing site between the development and production core files. We also built initialization and deploy scripts.

The init script pulls in a default site repo from Git with all the symlinks already set up so you can get up and running quickly. It also has some common content pages already set up.

The deploy script rsyncs all the individual site files to the live server, adjusts permissions and makes a backup of the former files in case we need to roll back. We don’t keep our live sites in Git since they can be changed on the server via the Statamic backend.

The result: an easy to deploy, easy to update set of websites

We now have the ability to run multiple websites with a single set of common backend core files. The sites are quick to deploy. All we need are the new site colors and website content and we can set up a working site and launch it extremely quickly (generally within a few hours).

And they are easy to maintain; upgrades instantly go throughout all sites running on the system.

But best of all, this helps us achieve our goal of lowering our barrier to entry for customers with smaller companies and budgets.

Curtis Bowman

Developer

A few quick things about Curtis: 1) If there was such a thing as a Netflix Aficionado, Curtis would qualify. 2) The amount of Spotify playlists he has created number “at least a billion.” 3) He claims he’s from Boston, but we’re a little weary because he doesn’t have the accent to prove it. Of course, at Rocket Media these have little bearing as he can code and design with the best of them. (And isn’t that what really matters?)