How agencies are handling the transition to Gutenberg- A conversation with In The Loop

The road to block editing in WordPress has been a long one. From the agency perspective, where you are on that road depends on a number of things, from target market and client budget range to personal experience and developer skillset. Stepping away from many of the familiar tools of building in WordPress- PHP templates, actions, filters, and functions.php files- requires a healthy budget of time spent just learning. Learning something new can be exciting, but it can also be frustrating and time-consuming. It eventually needs to pay off, unlike all the time I spent learning to play the trumpet in the high school marching band. One of the benefits of WordPress is that often someone else has gone there ahead of you, and there’s a strong ethos of sharing what you know so that others may follow.

That’s been my strategy on block theme building in general- wait for much smarter people than me to forge ahead, so that I can learn from them. And in the last year, I feel like we’re starting to see many of those names coming out and some ideas around best practices are emerging. Many of the smart people in block-editing are sponsored by hosting companies, a welcome group for sure, but with a different day-to-day experience than what Matt Medeiros once called the “blue-collar digital worker“, those of us in the agency space cranking out WordPress websites like widgets. I appreciate all of the developer advocates sharing their knowledge, but often their specific use-cases didn’t apply to my day-to-day work.

I wanted to know which WordPress agencies explored deep into block territory and were not just creating those beautiful showcase themes you might see in the theme repository. I’m talking about custom websites for clients, typically matching a pretty rigid design, with as much as possible happening inside of the block editor. While there’s been some great resources just coming out of the larger companies- 10up and HumanMade come to mind- the names that kept popping up in my feed were Cory Hughart and Phil Hoyt from Blackbird Digital. 

If you’ve never listened to their podcast, In The Loop, I highly recommend it. They’ve had amazing guests over the years, and this recent deep dive into hybrid/block theme building (along with the followup conversation with developer advocate Ryan Welcher) is probably what brought us together. As Cory mentioned in our conversation, “the entire run of this podcast [has been] about Gutenberg and the effect that has had on our work as a custom WordPress theme and plugin agency.” It serves as a transparent historical document of an agency in transition, having the sorts of conversations that many of us have internally with our co-workers when we want to try new things.

The central question of our conversation, in Cory’s words, sounds something like “Is there a ‘right way’ to develop custom themes for clients with Gutenberg, or is that up to us to figure out?” The three of us sat down on mic and had a great conversation about what it feels like to use the block editor for clients right now, not just five years ago (when it was rough) or five years from now (when it’s hopefully a fully-featured tool). 

Hybrid – A Response to Block vs Classic

The conversation started because of our article deriding the Block-vs-Classic construct in WordPress. I take issue with the idea that developers have to live on one side or the other, either stuck in ye olde classic theme land or living on the cutting edge of block editing. Cory and Phil agreed, and most of what they showed me was how they’ve blurred the line between old and new ways to build WordPress sites. Phil explained:

We definitely experiment quite a bit here. It’s been a very interesting couple of years, especially these last two years trying to build WordPress sites with the Gutenberg editor. We don’t call them classic themes, we very much call them hybrid themes. The header and footer are the most boring aspect of the site. That’s mostly PHP and the middle part is mostly Gutenberg, the block editor.

This resonates with me, as it’s been the header, the footer, and maybe custom post and archive pages that have given me the most headaches in the block editor. While the promise of true visual editing feels very appealing, you can often save your clients a lot of time and money by relying on tools like Advanced Custom Fields to throw together solid, reliable backend settings areas for even the most complicated landing pages. “If you’ve used ACF long enough,” jokes Phil, “you’ve accidentally created a page builder.”

“A bad one,” adds Cory- an experience I can deeply relate to. Rows and rows of custom fields starts to feel like a slog. And yet, we were all pretty bullish about sticking with Advanced Custom Fields in the future- especially when you consider using their ACF Blocks instead of writing custom Gutenberg blocks in full-on JavaScript. The heavy reliance on JavaScript has been a major barrier-to-entry for a lot of developers, and ACF Blocks is probably the big transition piece you’re looking for.

