#statamic

How’s the ecosystem? If all I ever used was ACF would the included field types cover most vanilla use cases (forms etc?)

How easy is styling with SCSS?

When we first started Pixlee, things were pretty simple. We had a single monolithic Rails application that powered everything from the web application to background workers to landing pages. As we grew the business and the platform, that monolithic application became a collection of systems and services.

When people ask questions about our tech stack, they usually mean our application servers. One often overlooked and valuable portion of that stack is our content site; all of the marketing copy, landing pages, and blog posts that help us tell the Pixlee story. As our non-technical staff grows, it's become imperative that they be empowered to make changes to the content site quickly without technical assistance. We believe that our content process should be as agile as our software development process.

We were able to settle on a workflow inspired by the folks over at Asana who wrote a great blog post detailing their use of Statamic, an incredibly awesome file-based CMS. Here's our take on the Asana team's workflow:

Increased accessibility through the GUI 

The biggest deviation is that we keep the Statamic Control Panel enabled on our staging server and make extensive use of Fieldsets to create custom page types. The power of Statamic lies in its extensibility - designers are not limited at all by the CMS and can empower non-technical teammates to jump into an easy-to-use GUI and make changes to content without affecting design. Anyone at Pixlee is able to dive into the staging Control Panel, make changes and immediately see the results as they would appear on the actual site in real-time, all without worrying about "breaking the site". This is a pretty powerful proposition. 

Everything is backed by Git transparently

We like having everything backed by Git but didn't want people navigate through files and folder structure of GitHub that they really don't need to know or care about. We have a hosted Git repository hosted that everyone can push to and pull from without even realizing it. This Git repo is the single source of truth for our content. 

Every time a teammate creates, alters, or deletes content, we perform the relevant Git actions in the background and push them to our repo. And, because they are editing content on the staging server itself, they can quickly see the results of their changes without having to navigate to another URL. At the same time, technical teammates can make changes locally and push to the repo as well, which will then update the staging server using a post-receive hook and notify anyone working on content that a developer/designer has pushed changes.

We've extended Statamic with Git functionality and a lightweight websocket-based alert system to achieve the above and could not be happier with how easy of a process it was. 

Deployment

Deployment is handled by a technical member of the team who reviews all changes and merges into the production branch when ready. Afterwards, it's a simple push to Codeship which then deploys to our production Heroku server. This is a pretty quick process and is more of a sanity check to that ensure nothing goes wrong. 

Impact

Before we switched to Statamic, we had a hodgepodge of static pages served by Rails directly for the core marketing copy/pricing pages and Wordpress (reverse proxy from the Rails app) for blog and landing pages. This was a very hacky setup and led to a lot of unnecessary lead time on things as simple as switching a sentence on the Rails-backed pages or a lot of frustration when working in Wordpress. More distressing, our content workflow did not reflect the agile processes that are the trademark strengths of a small team. 

As a startup, time is our most scare resource and pulling a developer or designer to perform incremental website changes would be a painful context switch, so a lot of changes were simply left on the bench. 

Now, anyone can make changes to the site, see it in staging in real time, and have it deployed within minutes without having to re-deploy our core application server. And because we've empowered the entire team to make changes quickly, people are more interested how our site performs and how we can improve it. 

I'm not sure exactly where I entered the rabbit hole, but I saw a mention of Statamic somewhere, and one link led to another until I realized there is a myriad of very slick, flat-file-based frameworks to choose from, in just about any language you prefer.

Perhaps the idea of a barebones, well-orchestrated platform was such a relief because I'd been spending my entire weekend hand-coding PHP to send multi-part MIME order confirmation emails with crusty table markup, in the thick of aging procedural code. From "GOOD GOD WHAT AM I DOING WITH MY LIFE" to "Oh cool, Statamic looks nice."

Statamic just needs PHP 5.3. Pretty slim requirements1. It uses YAML for all config files, and creating plugins looks damn simple, enough to make PHP appear not-too-shabby as a language.

One of the earliest to start this trend is Jekyll, which has been around for some time, looking just gorgeous in its Ruby minimalism suit of adult soothing dark techy hues. Installing it is ridiculously simple:

gem install jekyll jekyll create hotsauce cd hotsauce && jekyll serve

Oo-lala! Like Python? I do. How about Cactus?

sudo easy_install cactus cactus create holysmokes cd holysmokes && cactus serve

Looks familiar! Jekyll comes a little more pre-styled, but they're both very similar concepts. And along with Statamic, they all use a variant of the Django templating language (Cactus uses the real deal), which is fantastic.

But every time I get excited about using one of these handsomely simple frameworks, like Ghost, I remember that most sites I've worked on just aren't minimal enough to be served entirely by these solutions. As soon as you need products or some custom data type the client can manage, or a page that mixes & matches data types (just about every site we do at Firebelly to my chagrin), I'd be fighting against their opinionated limitations.

All said, the next time I decide to redo my portfolio site, or have a simple site to build, I'm definitely going to give one of these a try. Being able to just create a new folder to extend heirarchy, work with markup entirely in inheriting templates, and version control the entire stack sounds damn refreshing.

For now, back to my PHP spaghetti.

Not even a simple CMS like Statamic escapes the wrath of 1and1 web hosting, but luckily there's an easy fix. In your .htaccess file, add this line:

AddHandler x-mapp-php6 .php

This enables PHP5.4 on 1and1's servers so you can run Statamic. Statamic requires at least PHP5.3, so that's why it doesn't work by default.

So far I haven't run into any other issues with it, so it looks like the coast is clear.