Thoughts on Statamic 3

Update

After posting this review the guys from Statamic reached out to me to address some of the issues. The documentation has been extended, and they helped rectify some of the specific issues I experienced. I have since implemented Statamic on a number of client sites with great success. With larger client sites I have opted to implement Statamic using Blade, which gives a little less of the "just works" support, but way more flexibility overall.

--

Statamic is a CMS built on Laravel. I've had my eye on it for a while but never really had an opportunity to use it in production. Time had recently come to rebuild both my blog (where you're reading this) and one of my websites which reviews cordless vacuums, and I decided to see if Statamic was up to the challenge. Particularly good timing as Statamic 3 was recently launched, which is the latest and great version of the CMS.

Initial thoughts

At first, everything was pretty good. Installation is painless. I'm very used to Laravel, so opted for a composer based install. With no database requirement I was up and running in under a minute. Great.

Starter kits

There are a few different 'starter kits' available. For my blog I opted for 'Cool Writings', which comes with a bunch of different settings geared around running a blog. For my vacuum website I went for Peak, which is a more feature-rich starter kit.

To my surprise none of the starter kits included Bootstrap, instead they were all geared around Tailwind. I like Tailwind, but it's a very different build path to what most developers are used to so I was surprised there wasn't a Bootstrap starter kit available. Removing Tailwind and implementing Bootstrap is extremely straightforward though, none of the starter kits are particularly frontend heavy, even though they class themselves as opinionated.

The control panel

The control panel is responsive, clean and very easy to use. Without having to revert to the docs it's reasonably obvious what everything does, from collections, taxonomies, assets, blueprints and fieldsets - not much needs an explanation. I'll give a brief overview of blueprints and fieldsets though.

Fieldsets

Fieldsets are groups of fields bundled together to create an 'element'. You can use them for different purposes than this, but it's definitely the best way of thinking of them.

Take a button as an example. You can create a button fieldset, which contains the following fields:

• Title (text)

• URL (text/url)

• Variant (dropdown)

You can then use this fieldset everywhere you'd be able to use normal fields elsewhere.

Blueprints

Blueprints are sets of fields which can be assigned to different pages, templates and collections. If you're coming from WordPress you can think of this as what ACF does. There are a huge number of available fields from the off though.

Most of these should be obvious, but there's one key one there called Bard...

Bard

The Bard field is pretty clever, it's probably the most used field and allows you to define your own page builders. You can create a Bard field, which by itself is a WYSIWYG editor, but you can then in turn add fieldsets to it to create your own components.

The CMS shows a Bard field as a single WYSIWYG field, but it's actually a bunch of different entries. Kind of like Gutenberg, but much cleaner.

If you wanted to get really fancy, you're even able to have a bard field within a bard field.

Within your theme you simply loop through the bard field, and do something with each type, which is usually just including another file to handle the output for that component.

Antlers and theming

Most developers working with a CMS spend the majority of their time building the theme, so let's go over that. Statamic uses its own templating language called Antlers. Antlers is very, very similar to twig; you have some basic conditional logic available, some control structures and loops, and some basic modifiers. Perfect.

Well, no.

Antlers itself isn't really the problem I encountered. The lack of the availability of PHP was. When you're building a theme there are many times you just need to dive into PHP to do some debugging, and being restricted to only being able to use Antlers was really quite tough at times. I was probably doing some more advanced stuff than you would generally do in a typical theme, as I was deep diving into some scoping problems due to the way I needed to handle custom routing, but the inability to just revert to PHP to really see what was going on behind the scenes was quite debilitating. Frustrating, because it's probably reasonably trivial to add support for vanilla PHP.

Debugging

I might be giving Antlers a bad rep here, because you do get access to an extremely useful method called dump, which will output all available variables for you in a nice interactive tree. Very useful, and something remarkably missing from some CMS like Drupal.

Scoping

Scoping is a real problem in Statamic in my opinion. The nature of Antlers makes this all a little problematic.

Take the following example code:

{{ get_content from="slug" }}
    <h1>{{ title }}</h1>
    
    {{ glide:image width="200" }}
        < img class="mx-auto" src="{{ url }}" alt="{{ title }}" width="{{ width }}" height="{{ height }}" loading="lazy">
    {{ /glide:image }}
{{ /get_content }}

Let's run through what's going on here. We're in a custom route, which is defined in my routes file, like you would in vanilla Laravel. I'm grabbing the slug (eg: Route::statamic('whatever/{slug}');), and using get_content to get the available content from the CMS for that slug. So far so good.

{{ title }} refers to the page title. The glide:image tag pulls my image field out, and makes a bunch of variables available inside those tags related to my image.

If you read that code you'd expect something like the following to be output, right?

< img class="mx-auto" src="/storages/imgs/example.png" alt="My page title" width="200" height="125" loading="lazy">

So would I... the problem here is the alt tag. What you actually get is the name of the image output. That's probably to be expected as our scope has changed and we're inside glide:image. But how do I output the actual page variable there?

Well there lies the problem. After an hour of messing about and trying all sorts I couldn't work it out. I jumped on Discord and got some suggestions, none of them that worked. I was left scratching my head, as to why I can't do something as simple as define a variable.

I'm not suggesting what I'm trying here isn't possible - I'm almost certain it is - but it's either:

• Possible, but not documented

• Possible, documented, but not easily found

• Not possible

None are great really, especially for such a common use case.

In the end I achieved it with the following:

< img class="mx-auto" alt="{{ title }}"
{{ glide:image width="200" }}
    src="{{ url }}" width="{{ width }}" height="{{ height }}"
{{ /glide:image }}
 loading="lazy">

Really not nice.

Support

Statamic isn't a hugely popular CMS, which makes me nervous when it comes to support. However, there are a couple of great options. You have their forum, and you have Discord, both are very active and you will get a solution from both... eventually. However, don't expect the same reaction as you would with a Laravel or WordPress issue on the likes of StackOverflow, where you'll either find someone else with the same issue, or have your question answered within a few minutes.

I actually found this quite limiting. I had very specific requirements with a few things on my theme. The above scoping issue is just one of a handful of problems I encountered, and it was a little debilitating having to wait so long for answers. That's no disrespect to the guys at Statamic - they're way more helpful than on other communities I've encountered - but it's a small community so things naturally take longer.

Laravel

Statamic is, beneath it all, Laravel. That's a massive advantage over any other CMS. No matter what site I'm building it comes to a point and I really wish I had something more powerful to build out a feature. There's nothing more powerful than Laravel for these times.

Statamic is literally sitting on top of vanilla Laravel. You can create a route, create a controller and you've got a standard Laravel MVC set up ready to go.

Conclusions

I'll likely use Statamic again for personal projects but I think I'm a long way from being able to use it on a client project for the moment.

If the documentation had a bit of padding around certain aspects, especially available tags and scoping, and PHP became available as a fallback to do some things Antlers just isn't capable of, I think I'd feel way more comfortable. I'm almost certain all of the issues I encountered were simple fixes, but the solutions to those small problems were way too difficult to find, and that is really Statamic's only downfall.