How digital agency Adapt innovates—without heavy-lifting

Tom Helmer Hansen
Software Architect/Developer
Adapt
03 Feb 2021

If you’re like most developers, you want to flex your creative muscle. Some days, you may feel more like a mad scientist, tacking together different pieces of technology in the quest to solve a challenge for a client or for your own internal stakeholders. Either way, Platform.sh projects provide a lab where you can experiment with not only new features, but with completely different frameworks and infrastructures to optimize your websites and web apps. Software Architect/Developer Tom Helmer Hansen of digital agency Adapt shares one of his latest CMS solutions, which combines Statamic on top of Laravel running on Platform.sh—without heavy-lifting.

Why not Drupal?

One might say I’m passionate about Drupal. I developed my first Drupal site more than 17 years ago. I’ve been involved with the Drupal community even longer, attending DrupalCon events around the world. I’ve also built around 20 Drupal sites, some with thousands of pages each. But in recent years, I’ve spent most of my time building APIs based on Laravel. I chose Laravel for a few reasons. First, along with the trend of building single-page applications, we needed a framework for the API. Second, some of my team members had used it successfully on other projects. And last, I just really like working with it!

Last spring, one of our healthcare customer’s Drupal 8 sites became due for a major overhaul, including a redesign and upgrade. With nearly 1.000 pages, the site has both integrations with React applications and with SOAP integrations. The straightforward choice, of course, would have been to upgrade to Drupal 9, make new content modeling, and migrate the relevant content from the old site.

But in the spirit of my university motto “In tranquillo mors - in fluctu vita” or “In stillness death, in movement life,” we decided to look for alternatives. Running on Platform.sh gave me the flexibility—and confidence—to change our software stack without any deployment or hosting concerns.

Deliver editorial workflows that make sense

Most sites we build have a large portion of non-CMS functionality, like integrations with SOAP services and maps. However, instead of choosing a CMS and implementing the additional functionality with modules/plugins, we chose to begin with the application framework, i.e., Laravel, then add a CMS package on top of it.

Since most website hacks are perpetrated through SQL Injection, I’ve been looking at flat-file content management systems that don’t use a database, so they eliminate most forms of automated attack.

In addition to daily editorial changes, our customer’s site has one major content update each year. So, beyond security benefits, a flat-file CMS would enable us to support a content workflow where the bulk change could be done on a staging site and deployed to production with Git.

I’d looked at flat-file CMSs like Hugo before, but found the editor experience unfriendly and content modeling too simple. Options like DatoCMS looked promising for editing the content for generators like Hugo, but we didn’t have the option of using a cloud service for the content.

Our major requirements looked like this:

  • Based on a well-known secure framework
  • Flat-file content
  • Editor-friendly UI
  • Advanced content modeling

After a survey of options for CMS packages for Laravel, we settled on the flat-file CMS Statamic. Statamic has a bring-your-own-HTML approach, so there’s no theme layer to override. Statamic Version 3.1 has GraphQL support, so it can be used with JavaScript-driven frontends like NextJS, but I’m not convinced that this would have been the right approach for this type of site.

inline

Bard, the Statamic editor, is based on the tiptap editor, built on top of Prosemirror —a structured format that fits in somewhere between markdown and full-blown HTML. With Bard, you can define your own custom field sets, which can be inserted into the editor. This approach resembles Paragraphs in Drupal or blocks in the Gutenberg editor, making it easy for the editor to add custom parts with some specific fields and related templating into the text flow of a page.

Our team created most of the site with built-in functionality like blueprints, navigation, forms, template engine, and media-handling. We’ve also developed some custom tags for the template engine and are using Livewire for dynamic pages, with integration to backend services.

Redis is used for caching in the application, Varnish to cache non-dynamic pages, and Elasticsearch as the search engine. Platform.sh makes it really easy to set up and use all of these services.

Overall, I believe we ended up with a secure solution with high usability, free from needless functionality that could compromise security. And this was accomplished while keeping both developers and editors happy.

You can connect with Tom via LinkedIn.