Brother From Another Mother
An introduction to Statamic for Drupal developers
I've been building Drupal sites for most of the past 7 years. I've built sites for large Ivy League universities, small non-profits, and a few salt of the earth small businesses too. Drupal has always been my go to for building just about any website. The flexibility is truly empowering, and the site builder experience makes it quite easy to get lots of work done without writing any code. So why then, did an experienced Drupal developer choose to pivot and start building new sites using a different CMS?
While building Drupal sites over the past several years has transformed my career in huge ways, and I owe the Drupal community a huge debt of gratitude, I got hooked on web development after watching the famous Rails fifteen minute blog video:
While creating websites using a flexible and killer CMS gave me lots of room to learn, I wanted the developer freedom and tools provided by a Rails-like MVC development environment, which just doesn't exist with Drupal (despite how good Drupal's tooling and community are [especially Drush!])
Maintaining skills in two languages is hard
For a long time, I was trying to maintain both my Ruby/Rails and PHP/Drupal skillsets. I would do Drupal at work for our clients all day, and try to get our custom app developers to let me work on Rails projects with them, but there was always way more PHP work to do, so I didn't spend a lot of time with Rails. The context switching required a lot of investment, and that meant I just didn't spend a lot of time working on side projects and custom apps.
Laravel to the rescue
When I discovered Laravel, I realized I could continue investing in my PHP skills, making progress faster, while also getting to build truly custom applications, with a modern MVC framework, access to the entire flourishing PHP ecosystem (thanks to the introduction of modern OO features to PHP and Composer) and all of the tooling that came along for the ride (artisan, PHPUnit, etc)
But I still have to build websites
For a long time, I maintained a hard split, doing website work in Drupal, and building custom apps in Laravel.
This worked fairly well, I cross-pollinated ideas from Laravel/Rails into my Drupal work (and still do), but things like testing are still hard, and there is a lot of ceremony that goes into writing custom Drupal code that is verbose and time-consuming.
Statamic is a CMS based on Laravel
One of the first exciting things to know about Statamic is that it is based on Laravel, and since V3, you actually have a fully functional and accessible Laravel application with every Statamic site. If you're looking for the tooling and ecosystem of Laravel with the flexible CMS capabilities of Drupal, Statamic is the 'just-right' porridge you've been looking for.
If you need to do something that isn't standard CMS fare, you can simply create some routes, controllers, models, and views like Statamic isn't even there.
Likewise, if you are working on a Laravel app and need to add a CMS to manage content, you can install Statamic as a Laravel package and not have to maintain a completely separate CMS, but still get all the benefits.
Similar concepts
While Statamic has a different set of concepts than Drupal, they're actually more similar than it seems at first.
Building blocks
In the land of Drupal, you're very used to nodes, taxonomy terms, blocks, and content types as the main building blocks of any Drupal site. While many sites will incorporate concepts like paragraphs, field collections, panels, and other entities, Statamic has pretty much everything you need out of the box.
Nodes are entries
The concept of nodes more or less directly maps to entries in Statamic. Entries are backed by markdown files in the content directory, and they can be flexibly fielded using several concepts...
Content types...it's complicated
Statamic combines a few different concepts to create something that more or less equates to Drupal content types.
All entries belong to a collection, which allows you to group and query them, similar to creating a view of blog posts or products in Drupal.
Collections can be configured to use one or more different blueprints, which are structured field configurations. This means that a 'page' collection type in Statamic can be configured to use multiple different sets of fields.
You could have 'landing pages' and 'pages' be part of the same collection, but use two different sets of fields (and templates), or have multiple products that have different field data, but show up together as one list of content for iterating.
Field collections, paragraphs, and panels are fieldsets
There are a lot of competing concepts for reusable groups of fields in Drupal, Statamic has fieldsets. I tend to use fieldsets the same way I'd use paragraphs in Drupal. The 'hero' units on this site are fieldsets, and the blog posts and pages have a bard field that more or less lets you do similar things to WordPress' Gutenberg or Drupal's paragraphs. Those bard fields have 'sets' that map to the paragraph types in Drupal, or block types in Gutenberg, and the field definitions of the sets are created using fieldsets.
Fields are...fields
Fields are more or less the same concept in Drupal and in Statamic. You have the same flexibility here, and Statamic ships a lot of field types out of the box.
Blocks are...globals?
Blocks don't really have a simple equivalent in Statamic, but Statamic sort of lets you take care of this using globals and just plain old custom markup. many other things that you would do in a block in Drupal would probably be covered by running collection queries in Statamic, but at this point, most blocks I put on Drupal sites are one-offs that are fine to configure with a simple template with a few global variables to be replaced in Statamic (the social menu in our footer is a good example).
You can create groups of globals, so you can have a separate set for your site name, contact email, your social links, your favorite bands, whatever random stuff you would put in a custom block in Drupal that just needs to be placed in a single spot on the site.
Version-controllable config, just like Drupal
Just like Drupal 8+, Statamic stores all of its config in files by default, so you get all of the awesomeness of config management from Drupal without the need to constantly run import/export commands.
Speaking of...
Database? What database?
Statamic is completely backed by files (mostly YAML and markdown) by default. It's possible to hook it up to a database, but by default, everything is a file, including your users, your nodes, and your terms. This means every time you change something, config, or content, you get to see it in the git log immediately.
What will you do without views?
Drupal's views system is an extremely powerful tool that lets you build very complex lists of site content without code. Unrealist's Lauren Kelly can probably completely recreate all of Windows XP just using views.
Statamic has no views-like system, but the basic things you'd do using views are trivial using Statamic's template engine:
The above is how we display the blog posts on our /blog page, and a more complicated version sits at the bottom of each blog post to show related posts, using the filtering system.
Templates not themes
One of the best things about Statamic is the simplicity and productivity of the theming experience. This is mostly because Statamic has no concept of a theme, it just has templates and assets.
Themes are an incredibly useful concept for a CMS that is intended to empower non-developers to create beautiful websites while knowing very little about HTML, CSS, and Javascript.
For the professional web developer, themes are a layer of abstraction that interferes with their ability to take data out of the system and render it in the best possible way per the design.
Almost every site I've built over my professional career has been created from a custom design created specifically for the client property we were working on. In most cases, the theme system is slowing me down, forcing me to override my way to a decent result.
Just your markup
Further to the point, Statamic doesn't ship default field templates, node(entry) templates, term templates, or view templates. It's just you, you're data, and some elbow grease.
This makes custom markup a joy to implement because you don't have to fill your 'theme' with templates like this:
# field.html.twig
Wrapping up
There is a lot more to learn about Statamic, and quite frankly, we're still learning too. We'll still use Drupal for plenty of work, but for sites that we would have previously considered WordPress for in a search for simplicity, we'll likely reach for Statamic, as we have for this site. Have any questions about Statamic or looking for some help on a Statamic site? Give us a shout and we'd be happy to help.