dateo. Coding Blog
Coding, Tech and Developers Blog
Choosing Statamic over WordPress
Today's article is about a .NET developer gone astray, about delving into the mysterious worlds of web development and turning a WordPress site into something blazing fast. Let me share with you my journey of rebuilding the complete site using Statamic3.
Motivation
When I began to take technical blogging seriously (which really is only months ago), I took some time to think about a good way to host my content. There are several options out there that are trying to be the all-in-one solution for bloggers (think about Medium) - SaaS solutions, basically. I decided, however, that I wanted to give myself more flexibility in terms of extensibility, especially considering that I might want to use the site and its content for business purposes later on, and chose WordPress as the technology I would be using. I've worked with WordPress on several occasions during my private and professional life, and also my existing account on Strato offered a fair package including a WordPress one-click installation and a top-level domain, respectively. I was sold. Being able to write content as quickly as possible led me to choose the easy way here. Over the last few months, I learned a great deal more about WordPress and its inner makings both on my own as well as on my (partner's site)[https://whyld.one], and I also learned why will try never to make WordPress my first choice ever again in my life. So let me share with you some of the problems I faced with a Strato-hosted WordPress site.
The blog hosted on WordPress
WordPress is a content management system (CMS) that's been around since 2003. The earliest I have worked with it is probably 2006 and, honestly, the user interface hasn't changed much since. According to Statista the market share of WordPress is around 64 % worldwide at the time of writing this article. Maybe that is why WordPress is slow to change...
Let's go through some key aspects when it comes to WordPress:
Customization needs coding
There are many great WordPress themes out there that can get you started, but for anything slightly out-of-the-box or customized to your needs, you'll very likely need at least some experience with CSS, JavaScript and PHP.
Everything is a plugin
The basic functionality of WordPress is limited. If you want to have anything beyond simple plain text sites (proper theming, SEO, newsletters, caching, access rights, etc...), chances are you'll need to install a plugin for that. And there are literally tens of thousands of plugins to choose from - how is anyone able to pick the good ones from this? Also, very often, you'll run into compatibility issues when one plugin updates and conflicts with another one, when your PHP version changes, when WordPress needs an update, when... backup strategy? Well, yes, using backups. There are plugins for that, too, you know...
Heavy and slow
When everything is a plugin, you'll easily end up having one or two dozen of them for every beginner's page. As I said, even if you are not doing e-commerce, you'll need something for newsletter subscriptions, search engine optimization, cache and page speed, highlighting, code snippets, user access rights, advertisements, and so on. All those plugins, and the fact that there is a big database behind WordPress, tend to make your website pretty slow. Combined with Strato, I've had an LCP score of 3 to 4 seconds which is insanely slow. You guessed it, plugins help solve some of the issues here, but that can only be chip tuning. Metaphorically speaking, WordPress has a drag coefficient of a cube and no plugin will cover that up completely.
Database
WordPress is powered by a database from which content will be drawn and rendered into HTML files. Not only does that make things slow, but it also makes trying things out pretty hard. While there is a preview mode for any of your sites and posts, I've seen my fair share of broken landing pages when things hadn't actually been published yet. So, what's better than a database? No, it's not "two databases", but we'll come back to this later.
No development and staging environment
Especially when using one-click solutions, you'll have your production environment and that's it. To me, as a professional developer, since I know that I'll make a mistake eventually, I'd like it not to end up on the live site immediately. I'll sleep much better knowing that I can test any feature or UI change in a controlled environment. Of course, if you are self-hosting WordPress, you can spin up multiple instances and sync between those, but then you'll also go for a second (or third) database and things can get complicated real quick.
No source control
This again might not apply to any self-hosted environment where you'd be clever to source-control your website. I'm pretty sure that many of all WordPress sites available out there are not under source control. This is backed up by the number of backup plugins available. So whenever you crashed your site completely (guilty of that 🙋♂️), you can only hope for your backup to work correctly and restore a working state. That is not my favorite approach to software engineering in any domain.
There are a couple of other known issues with WordPress, so you might want to have a look at these, if you're interested.
For now, let's just say that I ran out of patience with WordPress quickly and was ready to move on to a different solution.
And also, if coding is involved anyway - why not learn something from it?
The blog hosted on Statamic
There are quite a few options out there that help you build your website using a CMS (or not using content management at all). To name but a few:
One could also go for a popular web framework and build their site as a web application using Blazor pages, Angular, or any of the other this-is-the-only-web-framework-you'll-ever-need things out there. And for absolute purists, Hugo and Gatsby are waiting for you to generate static pages with them.
So, how would you go about choosing the very best framework/technology/tech stack for your website or in my case: for me? Simply put: You can't. I can't. There are just too many options out there, and I have only so much time to evaluate my options. Yet, I'd prefer not to make a bad call, so it's probably fair to say that I took a decent amount of time to think about things I need and don't need and to weigh the available options against that.
In the end, Statamic is the CMS framework I went with. Here is what it is:
Basics
Statamic is a Laravel-based CMS framework powered by a custom templating engine similar to Laravel's blades. It is dev- and designer-first oriented, Git-powered and gives you pretty much every freedom you need when building your own website.
CMS framework
It is the starting point for your own customized CMS. It gives you everything you'll need but nothing more. With one of the themed starter kits available, you'll get example items/articles, a working administration panel and all the infrastructure you'll need to get going.
Dynamic PHP generation (front-to-back) until static
If you care for dynamically generated content, and certain features that require a "living" backend, you can fully rely on PHP as the engine. If you don't, you can simply generate static web pages from Statamic, giving your readers the fastest experience possible.
Flat-file, no database
Remember that database argument - what is better than having a database? Correct: No database at all. While you can hook up Statamic to a database (if you need to), it is flat-file by default. Meaning that every content item is stored as a human-readable file. Those files are of course version-controlled, you can mess around with them locally without destroying your production environment - it's Markdown and Yaml files. I love that.
Everything is a collection
To Statamic, everything is a collection. To me, thinking object-oriented most of the time, this is a relief. As .NET developer, I am used to thinking about things as objects. And multiple objects, obviously, are a collection. But what does that mean? Statamic allows you to define your own collection, with your own fields.
For example, articles can be a collection. Do you want this collection to provide a custom set of fields? You can do this in Yaml:
sections:
main:
display: Main
fields:
-
handle: title
field:
type: text
required: true
validate:
- required
-
handle: author
field:
type: text
validate:
- required
instructions_position: above
listable: hidden
visibility: visible
always_save: false
input_type: text
...
You can also do this using the admin panel while providing your site - your call!
Everything can be a collection. That encompasses newsletter campaigns, your pages, customers or subscribers and whatever else you might think of. Statamic is one of the most versatile environments that I have seen so far.
The final solution
The current state of the development and deployment process is made up of the following main components:
GitHub
The complete source code is source-controlled on GitHub. That is of course nothing groundbreaking. But that is still something that is difficult with WordPress. If you'll host a WordPress installation that is fully under your control, then that's simple. But most people don't and setting that up can become quite tricky. The repository is rooted in the main branch, where all production-ready code resides. Development is done on development. Frequent pull requests sync between these two. Statamic features Git integration itself so that any changes in the live environment can be automatically committed to the local branch.
Deployer
As a deployment orchestrator, I use Deployer. With this, I can define multi-step deployment processes like generating artifacts, ssh-ing to my production server, running package installations and updates and also running end-to-end tests. All this is configured in a global Yaml file. And while the documentation for using Deployer with Yaml file configuration is horrible, it has made my continuous deployment much easier.
GitHub actions
With GitHub, I can leverage the power of GitHub actions. There are two defined right now:
- For every commit on
developcontinuous deployment is made to a separate subdomain, on which I can test any features or changes to my site after local development and prior to deployment to production. - Once I am content with changes on staging, a pull request to
mainwill deploy the current version to production.
Developing own features
While Statamic is not free if you want to really go pro with its features, there is always the chance to build things yourself. Also, many add-ons will charge you for a bit of hard-earned money.
I am not a PHP or web developer, but by reactivating my ten-year-old PHP skills, I was able to build a few features completely by myself, like custom newsletter campaigns that can be templated using HTML and CSS and will retrieve their content from any of my collections (articles, in this case).
Core Web Vitals
Google is nowadays quite obsessed with its Core Web Vitals and uses these metrics to rank your site in its search results. Below you'll see the results from PageSpeed Insights for the current version - it has become insanely fast since I moved away from WordPress+Strato and towards Statamic+ManituHosting.
What if you're not into developing?
Like I said, Statamic gives you all you need to start, but nothing more. So if you are not into developing your own CMS all by yourself, you'll probably a developer to do that for you. But once that is done, you're good to go to work with your own, customized CMS like with any other pre-existing solution out there. I'd say even better still since this CMS can be customized to exactly the needs you (or your content creators) have.
Conclusion - what have I gained from this?
First of all, I have gained speed. And that means speed both in developing the site and my content (no more waiting on WordPress to load, render, preview, update plugins, etc.) as well as in actually providing it to my readers. At least I know how I react to a website not displaying the content I am interested in fast enough.
Secondly, my workflow can now be called a deployment strategy. I can develop, run, test locally without having to fear of breaking anything live. I can then deploy my changes to a staging environment and perform additional manual or automated tests. And then I can finally deploy to the live environment.
Thirdly, I have gained a huge amount of basic knowledge about what it takes to develop and host a CMS full-stack. I have extended my knowledge of HTML, CSS, Tailwind, PHP, Javascript, Deployer, GitHub, Laravel, Composer, Deployer, PHPTest, SEO, meta-tagging, and a few more. As I said, I am not a web developer, but having at least a rough understanding of these topics will be more than helpful in any tech job in the future.
And whether or not you like or don't like the design of this site, it is something that I built myself, including the features that do not ship with Statamic directly - and that is something to be proud of.
the journey is not yet over; there are still a few things on my list that I'd like to tackle. And also, if you happen to find something that is odd, if find a bug, or would leave a suggestion, please shoot me an email via the contact form.
For now: Goodbye WordPress!
Be the first to know when a new post was released