How we came to love Wagtail at Berkeley
When developers at University of California, Berkeley went looking for a Drupal replacement, they found Wagtail and fell in love with it. Here's why.
Why we sought to replace Drupal
The team I belong to at University of California, Berkeley (Berkeley) builds a few completely bespoke, CMS-driven websites each year to support the University’s fundraising efforts, major events, and special programs. Some recent examples include commencement.berkeley.edu, homecoming.berkeley.edu, and light.berkeley.edu. For close to a decade, Drupal was the team’s tool of choice for these projects, but that started to change around five years ago. These days we are all-in on Wagtail for any site that needs a content management system (CMS).
Many years ago, when I first learned Drupal, one thing that impressed me was how much site-building you could get done without writing a single line of code. Over time, though, I came to realize that this approach is very much a double-edged sword. It means the CMS has to be way more than a means to craft and edit content: It’s also a wide-ranging control panel for a site’s behavior. This makes it possible for developers — and in some cases, CMS users — to suddenly mess up a live site in ways that can be difficult to unwind. Each time this happened, I wished I was working with a stack that let me define my site’s behavior fully in code.
Maintaining our Drupal sites also proved unexpectedly frustrating. The Drupal community releases security patches for the core product and for community-supported modules on Wednesdays. I cannot tell you how many Wednesday afternoons I’ve lost to upgrading Drupal sites. It’s not that getting new code out to several sites is hard — it’s that there were so often unexpected, negative consequences to pushing these updates. And yet, getting patched very quickly was an absolute necessity. When the “Drupalgeddon” exploit happened in 2014, I had sites impacted within a couple of hours. We were far more vigilant by the time Drupalgeddon 2.0 happened in 2018 — but that it happened at all made us wonder what sort of foundation we’d been building on.
Drupal 8 reworked the framework significantly, but didn’t ease our pain. Meanwhile, the project itself seemed to pivot from being community-driven, geared toward all kinds of sites, and friendly to higher education, to being focused pretty squarely on turning Drupal into an enterprise-oriented moneymaker for its creator’s company. Feeling the community splinter, we started looking at alternatives.
How we found Wagtail
We don’t just build content-driven sites in our department. We also build custom web applications from the ground up. In 2016, we were tasked with architecting a replacement for give.berkeley.edu, which is Berkeley’s online giving platform. For a host of reasons — including the team’s strong preference for Python over the alternatives — we decided to build with Django. That experience was excellent, and we remain proud of the application we built. This happened around the time I was discovering that Drupal 8 didn’t feel like a good way forward. So I started looking at Django-based CMSes.
I distinctly remember test-driving Wagtail for the first time in 2018. What immediately got my attention was the StreamField. There was an equivalent in the Drupal 7 ecosystem, but it was so awkward for content editors to use, I hadn’t been able to see its potential. Playing with StreamFields in Wagtail, on the other hand, made me want to build sites with Wagtail! I couldn’t wait to get a Wagtail site into the hands of our editors and designers to see what they thought. Soon, I had that opportunity, and my colleagues were as thrilled with Wagtail as I was.
We have built close to a dozen sites in Wagtail since we made the switch, and are still in the process of redesigning and relaunching old Drupal sites as Wagtail sites. It’s all been for the best. Here are just a few things that make us happier developers since Wagtail became our CMS of choice:
- Security updates (mostly, the lack thereof). We’re off the Wednesday afternoon update treadmill! Django and Wagtail security updates are relatively few and far-between, and in four years we have not seen a vulnerability that might have actually led to an exploit on one of our sites.
- Extending Wagtail is a joy. Whenever we needed to write custom code to make a Drupal site do something unique, it was a slog — because both PHP and Drupal itself made some hard things very, very, very, very hard! It’s different with Wagtail. We have the entire Python and Django ecosystems at our disposal when we need them, which is lovely — but more often, we just code up some bog-standard Python in (for instance) a Page model method, and voila, we’ve just taught Wagtail to do something new. This is an immediate sort of flexibility we just didn’t have before.
- Our designers and editors love Wagtail! A couple of non-coder colleagues remember having broken Drupal sites by clicking where they “shouldn’t have.” They love that there are no dark corners of Wagtail where they can break things by clicking the wrong box. One colleague who has WordPress experience from a previous job told me, unbidden, “This is easier than WordPress.” I smiled at that.
- Our sites are now entirely defined by code. If something suddenly breaks, it’s because I’ve pushed bad code, which I can easily roll back. When I add a third-party package to my Wagtail project, I know that it won’t affect my front-end in any way until I integrate it, because the only templates that matter in the project are ones that I’ve written. And I absolutely love defining content types as Django models. It’s a brilliant way to work.
- Truly excellent documentation. I used to struggle with Drupal’s official documentation. Some crucial topics had skeletal coverage, examples were lacking, and especially after Drupal 8 launched, I encountered information that was simply out-of-date. As a Wagtail developer, I’ve spent a lot of time with both Django’s and Wagtail’s documentation. Django’s docs are the most comprehensive, well-organized set I’ve ever seen for a large framework. And Wagtail’s docs are very nearly as good. I have never — not once — found information in Wagtail’s docs that was out-of-date or inaccurate. When I need to know how to bend Wagtail to my will, I know that I can find what I need in the docs.
A while back, after our team adopted Wagtail, I heard Torchbox’s Tom Dyson on the Django Chat podcast. He said that Torchbox created Wagtail after discovering that Drupal was “a technology that was hard to love.” Hearing those words, I understood our team’s journey better. We moved from a stack that frequently made our jobs harder, to one that, four years on, we are still excited about. Wagtail empowers us to craft beautiful, responsive, accessible websites that are a breeze for content workers to administer and painless for developers to maintain. At Berkeley, we’ve found Wagtail to be a technology that’s quite easy to love.