It’s a bit of a cliché to say that technology moves forward so quickly that it’s difficult to keep up. In an agency environment we are, to a certain extent, protected from that rapid progress by our need to support our client’s tech-stack over the long-term and selecting the newest, shiniest thing often isn’t aligned to that.
It is important that we monitor trends in emerging technology to identify those things which are staying the course and might be more widely adopted. Not doing this would likely mean becoming stuck in a rut, delivering the same solution which over time becomes out of date and eventually the wrong choice – The iPhone 4S probably still works as phone, but you’d be annoyed if you’d been sold one this year.
In a busy client focused environment how do we test and learn more about a technology without risking a client’s project?
The challenge
As a team we’re well integrated into the Drupal community, many of the websites in our portfolio are built on the platform and we know it inside out. There are instances, however, where it might not be appropriate as a solution for a client’s functional needs or other consideration be that business driven or technical. To make sure we’re always able to provide the right solution to a challenge we must have a wide knowledge of other technologies that are production ready and widely supported.
Making sure we’re using relevant and modern technology makes sure our team is constantly challenged to enhance their skills and keeps them engaged with the excellent work they do daily.
Creating proof of concepts and evaluating technologies can give us a general idea of the suitability of it. However, these tests rarely come close to giving the in-depth insight we want before we’re confident in recommending it for client work.
Luckily, as a tech orientated company we develop a lot of internal tools that make our team’s lives a little easier and these internal projects give us the opportunity to really test out new software. When Logic+Magic rebranded in February 2024, it gave the dev team the opportunity to test the suitability of a new CMS by re-platforming our own website.
The solution
For this iteration of our company site, I was eager to evaluate Statamic. This CMS was first released in 2012 and today is running v5. It’s been on my radar since 2016 and drew my attention for two main reasons.
Laravel PHP framework
I confess, I’m a fully paid-up member of the Laravel fan club – I love working with the framework. The developer experience is excellent; it handles so much of the heavy lifting, getting an application up and running is so quick, and the surrounding ecosystem provides so much support.
Flat file approach
Unusually for a commercial CMS, out of the box Statamic doesn’t utilise a database. It stores all configuration and content in flat files. This intrigued me for a few reasons:
Security – Many website hacks are performed via SQL injection. This attack leverages vulnerabilities in code to access the database running the website – By not having a database, this attack vector is eliminated.
Performance – By removing the database from the architecture, network latency is reduced increasing response times. Though the files still need to be read from, I was interested to see if this improved performance.
Version control – With the right configuration it’s possible for all content changes to be pushed into the version control platform of your choice. Theoretically, this creates backups of your site that are easy to restore should you need to recover any changes or even the entire site.
These reasons alone gave us enough to think that Statamic might be a CMS useful to our clients and so we started development on the website.
Editor experience
Evaluating a new CMS means getting to grips with the editing experience as well as the technical and developer experience it offers.
As with all CMS, a lot of the initial learning is around the data structures that are the building blocks of a content driven website. Statamic provides collections, taxonomies to categorise content, and blueprints and fieldsets to design the forms and reusable components which give content editors flexible tools to build pages with.
Editors have access to everything you would expect from a modern CMS. Live previews of the pages being created increase the speed that editors can work. Content can be cross-promoted from different areas of the site, bespoke page layouts can be built with customised page blocks and there is a full media library with basic image editing functionality.
Ticking all the boxes so far.
Antlers vs Blade
The team behind Statamic have created a new templating language which is parsed to create the pages that render in the browser. Antlers is tightly coupled to their predefined content structures, offering handy helper functions for querying collections, filtering results and accessing content properties.
Coming from a Laravel background, some of the functionality is abstracted when compared to Blade and it was challenging to change our mindset to this design approach. Ideally we would have liked some customised control and access to the controller logic to make some changes, and found Antlers limiting at the outset. Perhaps more experience would help us understand how to be more effective with Antlers in future.
Hosting
After deploying the new site to a UAT environment, we found we were going to experience issues with one of the main features we wanted to try, the flat file system.
Our usual hosting provider uses containerisation and allows everything to be configured through files. Due to that configuration, the application filesystem is made read-only. This presented difficulties in managing the configuration of the CMS away from the development environment and made some key requirements impossible to implement.
To make sure editors and website visitors got the best experience we migrated the site to a new host. This wasn’t ideal as there was additional costs as well as having to manage another new service which adds complexity.
This change did come with positives though, it meant that we were able to evaluate another platform which has been of interest to us, Laravel Forge.
Glide
Statamic comes with Glide, an on-demand image manipulation library, to support a variety of different image use cases.
Using Glide, we were able to help content admins present content in modern image formats such as WEBP and AVIF and improve page loading speed, without having to worry about how to convert the images manually. It’s all handled in the site’s code.
Glide also aids user experience across all devices by letting administrators set focal points on images. Where images are resized on mobile devices the focal point makes sure the message being conveyed isn’t cropped on small screens. We can also provide different images to support art direction. Rather than reusing the same image across all devices it might be appropriate to provide completely different images to mobile or desktop users.
Static site
Though not a new concept, Statamic is one of the few CMS systems which provide out of the box support for static pages. We saw this as a way to really improve page performance for visitors and demonstrate our commitment to making sure content is delivered to the end user as quickly as possible without impacting the site’s functionality as a dynamic site.
Predictably serving static files to users, the response time is excellent when hitting a warmed cache. Usually, we see time to first byte around 50ms which gives the site a really zippy feel on all devices.
Time to first byte
Conclusion
There is a lot to like about Statamic as a CMS; it’s architecture, it’s scalability and it’s performance optimisation. From this evaluation, it probably lends itself more to being deployed as a part of a larger Laravel based application – a SaaS platform with a marketing site frontend for example.
The CMS is intuitive to use and is very visually appealing, but it’s limited to an extent by the lack of available add-ons and documentation. This likely as a result of its specialist nature, targeted at developers, when compared to WordPress or Drupal, but most additional requirements and integrations will need to be built from scratch, increasing development costs.
During the project we found ourselves abandoning the documentation at points in favour of looking directly in the code base for answers to implementation questions. This aided our knowledge of the platform overall but was especially difficult and time consuming when looking into the query builder. Some complex business logic, that should have been quite straightforward to introduce if it was database driven with Laravel’s Eloquent ORM, took time to find a solution.
Out of the box performance wasn’t great so we implemented static site cache. This poor performance was likely not having the right server specification in place at the time, and not optimised for the flat file system. Moving the hosting and implementing a full caching model really boosted performance and showed off Statamic's credentials.
The evaluation exercise was useful and allowed us to not only look at the CMS itself but also new hosting and infrastructure providers. Considering our overall experience of the build, at the moment it’s more of a solution to keep an eye on rather than recommend to clients for new builds.
Software Services Director
