Statamic as a WordPress alternative for developers

It is no secret that I love Statamic, and have been using it for years now. Switching Mity Digital’s CMS-of-choice from Joomla to Statamic was a delightful breath of fresh air, and has allowed us to be more flexible, dynamic, innovative and creative when developing sites of all shapes and sizes for clients.

I’ve even spoken a few times about Statamic, including:

• Blueprints, Fields and Fieldsets (great for beginners, at PHP Adelaide)

• Building maintainable sites with Statamic (assumes knowledge of Statamic, at Laravel Worldwide Meetup)

• Statamic for Laravel Devs (at Laracon AU 2023)

Our initial brief was simple: a CMS that is built on Laravel. Why? Because we often have clients that need a website but also need it to do something a little left of centre. I reviewed a few candidates, but found that Statamic is the ideal blend. As a Laravel developer, building full-blown apps using Laravel puts me in my happy place – and Statamic grants us all of Laravel’s features and opportunities with a best-in-class authoring experience.

Big statement there, right?

But it’s true: Statamic offers the best-in-class experience for your authors.

Statamic is not a replica of WordPress. It is not a zero-code platform. It can’t be installed on your cheap shared hosting with Fantastico and away you go.

In other words, it is not for Sarah down the road to set up a site herself without needing a developer.

Statamic is a platform for web developers.

You will need to code something to build a Statamic site.

This isn’t a bad thing though: it’s about different audiences. If you’re a developer, or part of an agency, and are looking for power, flexibility and freedom, Statamic is worthy of your attention.

So let’s consider how other platforms work with content. And for simplicity, I’ll consider the out-of-the-box experience. Platforms like Joomla offer a single text field, so you’d better hope that your authors are happy editing HTML for more complex layouts. There are custom fields, but they’re stored together on a separate tab. WordPress can have a single field too, but also offers Gutenberg which, while it is powerful and incredibly flexible, can be overwhelming and unintuitive in places, especially for non-technically minded users.

If you’re a developer or agency building sites for your clients, more often than not, they’re not programmers, they’re not coders, they don’t know HTML or that what they see on their screen is different to how other screens may render a page. Your end users need an experience that keeps them focused on content, not on trying to figure the technicalities of authoring their words.

This is where Statamic comes in, and balances the ideas of flexibility with author experience.

Each Entry (i.e. an Article, Page, Post, etc) can have a Blueprint which dictates the fields that are displayed to the author, and their layout. One way I like to think about Statamic’s approach with Blueprints and Fields is like an object-based approach to content. Huh? Yeah, keep reading, it’ll make sense.

If you’re building a “Blog” section, your Blueprint can have your usual content authoring fields, but also other fields like a Hero Image, Author, Date and a Taxonomy to help filter/group them (think of “Tags” in other platforms). 

If you’re building a “Projects” section, you might have a gallery of images, Project Dates and additional project specifics.

If you’re building a cinema site, you’ll have a “Movies” section, where each Entry would need things like a Synopsis, Running Time and Classification.

Each of these sections can have their own Blueprint – and that Blueprint is modelled around the ‘object’ of content – a Blog, a Project, a Movie. Just like when you’re planning a database schema, you think about the fields you need. This is the same approach – but Statamic translates your Blueprint to a layout on screen for your authors to interact with. You can have different sections and groups; different tabs; conditional fields; and all without writing any code: its Control Panel (its CP, think of your existing CMS’s admin area) is designed, first and foremost, to be flexible and open-ended.

Another way to think about it is that Statamic is a toolbox, and offers you a suite of tools to use… and from those tools you can build a site (including the CP) to truly meet the needs of your authors – especially the non-technical users. This includes dozens of different fieldtypes to make your Blueprints really focused on the object model – text fields, numbers, assets (images/files), its own rich text editor, related content, and even easy extensibility to make your own fieldtypes. That’s one heck of a spacious toolbox, hey. 

Authoring content is then as simple as filling out a form. And your authors – no matter how technical – can fill out a form, right?

Coming from WordPress or Joomla, you’re used to relying on plugins, addons, components, whatever they’re called for your system. 

Such as a popular plugin for WordPress that allows you to have metadata on a page.

Seriously? You’re creating a web page – a page that is displayed on the web – and will always need some sort of metadata. So why do you need a plugin for that?

