I’ve been working with WordPress a lot over the past six years or so. I’ve built everything from single-page and standard sites, through to sites with complex e-commerce, membership and e-learning requirements.
There are plenty of reasons for WordPress dominating the content management system (CMS) marketplace, but it’s not without its limitations.
I’ve written about the most common WordPress myths before, but the biggest issues with WordPress are generally how it handles data.
As time’s gone by, I’ve increasingly found a need to display different types and formats of content. WordPress offers lots of ways to do this, but they can be quite convoluted so I started to look at some other options.
Exploring new CMSs
I first heard about Statamic years ago, but didn’t investigate much as I was fairly happy with WordPress. Looking at it again, the documentation relatively inviting and the demonstration videos had a great intro to boot.
I’d also heard lots of positive things about it. Even though WordPress sites can be blisteringly quick, Statamic doesn’t require a database, which helps reduce load times. You can even run the frontend of Statamic as static files if you’re willing to sacrifice forms.
Another side effect of there being no database is that everything can be version-controlled through Git. And that’s something else I wanted to become more familiar with...
Statamic in the wild
I decided to build the CSS For Designers site with Statamic. With all the potential issues surrounding WordPress’ handling of development and live sites, this seemed like the perfect project to dive in with.
Jamie Dumont wrote a brilliant article on setting up a membership site with Statamic which gave me confidence this would be possible. I knew I wouldn’t want to use Stripe for payments as it would require VATMOSS registration, but the article demonstrated how straightforward it was to set up protected content.
I’d forgotten how much there is to learn when adopting a new CMS, but the Statamic documentation is thorough and has lots of helpful examples. Apart from needing to look everything up, developing the site was relatively quick.
For my own reference, and anyone considering trying out Statamic from a WordPress background, here are some thoughts and gotchas.
Pain points
Local setup
I’ve never been particularly comfortable with the command line. Getting the local setup completed was nowhere near as easy as the documentation outlined.
It took an evening plus some help from a developer friend to troubleshoot. Stick with it, though, because being able to develop locally is really beneficial.
Private repos
You can run everything through Git, which is great, but almost all Statamic sites will need to live in a private repo because user data lives in files. As CSS For Designers has protected content, that was also a consideration.
This isn’t necessarily a problem, but I found deploying private repos on cPanel hosts to be quite the nightmare and lost hours messing around with SSH keys. Not fun.
The brilliant Mike Ellis put me onto DeployHQ which makes the whole process much easier. I’d highly recommend using something like that, especially if your host runs cPanel.
Syncing local and production environments
One of the biggest pain points I’ve found so far is syncing live and local data. Statamic provides an add-on to help with this, but I’ve not managed to get that to work yet...though that’s likely user error.
“Mounting” collections
Statamic’s equivalent to WordPress’ Posts is Collections. You can create Collections for any type of post with any type of data.
Collections could be viewed as a WordPress category. These Collections contain Entries (Statamic’s name for a Post or a C*ustom Post Type*). For instance, you might have a Collection called Articles with Entries about a range of topics.
Lists of Entries can be pulled into other areas of the site (e.g. Latest Articles) and sorted by date, title, or lots of other things.
Entries within the same Collection have a relationship to each other, much like Posts in WordPress. They can navigate to each other (Next / Previous etc), be assigned a Fieldset (more on this later) and lots of other things.
It took me a while to get my head around this new terminology, especially when it came to mounting a Collection onto a page. Mounting a Collection to a page associates that content with the page and allows you to set those entries as child pages in the URL structure.
For example, you might have a page called Articles and mount a collection of the same name to that page. You could then have a URL structure that’s something like /articles/title-of-article etc.
Other settings
Everything in Statamic can be controlled with the raw YAML files. This soon becomes the quickest way to manage the site.
That said, the format and structure the data needs to follow isn’t always clear (e.g. when setting up Routes). A simple workaround is to make the first change using the control panel: this sets up the YAML file which you can edit in the future.
Unexpected joys
Multiple Layouts and Templates
Statamic offers two levels of control over how your pages display: Layouts and Templates.
Layouts are the overall appearance of the page: they could be viewed as everything outside of the content area (i.e. header and footer).
On CSS For Designers, I use two layouts: one for the public-facing site and another for the courses. The courses have a left-hand sidebar navigation, whereas the front of the site has a traditional horizontal layout.
Templates let you define the structure of the content area. You might have a template for the home page, a blog, a page with a sidebar, etc.
What’s great about Statamic is it’s ridiculously easy to switch the Layout and Template on a page-by-page, folder-by-folder or even Collection-by-Collection basic.
For instance, you could set a Collection to have a specific Layout, but specify a different Layout on a single entry within the Collection. This was a revelation to me
The templating language is great
Statamic’s templating language is called Antlers. These are pairs of double curly braces: {{ title }}
You can use these to create conditional statements, in a similar way to PHP (e.g. {{ if }}), pull Collections into a page and loads more. It’s a powerful and flexible language yet straightforward enough to get started with.
What’s particularly handy is that you can input Antler tags while editing Pages/Entries in the dashboard. So, if you decide you need to pull in the link to the latest item from a Collection, you can do so on whatever page you’re editing.
What’s more, you don’t have to worry about the WordPress loop, either.
Fieldsets
Fieldsets allow you to define the fields for Pages/Entries on your site. There are lots of content types to choose from and they’re another powerful Statamic feature.
Like the Layouts and Templates, these can be defined across sections of the site or on a per-page basis.
Lean code
When I worked with WordPress, I’d often be using frameworks or blank starter themes due to time or budgetary constraints.
There are some starter themes available for Statamic, but the templating language is so straightforward it’s quick to develop layouts from scratch. This gives you tiny file sizes with no excess code.
On CSS For Designers, the only JavaScript used are for syntax highlighting and privacy-focused analytics.
Things to explore
I’ve only scratched the surface of what’s possible with Statamic. There’s plenty more I want to look into such as the Bard editor and Yields.
My next project will be to rebuild Work Notes with Statamic. Then, who knows...
Top comments (0)