The problem: a station that couldn't afford to go dark
KSER is a community radio station. Community radio doesn't get downtime, and it doesn't get a big IT budget either. When Freelock took over the site in 2013, it was already running on Drupal 5 -- a version that was already end-of-life by then, having been in service well past its own supported lifespan before we ever touched it. We tried to upsell KSER on a rebuild early in the relationship. The answer was simple: there was no budget for it.
So Freelock took the only responsible path available: keep it running, safely. Over more than a decade, we kept that Drupal 5 site alive, eventually moving it into Docker containers to isolate it from the aging PHP and OS versions it depended on. It wasn't glamorous work, but it meant KSER never had to choose between "pay for an emergency rebuild we can't afford" and "go offline."
That patience paid off. In December, KSER came to us with something rare: budget for a real replacement, not a patch. By then, though, there was a new wrinkle - a new station director had come on board, and he was already leaning toward moving the site to WordPress.
The turning point: winning back the platform, not just the project
WordPress was a real option on the table, and a reasonable one - a new director doing his own research and landing on the platform most people default to isn't a hard call to understand. Freelock's job wasn't to dismiss that instinct, it was to give him a better one. We made the case that Drupal CMS 2, built on the new Drupal Canvas page builder, wasn't the old, developer-gated Drupal he might have been picturing - it was a genuine alternative to WordPress for exactly the kind of editorial independence he was after, and one that would serve KSER better going forward.
Part of what made the pitch land was the deal behind it. Drupal CMS 2 hadn't even reached general release yet - KSER started on it while it was still in beta, months before the January 2026 launch - so Freelock didn't have production experience on the platform either. We structured the engagement as a mutual bet: KSER would be one of our first live Canvas builds, built on a pre-release version of Drupal CMS 2, we'd price the work accordingly, and in exchange we got a real-world project to learn the platform on before it was even final. KSER got a new site built on a modern, editor-friendly foundation at a price a community station could actually afford; we got hands-on production experience with the tools we were betting our future work on, and a head start on a platform most agencies hadn't touched yet.
For a small nonprofit newsroom-style team, the technical pitch mattered too. KSER's editors needed to build landing pages constantly - event promos, fundraising drives, program pages - without waiting on a developer every time. Canvas's drag-and-drop, component-based editing was built for exactly that.
The hardest problem: a stream that can't stop
KSER is a radio station first. Its website exists to get people listening, so the audio player isn't a widget - it's the product. That made the stream player the centerpiece of the rebuild.
The first pass came together fast. We used Canvas's built-in AI assistant to generate an initial working prototype of the player - a functional version in under 30 minutes. That's not the whole build, but it's a real head start: instead of scaffolding a component from a blank file, we were refining something that already worked.
The much harder problem was one that took more than a prompt: how do you keep the stream playing while someone browses the rest of the site? On a traditional Drupal site, every click is a full page load, and a full page load kills whatever's coming out of the audio player. For a radio station, an interruption every time a listener clicks to a program page isn't a minor UX papercut - it defeats the purpose of putting the player on the site at all. The old KSER site sidestepped the problem the way a lot of radio station sites still do: pop the player open in a separate tab or window, so the main site can reload without touching playback. It works, but it splits the listener's attention across two windows and never feels like part of the same site. We had a hunch that new browser APIs, built for exactly this kind of problem, might offer a way to solve it properly instead.
We solved it using the View Transitions API, the browser-native transition system now supported across modern browsers. Drupal already had a View Transitions module we could use as a starting point, and it was already built on HTMX - the library Drupal core has since shipped as a fully integrated, first-class part of core in 11.3. But out of the box, the module wasn't built for this: it still used HTMX to reload the whole page, just with a nicer animation on top. We reworked how it used HTMX to swap only the page content, leaving the audio player (and the site's styles) untouched and running. Playback never breaks, no matter how much of the site someone clicks through.
Because the fix built on infrastructure Drupal itself now ships with, rather than a hand-rolled, fragile AJAX solution, it isn't a one-off hack that breaks on the next core update.
The result
KSER now has a site built for how its team actually publishes - editors building their own landing pages in Canvas without waiting on a developer for anything beyond the components themselves - with a stream player that stays on the air no matter where a listener clicks. KSER's editors were never locked out of managing their own content; they'd been doing that in Drupal 5 for years. What's different now is how much more they can do themselves, and how much less friction it takes to do it. During training, one of KSER's editors put it plainly: Canvas was a better editing experience than WordPress. For a team used to Drupal's older, more developer-dependent tooling, that's the win that matters most.
It's also a case study in patience paying off - twice over. First, the decade-plus of quietly keeping an already-outdated Drupal 5 site alive and secure, long after most agencies would have walked away or forced an expensive rebuild. Second, the willingness to make a genuine case for Drupal again when a new decision-maker was ready to default to WordPress, instead of just taking the migration project and running. Both are why KSER had a website worth reinventing in December, on a platform built for how they actually work.
The technical stack
- Drupal CMS 2.0 with Drupal Canvas as the default editing experience
- Canvas AI for initial component/page prototyping
- View Transitions API, extending Drupal's View Transitions module for partial-page, style-preserving swaps
- HTMX, native to Drupal core as of 11.2/11.3, as the fragment-swap mechanism underneath the transition work
- Prior infrastructure: a decade-plus-old Drupal 5 site kept alive and secure via Docker containerization