Given metadata are just fields, you can add metadata fields to your Blueprints and you’re all set. Within your site’s template, you’ll have access to these fields to allow you to include your page’s metadata. 

Statamic still does have a marketplace for addons – some free, some paid – that offer more specific and opinionated functionality. I’ve built over a dozen myself, too.

But because Statamic is so open ended with how you build a site, you may not need an addon for basic functionality like metadata, forms or images. 

Statamic also offers the idea of Starter Kits. Like “Themes”, to a certain extent. Like addons, some are free, some are paid, but can be a starting point to help you get up and running and extend from.

In my Building maintainable sites with Statamic talk, I mentioned that we have our own Starter Kit that we use as a foundation for every site. It gives us our opinionated basics that we need for every site, and allows us to focus on building what the client needs rather than starting from scratch every time.

Let’s be direct with this one: Statamic is not a drop-in replacement for WordPress or any other CMS (but don’t panic). And while that creates an initial roadblock, it isn’t a reason to not consider Statamic.

Structure and ideas

The markup of any CMS is opinionated – Statamic included – but also other platforms, including WordPress, store their users’ content in a way that makes sense to them.

If I were to switch to using WordPress, I’d need to learn how WordPress (especially Gutenberg) stores its content (and what that means for me on the front end). So when you switch to Statamic, you’ll need to learn how Statamic stores its content. 

There’s always a learning curve to a new platform – and admittedly Statamic’s can be initially steep, but it is worth exploring its toolkit with an open mind and thinking about how you can work within the Statamic way of doing things, rather than trying to do the “Joomla” way or the “WordPress” way in Statamic. Get to know its terminology and ideas – and start building something.

Oh and if you’re a Laravel developer, you’ll feel right at home with its file structure and approach: it does things the Laravel way.

And when you have the CLI installed, you can get up and running with a new Statamic site within minutes, making it efficient and simple to spin up a new site and get started.

Work locally

So you’re running your WordPress updates.

And your site breaks.

Why did you do that on production? Well probably because it is so cumbersome to get the same site version up and running locally to install there then push back to production.

It’s a good thing Statamic makes that process so much easier – I’ll talk more about that later.

Lesson here: don’t update your site on production. Especially when Statamic makes it so much more streamlined to push changes up.

Review what it really costs

Statamic has a Pro version, and is a paid licence. This includes a year of updates, and then has a lower cost for renewals.

The Pro version gives you a heap of useful features like content revisions and drafts, multi-site and multiple users and git integration.

And when you’re an agency, like Mity Digital, you can go the “Platform” pricing where you are charged a small fee per site per month… when you reach a certain number of sites, this becomes the smart choice.

For us, Statamic’s licencing offers so much value for money. Especially with the time saved by staying in my happy place, the Laravel ecosystem.

On the other hand, WordPress is “free”.

But is it really?

What about all of those paid plugins? That paid theme? It can all add up. Plus the cost of working with the ecosystem itself. Supporting clients who are not technical trying to use a complicated UI. Maintaining updates that can brick a production site. Or even the current drama. Yeah I won’t get in to that.

Yes, some Statamic addons are paid too… but also Statamic does so much out of the box that other platforms need addons/plugins/components for.

I’ve had to develop components in Joomla. And it is such a nightmare compared to the lean and clean addon development in Statamic (and Laravel). The amount of work I can do in Laravel/Statamic per hour is insane compared to the Joomla ecosystem. So yes, there’s a cost involved; but also means I can be more productive, and do so much more for the client with the same amount of time.

Local development

When working with Laravel (and Statamic), Laravel Herd, a first party tool, gives you everything you need for your dev environment. Out of the box. Just like that. Yes, really. Look at Laravel Herd if you’re new to the ecosystem. Statamic’s docs will help you get set up with Laravel Herd.

Command line

Just like Laravel, Statamic comes with a CLI tool – Laravel’s is artisan and Statamic’s is please.

You can use this command line utility to help manage the site’s state (such as clearing the static cache or warming its stache, aka its internal cache), but also to scaffold different components of the platform including Addons, Tags and Modifiers.

If you’re a Laravel dev, you’ll know how useful artisan is – and please is just as powerful.

Deployment

Which also means the deployment process is just like Laravel’s, and can work beautifully with platforms like Laravel Forge (my choice) or Ploi – among others.

I’ll admit it too: when I was working on Joomla sites (and my own custom CMS because, yeah, we’ve all done that before), I was an FTP guy. FTP files up. 

