My First Impressions using Statamic

Following Marty Friedel's talk at Laracon AU 2023, titled "Statamic for Laravel devs", I decided to give Statamic a chance and re-wrote my blog (this blog) to use it.

Here are my first impressions!

Since this blog is only updated by me, I'm able to take advantage of the free plan - which is for the most part only lacking in multi-language and multi-user features. Most everything else that you could want is included in Statamic's free plan.

What is Statamic?

Statamic is a merging of the words "Static" and "Dynamic". It's a very adaptable and extensible static site generator and CMS, with a back-end control panel that (in it's default configuration) stores all data in readable YAML files on the filesystem.

Even user accounts are stored as files, completely avoiding the need for a MySQL database! But MySQL is available for those that need it.

First Impressions

Here's an unordered list of my thoughts so far, after one day:

• The control panel is easy to use (positive)
• Organisational concepts such as collections, taxonomies and blueprints took me a while to become confident with - but they are powerful and well worth the slight learning curve (slight negative)
• The cost for the pro version is quite high, but if you're using Statamic for a client, you may be able to justify it by billing the cost to the client (slight negative)
• Fortunately, the pro version isn't necessary for single-user projects where you don't mind giving that user full administrative access, making it accessible for blogs like this at no cost (positive)
• Being able to easily crop and resize images, and to choose the focal point so those crops actually look great, is a GAME CHANGER (positive)

You'll Want To Use File Storage

File Storage over MySQL

By default, Statamic recommends using file storage rather than a MySQL database. This is a unique concept, but it works well. Every change you make can be tracked in the Git repository, so you effectively have version controlled changes to your Statamic site.

However, I did run into a related issue.

File Storage over Amazon S3

As soon as I started working with assets - in this case, images for the blog posts - I decided to store them in Amazon's Simple Storage Service (S3).

This worked well, until I got to the airport for my flight home from the conference and didn't have a reliable internet connection. Suddenly: I couldn't even load the site locally without exceptions being thrown due to lack of access to the network.

I switched the images to be stored locally instead, updated the blog posts to point to the new location, and that issue was solved. Lesson learned.

To get the most benefit, I ended up removing the .gitignore files that prevented files in the storage/app/public directory from being committed to Git. This allows me to write a blog post locally, attach my images, and commit both the blog content and images together.

Once it's deployed to production using Laravel Forge, both blog content and image are sent up as part of the Git repository and I don't need to worry about re-creating anything on production. For a personal blog, this works well.

Negatives of File Storage

Rather than changes occurring in a database, changes are made in flat files on the filesystem. The control panel provides a nice user interface to do this - but it does mean you're making changes to the source code of the site directly.

You can either use Statamic's pro version to benefit from Git integration right in the control panel, or you'll want to set up an automated task to occasionally commit changes that were made directly on production to the Git repository.

For local development, you'd just do a git pull to make your local environment match production: data and all.

Have you tried Statamic? What did you think?

Let me know on Mastodon or the PHP Australia slack community.

Take a look at my notes from Laracon AU, when Marty Friedel spoke about using Statamic as a Laravel developer: "Statamic for Laravel devs"