Phil went on to talk about how they’re incorporating more PHP back into their workflow, and some of the new tools for dynamic blocks and block template parts are enabling a more integrated approach. As the dust begins to settle on the newly christened “Site Editor”, I think they may be on to something about the hybrid theme via the combination of PHP and block editing. So how do we establish the boundaries between classic and block? This is where I get hit with decision paralysis.

The decisions beneath each decision

Let’s take one example. “One of the biggest sticking points,” explains Cory, “is this idea of data entry.” One of the most common examples would be a custom post type that really just needs a lot of specific fields added or updated regularly, such as a list of books in a library or events on a calendar. There’s no need for a main content area and there’s no classic editor, just a ton of custom fields that extend across hundreds of entries, fields for titles, dates, meta information, etc. 

While you could build this in the block editor, showing custom field “blocks” on the backend and a templated layout on the front-end, the question is should you. “Most of the time,” he continues, “[clients] are looking to pare down the interactions they have with the website as much as possible, as fast and easy as possible, with as little human error as possible.” This often means foregoing the more visual appeal of the block editor and relying on tried-and-true custom fields that function and feel like a traditional “content management system.”

But when do you use blocks and when do you use fields? These questions- and a lot more- build up to the complicated series of decisions that every developer has to make when incorporating more of the block editor into their workflow. When should you use PHP and when should you use JavaScript? Which templates should be editable by the client? Which blocks should be locked? When should I create a custom block? Will it be a degraded user experience to send them digging through the “Appearance” menu to modify their navigation or footer? How can we minimize their effort without maximizing our own? And once these decisions are made and tested, how can we help others learn from our efforts?

The Future-proof Framework 

Because our team here is responsible for Understrap (the popular WordPress starter theme that uses Bootstrap to speed up development) we spent some time talking about theme frameworks for the next decade of WordPress. We’re constantly thinking about the block editor, the classic editor, and all of the places in between, and determining where a design framework like Bootstrap can fit into the block editor.

One thing that makes Bootstrap components so appealing over WordPress blocks is the documentation. It’s pretty easy to point a new developer to the Bootstrap documentation for lists or border-radius utilities. In contrast, overriding Gutenberg’s design components and default assumptions still requires a lot of trial and error that has to be repeated over every project. New hybrid theme frameworks and scaffolds can hopefully help light the path towards best practices.

Cory and Phil have been developing their own bespoke theme scaffolding openly on Github, and I was able to take some time digging around inside of it before our conversation, mainly so I could steal learn from their approach. While Understrap will be updated and supported for the classic/hybrid approach for many, many years to come, as we discussed in our conversation, “WordPress has decided that they’re going to be a UI framework.” This means that, depending on the type of site you’re building, many of the benefits of Bootstrap become redundant or lose their appeal. WordPress is rolling its own Bootstrap, in a way. This means that design decisions are now being catered to the limits of the editor itself.

Speaking about the role of shifting role of design constraints in theme building, Phil explains even more: 

It’s a complete paradigm shift, for sure. Every developer got to ‘choose their own adventure’ in the past- create your own, Bootstrap, Tailwind- and now all of a sudden we’re kind of beholden to a lot of decisions that were made without our knowledge.

This has been my biggest area of exploration recently: in a post-Gutenberg world, what would be the best way to build a developer-focused theme framework with all of the benefits of an Understrap (speed, stability, utility, etc)? While Understrap has very solid support for block editing, there’s eventually going to be more conflict between the two distinct frameworks, or at the very least a ton of unnecessary CSS being loaded when you have two completely unique utility libraries. Of course, you can just continue building WordPress websites the way you always have, but if you do want to put that visual editor into your client’s hands, can you?

The conversation continues from there and I was left with even more underlying questions and decisions to be made, each with their own trade-offs. As Cory points out, it really is up to us, the WordPress community, to figure out the “right way” to build a custom WordPress website going forward. And of course, there’s not just one “right way.” Understrap was a very different approach than say the Genesis Framework or even Sage. And there’ll be different approaches going forward that appeal to different development agencies. I’m excited to see what radically different approaches others might take.

All in all, it was a wide-ranging conversation that certainly doesn’t solve every problem WordPress developers are having, but one that I hope resonates with others as we crowdsource our way to the next generation of websites built with WordPress.