Laravel (and by extension Statamic) doesn’t play this way. Sure, you can FTP, but you’re damaging your developer experience. Understanding how to deploy a site using a deployment script  will make your life so much easier, faster and reliable. And my favourite phrase: read the docs. Statamic can help you get started with a number of different deployment methods.

Composer

Coming to Laravel and Statamic from WordPress will have a learning curve – first and foremost is composer. This makes installing new packages a breeze, and helps with deployment. It means your site, stored in git (such as GitHub, Bitbucket, GitLab, etc), is just your code: when you deploy your site, composer is used that will install the required dependencies.

Before going on, the golden rule: never change files in the vendor folder. Changes made here can (and will) be lost.

Righto so we’ve talked about fast setups and command lines and deployments – but Statamic has more to offer for your developer experience too.

No database (unless you need it)

Out of the box, there’s no database.

But can be expanded to use a database if and when you need it – such as on a really large site, it may start to become advantageous. Actually, in writing this, none of our sites have used a database: they’re all flat file. And still fast and performant.

That means that by default, content is stored in flat files.

And before you go “but what about relationships?”, don’t panic (remember I said that earlier?) – Statamic’s stache is its own internal map between all of your content so you can still have related content.

For most of our sites, they’re small. And we keep them as flat files. And this gives us a massive tool from Statamic: git integration.

Automated git integration

When a client makes changes on production, these get pushed back to the site’s git repository. Which means that when I need to work on the site I can simply do a git pull and get the latest content changes. There’s no DB to sync, and this is ideal for teams working on the same site too.

It also removes one more piece of the server stack: with no database, there’s no DB server to manage and maintain, and one less point of failure.

This is such a timesaver for day-to-day work.

Performance

This belongs in the front end too – so a good segue.

One of my favourite features of Statamic is its static caching.

It can render a HTML version of each page, and then that can be served from the server without needing to recruit a PHP process.

Meaning it is lightning fast.

Oh, this is out of the box too.

During the setup, you will configure your invalidation rules so that as content is saved, some (or all) of your static cache is cleared so that your visitors always get the latest content.

I’ve also written a free addon – the Scheduled Cache Invalidator – which is useful to have time-sensitive content appear (or disappear) from your static cache.

Rich text

Statamic comes with Bard as its rich text editor, built on top of TipTap. It is one of Statamic’s many fieldtypes.

It stores its markup in a structured format, for nodes and marks, which means it can be manipulated and processed later.

Want to change how your p tags get rendered? Sure, change that one thing and all paragraphs can have the changes applied - you won’t need to go back and edit old stored HTML markup.

While the old way (i.e. TinyMCE, JCE, etc) is a HTML field with raw HTML access, it also is a recipe for disaster as one wrong tag can bring down your site’s layout. And authors are most likely not developers: so why get them to do code things?

Use Bard within a block to give authors rich text editing functionality, but build that in to the idea of a Page Builder and Sets (more on that later).

I’ve written an addon for TinyMCE for Statamic (it’s free) if you wanted to still use it. But switch that mindset away from old-school HTML editors to a more structured approach to content. Yes, it is different, but also cleaner and cannot be borked by your authors.

We’ve always been told to separate content and style.

Statamic allows us to do that.

If you’re using the Statamic way of doing things (such as Bard instead of a HTML editor), all of your content will be stored in a structured file, and has no concept of style.

Your templates are responsible for style.

And because they are stored elsewhere, change one template and every thing that uses that template - including content from years ago - instantly takes advantage of it.

Storing HTML with styles with your content just makes on-going maintenance harder, and makes content less resuable as your site evolves.

I’ll touch more on Gutenberg issues later, but this here is the true separation of content and style.

When you set up a new site, Statamic will have Tailwind and Alpine wired up ready to go with Vite. But you are not forced to use these technologies.

Statamic will output HTML for all of your content, and you can style it how you want. Tailwind, Bootstrap, SASS, LESS, straight CSS. Whatever you want: you do you. Statamic will not get in your way to do it your way.

Vite

So Vite, if you’re coming from another platform, this may be a foreign idea. Vite is a tool that runs as part of your deploy script, and bundles up your CSS and JS assets and prepares them ready for production. That’s the simple way to look at it: and is a whole topic in itself. Laravel’s docs are a great read.

And during development, there’s a hot reload mode that watches for file changes and automatically updates your site in your browser while you’re working.

