Weighing in on Gutenberg

Gutenberg is coming to WordPress. If you haven’t heard about it yet, you’re not reading enough WordPress news. 😉 However, for the sake of completeness, it overhauls the default content editing for WordPress. The new content editor is akin to stacking Legos simulating more of a page building experience.

How it Works

The Gutenberg experience replaces the word processor style content area with a block based content builder. The new design does a couple of things. First, it moves users more toward a WYSIWYG experience. The idea being that the more natural the tool becomes, the easier it will be to attract (and keep) new users. Gutenberg also creates a consistency in structure by presenting an adaptive workflow. Instead of having a big bucket that has to change with every type of content, developers will create blocks to handle the specific content they need.

This change also sets the stage for future development for how page templates and full site customization are going to be developed in WordPress. These are big changes, and there has been a lot of debate and some angst about what this means.

If you’re interested in getting involved with the project there are some great resources already in place. The development repository for Gutenberg shows the current activity and allows you to get involved if you have coding ability. If you find issues while using Gutenberg you can report them in the issue tracker. Finally there is a Gutenberg handbook that walks you through a lot of the concepts and structure.

How Does Gutenberg Affect My Site?

When we started looking at Gutenberg we wanted to focus on the details. As developers we needed to think about our client sites as well as our own properties. While we want to make sure this website and our AdSanity website are both able to transition beautifully, our focus is always on what we’re building for our clients.

Gutenberg is going to affect existing sites the most. There are going to be some functional changes needed. The most frequent area of change is going to be plugins. Many plugins address the content area in a variety of ways; short codes, meta-boxes, and other formats. With the new block system these plugins will need to change. Some key examples include Yoast SEO and Advanced Custom Fields (ACF). Yoast has already written an article about possible changes for Gutenberg. He also has developers working to address the new tool. The ACF team has also addressed their preparations for Gutenberg.

One of the tools that we often use on sites is Beaver Builder. In some ways a lot of the concepts that we’re seeing in Gutenberg echo the approach that we’ve seen in the way Beaver Builder makes a page. We know that the Beaver Builder team has been working hard to stay not only abreast but ahead of the changes as they are happening. They recently wrote a post outlining their take on Gutenberg. We’ll be keeping an eye on their progress.

Themes will also be impacted especially themes that have a lot of functional components to them like Avada, Enfold, or the X-Theme. The more places your theme touches your content areas the more issues may arise.

What Are We Doing?

Currently, we’re business as usual. We’re not changing the way we work or the tools we’re using at this time. We’ll be advising our customers about the upcoming changes and we’ll be maintaining our sites to the same standards we always have.

As the developers of a premium plugin, AdSanity, we’re also looking at adapting for our plugin customers. We don’t have a lot of interplay with the content area directly, but we do support a shortcode system. We’re looking at how we can adapt to Gutenberg and what positive changes we can bring to the plugin. We see it as an opportunity as opposed to an obstacle.

Don’t Panic!

Yes, things are going to change. However, you shouldn’t overreact to the news. There will be a change, but backwards compatibility is a major concern for the team building Gutenberg. Watch the development of the plugin on the repository as well as the Github repository.

This quote from the team should allay some fears – “While we want to make sure the new editing experience from writing to publishing is user-friendly, we’re committed to finding a good solution for highly-tailored, existing sites.”

There are a couple of recommendations that we suggest. First, we recommend making a list of all of your plugins and writing down exactly what functionality those plugins are providing. This is something we’ve always recommended. Dustin Meza gave a great presentation on how to approach this sort of inventory so ANY problems that occur can be handled easily.

Next, we recommend that you deploy your websites using a staging and production site process. You should not be making updates to a live site without testing on a staging site first. Ideally, you’ll be managing your entire process with version control. Even if you’re not, updates should be handled manually. If you’ve been relying on WordPress’ automated updating, you may want to consider disabling that for the 5.0 update. This isn’t something we recommend lightly as the security value of updating usually outweighs the break-fix concerns. Test all of your features on staging and then push those changes live.

As always, if you need help with your updates, or custom development to fix some functionality, feel free to reach out to us.