Aha! Moments

Ever wondered about that initial spark of inspiration that drew in web developers to work with open source CMSes, like Drupal and WordPress? Follow along as Steve Persch, Director of Technical Marketing at Pantheon, walks down memory lane with his first Aha! Moments. 

Image by Stephan Cassara via Unsplash

The strengths of WordPress and Drupal that first hooked me 15 years ago can still have transformative effects on any mission-driven organization.

In my early 20s I worked in the non-profit theatre scene in Chicago. It was a tough time sandwiched between the recession of the 2000s when every performing arts organization struggled for attention and relevancy. What would the internet's growing hold on attention mean for a theatre company? Could we convince people to turn off their brand new iPhones for an evening to watch a newly written, unproven play?

Many of the theatre companies I worked with saw immense opportunity online. They didn't see themselves as churning out productions of staid classics. No, they made raw and exciting new works of art! And most of the people they could get to walk through the door were immediately hooked. The web presented an opportunity to spread the excitement of this work beyond the walls of the theater; to attract new audiences far better than an advertisement on the side of a city bus could.

Here are three strengths of CMS-based sites that I first leveraged 15 years ago. I wish these examples were still online, but read to the end of the post for some thoughts on how to build for the long-term.

Aha! Publishing Fast to Get the "Behind the Scenes" Work Out Front

When I first started interning at a major Chicago theatre company, its main website was a classic Web 1.0 site. Its flat-HTML content had basic information about the company, performance schedules, and a menu system that cracked under the entropy of manual updates. Making any changes required waiting on a days-long email cycle with a contractor who FTP-d up any requested changes.

If we were going to get with the mid-2000s zeitgeist of rapid publishing, we needed to do better. The first two professional-ish sites I created were in WordPress. One was a straight blog that allowed different performers and artists with the company to blog about their experiences in rehearsal and more. The second was an online version of the material we might otherwise produce for a play's paper program: interviews with actors, breakdowns of costume or set designs, and letters from the artistic leaders.

In just a few weeks with WordPress we opened a channel to connect with our audience that previously seemed completely out of reach.

Aha! We Can Interlink the History

Once I saw how easy it was to publish contemporaneous materials with new productions, I wanted to fill that in historical data. Chicago theatre companies more than most rely on founding myths, intertwined ensemble lineages, and they take their history very seriously. I saw that to represent all that information well, I'd need frictionless content modeling tools. Enter Drupal 5. 

For me in 2007, the "Content Construction Kit" and Views modules turned me into a magician for my coworkers. I could take the records of which plays had been produced when and where into a sensible relational database where every datapoint got its own webpage. Every production, every actor could get interlinked. Every stunning, high-resolution photo tagged the actors and the name of the show.

This cross-linking made a rabbit hole of past productions that any visitor might fall down — often in a way that would bring them to buy tickets for the following one.

Aha! I Can Reuse Code From One Site to Another

Once I built out a few content types, Views, and templates that worked well for one theatre company I found that they would work pretty well for another. They each had very similar needs and data types: individual performances connected to productions connected to seasons. For my clients I could deliver better results at lower costs, thanks to the architectures of WordPress and Drupal that prioritized the reusing functionality, along with the customizing of visual appearance. 

15 years later, Drupal and WordPress still prioritize this architecture. They are both extremely extensible in adding functionality from custom or community-maintained code with a theme layer for visual styling. That architecture can set up a site for long-term success.

Making Sure the Last Relaunch Is the Last Relaunch

Getting that long-term success requires more than an architecture. I wish I could time-travel — to tell Steve of the mid-2000s — to plan more for the gradual evolution of the sites I was making. I made those sites at a time when big-bang relaunches were the name of the game. The Drupal 5 and 6 sites I made in this era were wholesale replacements for decaying web 1.0 sites made in the pre-CMS days. And I really liked that feeling of building brand new sites. I liked it so much that I just kept going; making new Drupal 7 sites. Eventually those Drupal 5 and 6 sites I made in the pre-Responsive Web Design days needed to be completely redesigned and relaunched.

Now in the 2020s, both WordPress and Drupal are on stronger footing both technically and culturally. There's a growing recognition that doing a total redesign, rebuild, and relaunch project should be a last resort. 

With smooth upgrades from version to version, teams using WordPress and Drupal can always be evolving and building on past success in an agile manner. That's even easier with a WebOps platform like Pantheon handling details like CDNs and deployment workflows. Unencumbered by minutiae, a team can continue finding new "Aha!" moments and escape the dreaded website relaunch.

You might also like: 

Topics Development, Drupal, WordPress