That Ctrl/Cmd+R key can get a bit of relief now.

Templating

Statamic’s templating engine is Antlers – but can also use Laravel’s Blade if you prefer. Antlers is incredibly simple to get started with, and the docs are a great place to start. Throughout Statamic’s docs you’ll also see code examples for most usages (such as Tags, templating, Modifiers, etc) so you can see how it all works together.

The docs really are a superb learning tool.

What I really like about Statamic’s templates is the idea of “partials”.

In Gutenberg, when you add a block, it is HTML markup wrapped in some WordPress tags. And changing/extending can become more complicated than it needs to be.

With a partial in Statamic you can have the markup of your block, and inject the variables you need. Easy as that.

Have a new variable? Just update your partial and every block can take advantage of it.

Change of style? Change one partial, and all blocks of that type will update to use that new style.

Images

When working with images in Statamic, make full use of the Glide tag.

This will allow your authors to upload images – including that 8MB JPG image – and have Statamic be able to process that image to be suitable for the web, including next gen formats like Webp and a JPG fallback.

There’s a bit of setup needed here – and you have full control as to how you approach your responsive images – but the point is: that 8MB JPG image can be resized down on the fly (and cached for the next visitor to use) to a web friendly filesize.

You can even crop on-the-fly, and set a focal point to centre your crop.

Tailwind

If you’re new to Tailwind (and are coming from a straight-CSS approach), you may feel really unsure. Why would you write so much more markup, when you can write your own CSS to do more in less markup?

Sure, that’s true. But also you need to start naming things. What if you’re working with a team and you need inner and outer wrappers – is this the outer_inner_wrapper or the inner_outer_next_wrapper and what do they all mean? Different developers will have different preferences for naming. 

Tailwind takes this step away, and provides utility classes. Which make your class definitions longer – but also easier to understand what that piece of markup is doing.

If I’m working with Michael (another dev at Mity Digital) on a project, I can look at his code and see exactly what that markup should be doing – including responsively – without having markup and CSS open together. This makes it easy to understand another developer’s code, and not need to understand their nested naming conventions.

If you’re new to Tailwind, give it a go. And not just reading the docs: build something with it to really understand for yourself how it can work.

Remember I mentioned how fast it is to set up a new Statamic site using the CLI? And that you get Tailwind and Vite set up out of the box? So run statamic new my-playground and set up a new site to have a play.

This can also lead to leaner CSS files: Vite will create these for you, and if you’re using a padding value throughout your site, you only need that included once in your CSS rather than in each class that uses it. If you have thousands of classes, that could be the difference of thousands of lines of code.

Changing an experienced developer’s mind

Yes, Statamic (and Laravel) do things differently from how you’re probably used to with WordPress. Michael, a long-time Joomla developer, had a big learning curve at getting up and running with Statamic, composer, vite, npm, and all of these other new ideas: but now even he has zero regrets about making the switch, and also can’t believe how hard, fiddly and frustrating the older way (FTP, databases, plain CSS, etc) was.

This article is already a lot longer than I had anticipated - and this topic is a whole article in itself.

I touched on it in my Building maintainable sites with Statamic talk - but that is Page Builder and Sets.

I talked about splitting a design in to different horizontal slices - these become those blocks and partials I mentioned earlier.

You can also use Sets within a Bard field.

Sets too can be styled in the same partial approach - so you get all of the perks.

One is a block itself, and the other is a block within a block. The two are not mutually exclusive - but the combination of them gives insane possibilities for even the most complex of designs.

Statamic is different, yes.

Better, well, in my opinion, yes. But remember there’s no “perfect” CMS. But to me, Statamic comes pretty close for the type of work we do.

It gives us a superb developer experience for building and maintaining sites, plus a world-class authoring experience for our clients, and endless extensibility with its foundations on Laravel.

Coming from WordPress or Joomla, yes, there’s a learning curve. And there will be lots of foreign ideas thrown at you really quickly – even before you’re set up – but these ideas will help modernise your development workflow and improve your day-to-day work. 

Be patient, and take the time to get set up. Give Statamic a fair go, and approach with the right mindset: it is not a copy of WordPress, and doesn’t try to be. But it will give you such incredible power and flexibility, with a modern tech stack, and an incredible worldwide community.

And if you have any queries, or want to chat about it, drop me a line. Always happy to chat and help.