When Matt Mullenweg said to, “…learn JavaScript, deeply,” in December 2015 (almost five years ago, wow!), he was laying the foundation for the WordPress Block Editor, Gutenberg, which is being built in four phases:
- Easier Editing — Already available in WordPress, with ongoing improvements
- Customization — Full-site editing (FSE), block patterns, block directory, block-based themes
- Collaboration — A more intuitive way to co-author content
- Multilingual — Core implementation for multilingual sites
Three years later, Gutenberg shipped in WordPress 5.0, Bebo, during WordCamp US (remember the outcry?); and ever since, Gutenberg development has been happening at a breakneck pace. If you don’t believe me, check out the special page they built to help folks keep up. A few weeks ago, we saw the release of WordPress 5.5, Eckstine, which is a release that puts the finishing touches on Phase 1, including easier editing and a state of stability.
WordPress 5.6, (led by an all-women release squad), will primarily focus on Phase 2—customization. Some of the release goals include rolling out beta Gutenberg customization features into core, such as widgets, menus, and the customizer, adding support for PHP8, and shipping a beta version of the FSE experience in December 2020.
WebDevStudios & Gutenberg Get Off to a Rocky Start
The Block Editor has come a very long way in the face of incredible adversity, and the crowning achievement is that it’s reached a sane level of speed and stability. Here at WebDevStudios (WDS), we respect and applaud the engineering efforts by a community of countless volunteers, as well as engineers from Automattic.
I say “sane” because in 2017 and 2018, we tried to build a library of Gutenberg blocks in anticipation of leveraging the new block editor on client projects… and trying to keep up with Gutenberg development was insane. In the early days, our very talented engineers were frustrated because with every new release, they had to add more and more code to each respective block’s deprecated.php.
The rapid development cycles in the early days of Phase 1 required our engineers to constantly figure out “the new way” of building the same block. This was especially hard because documentation was (and still often is) only found in the firehose of Make blog posts, or worse, hidden away in closed PR on Github.
The insanity went on for about a year, and it was like trying to plug holes on the Titanic. Plug one hole here, and two more appear over there, until finally the WDS Blocks project was fully vertical, and there was no stopping WDS Blocks from sinking to the bottom of the Atlantic.
Exasperated and shivering cold, we said goodbye to Rose Gutenberg and postponed the WDS Blocks project until further notice. Internally, we decided to leverage both the Classic Editor and Advanced Custom Fields (ACF) plugins for building websites until development on the Gutenberg project had reached a more stable state.
Advanced Custom Fields to the Rescue
Let me start by saying, Elliot Condon and his team at Advanced Custom Fields have done an incredible job at adapting to the pace of Gutenberg development. ACF has brought a ton of business value to our company and projects over the years because we can build complex websites in 12 weeks instead of 12 months.
Initially, our frontend engineers loved that they could get right to work building things. There was no need to wait for backend engineers to create dozens of custom fields and data relationships. Backend engineers loved that they were free from “themes stuff” so they could focus on API integrations, custom plugins, and data migrations. Sales loved that we could build complex things fast.
Our “block” workflow was based on the Flexible Content field experience baked into our starter theme, wd_s, and eventually we adopted ACF’s new Blocks feature. The ACF Blocks API is wonderfully simple, yet undeniably powerful… and many of us felt like this API should have been how Gutenberg blocks are registered with WordPress. For the last several years, we have been shipping websites using the Classic Editor and Advanced Custom Fields, and until recently, our clients and engineers have been very happy with the results.
Trouble on the Horizon
Development on Gutenberg continued to march on, as did JavaScript’s popularity. In 2019, I was having my regular one-on-ones with the engineers and more and more the word “JavaScript” was coming up. To summarize:
- Engineers were starting to tire of building traditional WordPress themes and needed some new puzzles to solve.
- The meteoric rises of React, as well as Gatsby and Next.js, were hard to ignore, and the buzz surrounding these technologies felt very much like the buzz around WordPress 10 years ago.
- Some Engineers who spent their off-hours pursuing careers in JavaScript, said their goodbyes and left to go work in that space.
These three events started to plant seeds of doubt. Engineers need new puzzles to solve, and building site-after-site with ACF, while fast and efficient, had begun to lose its luster. It was also hard to ignore all the cool things other engineers were building with Gatsby and Next.js and sharing on Twitter. Potential clients were starting to inquire about using WordPress as a headless CMS. Finally, seeing your friends leave to go work with these new and exciting technologies cannot be understated; the gravimetric pull is real and it is powerful.
It’s my job to worry about these things and find a balance between engineer happiness, business value, and client success. Should WDS shove our collective heads in the sand and hope all the changes on the horizon go away? Or make a major change in our approach to building websites?
Goal: Be The Best Damn Gutenberg Shop Out There
By the fall of 2019, our COO, Lisa Sabin-Wilson, and I had been working on upcoming engineering goals for 2020. One of them was to research what it might look like to become a Gutenberg-first WordPress agency by the end of 2020. After all, JavaScript was here, Gutenberg was approaching stability, and full-site editing was around the corner.
Here’s what I came up with:
- Education—Level up the entire team with JavaScript, React, and Gutenberg training.
- Tool-Chain—Replace ACF Blocks with either native or custom Gutenberg blocks. Move our ACF Block library out of wd_s and into a plugin. Rebuild wd_s from scratch with modern tech. Leverage Block Patterns.
- Execution—Start building projects with our new education and tool-chain.
After a few weeks of discussions among leadership and coordination with the PMO department, I had a plan ready. By the end of January 2020, I announced Phase 1 of our plan to become, “The best damn Gutenberg shop out there.” The plan would happen in three phases:
Phase 1: Education (February 2020-August 2020)
The education phase would be split into three milestones:
Milestone 1: Training. Our engineers were to take JavaScript-focused continuing education courses from Tyler McGinnis, Wes Bos, and Zac Gordon during downtime.
Milestone 2: Build. After an engineer turned in course completion certificates, they had to put their knowledge to work by building a custom Gutenberg block and demo it.
Milestone 3: Contribute. When an engineer felt comfortable building custom blocks, they were asked to help with Phase 2 (below), blog about what they’ve learned, contribute to Gutenberg itself, or host demos and WDS Lunch & Learns.
I knew that sometime in the middle of 2020, Gutenberg’s Phase 2 would begin, so this gave the engineers about six months to train.
Phase 2: Tool-Chain (August 2020-October 2020)
Gutenberg-first means using native blocks. Building custom blocks in Gutenberg means a fundamental shift in not only how we sell a project, but how we engineer it. Instead of creating complex blocks in a matter of hours with ACF, we would now need several days or even weeks. With Phase 1 now complete, our engineers are armed with the knowledge necessary to pull off Phase 2.
I met with our Technical Strategist, Corey Collins, and did an audit of our library of ACF Blocks, and we realized that we could use core Gutenberg blocks to replicate most of them. We would only need to create two custom blocks: a Carousel block and an Accordion block.
We also talked about the WDS ACF Blocks library plugin he created back in March, and finally we met with our engineering team to discuss the pros and cons of our starter theme wd_s. Armed with this information and feedback, I put together a series of five two-week sprints.
Sprint 1: Both Darren Cooney, Lead Engineer, and Rebekah Van Epps, Senior Backend Engineer, volunteered to team up and work on building those two blocks. I would help by “blowing up” our WDS Blocks repo, so we could continue to develop those blocks publicly. The 2.0 milestone was created, and Darren and Rebekah finished up those blocks on September 4th and we shipped the 2.0.0 release today!
Sprint 2: This sprint has just started and involves extracting our library of ACF Blocks out of wd_s and into a plugin. Remember the business value I mentioned with ACF, when a client needs super-complex block functionality that would take weeks to build? We can install this plugin and leverage Advanced Custom Fields without destroying a client’s budget.
Sprint 3: This sprint means rebuilding wd_s from scratch. Our starter theme is used on every single project, and as a group, we decided that somewhere along the way, it had become a bit bloated. Engineers mentioned they spent a lot of time “tearing things down” before they could get started. The goal is to thin out wd_s and leverage third-party tech so we don’t have to maintain it. For example, use @wordpress/scripts instead of maintaining our own build scripts. Instead of trying to maintain our own library of utility classes, let’s use TailwindCSS.
We’ll also house Block Patterns in wd_s, which is an amazing feature that our clients have been asking about for years. Meanwhile, we’ll be keeping a very close eye on FSE and have already started to experiment with a block-based theme.
Sprint 4: Sprint 4 is all about QA/UAT and refinements. Before we start shipping client websites, let’s be absolutely sure they’re not going to break after the next release of WordPress or Gutenberg, which something other agencies in this space cannot claim!
Sprint 5: Finally, we get to documentation and training. We’re going to update our JavaScript coding standards, demo the tool-chain company-wide, update our process documentation—everything from the sales phase all the way through the support and maintenance phase.
Armed with the knowledge and experience gained through Phases 1 and 2, WDS will be ready to start building Gutenberg-first experiences for our clients that will be battle tested and stable.
Time Marches On
WDS was not the first to enter the Gutenberg space. That was a calculated decision not to build client websites on unstable software. It took some painful self-reflection and circumstances (like engineer happiness and client demands) for us to act. However, through pain comes growth.
These events are now woven into our storied history as a WordPress agency, which is on a quest to be… the best damn Gutenberg shop out there.
Comments