If your organization’s website runs on WordPress, the next upcoming release may be a shock to the system. After much ado and hand-wringing in the WordPress community, 5.0 will introduce Gutenberg, an entirely new interface for creating and editing posts. Not everyone is happy about it (with some even resigning over it). So should you be worried? The short answer is: no, but you need to be prepared.

What is the Gutenberg editor?

Anyone who’s used WordPress is familiar with the classic content editor — the big blank box in which to write your screed. Perhaps your brand team offers a handy set of guidelines for styling the content you dump into that big blank box, so you don’t run amok. You might even have a few custom fields to call out specific pieces of content, like the author’s name or other associated metadata.

Ultimately, though, that big blank box is a free-for-all. If you want to give the content inside it a specific layout, you need to manually format it. And if you want to repeat that layout in multiple places, it requires a clunky copy-and-paste job, or some custom code. That’s why most WordPress installations depend on third-party widgets and plugins to aid visual layout.

WordPress 5.0 aims to solve those issues. The underlying principle of the Gutenberg editor is to break content down into chunks that can be easily moved around and duplicated across posts and pages. It’s an attempt at competing with all those visual page builders now on the market, like Divi and Page Builder.

Cue Gutenberg blocks

Instead of a page containing one big blank box for content, Gutenberg breaks down a page into chunks, or blocks. Blocks are simply individual units of content—a headline, maybe, or an image, or a paragraph of copy. This allows you to structure and style your content at an atomic level. In and of itself, this feature isn’t particularly revolutionary. After all, you can already do that using short codes and css. But Gutenberg’s chunking makes it much easier to cluster these atomic components. For us content strategists, that’s basically in-line content modeling.

• You can cluster individual blocks into larger blocks. These larger blocks be dropped anywhere on your page.
• You can further cluster larger blocks into templates. When publishing an article, you might drop in your author template, consisting of a byline block, an image block, and a bio block.
• You’ll be able to (eventually) drag and drop blocks to arrange and rearrange page layouts to your heart’s content.

While this is all very cool, there’s some real controversy about whether the Gutenberg editor will succeed when it’s initially released.

Should you be worried?

The short answer is: no, but you need to be prepared. There are some real drawbacks to WordPress 5.0 that are causing consternation, concern, and ill will.

Updating may mess with your existing content

The reality is that upgrading to WordPress 5.0 without proactively updating your theme is likely to break a few things. “Gutenberg simply will break sites,” writes Iain Poulson of Delicious Brains. “This won’t be white screening, or breaking appearance on the frontend, but as soon as a site is updated to 5.0, a user will have a broken experience the next time they edit a post, if the site relies on custom meta boxes.”

In other words, Gutenberg will remove any custom metadata fields your current theme (including plugins) might include in the post and page editor. That means you’ll have to build new post and page templates in Gutenberg that mimic your previous ones.

From what I can gather, it doesn’t appear that Gutenberg will delete already-published content created with custom fields. If you ever want to edit those pages, however, it will likely delete that content as soon as you enter edit mode (since it strips out custom fields by default).

You could recreate any custom fields as blocks, but you’d need to have your already-published content backed up and then manually re-enter it using the Gutenberg editor. That’s just not tenable for large sites.

Existing plugins will need compatibility updates

Most major plugin developers are furiously working to make sure they’re compatible when WordPress 5.0 launches. But a lot of plugins simply won’t be compatible anymore. These include plugins that change the editing experience or functionality of the site, impact styling, or rely on shortcodes.

There’s no exhaustive source of truth for compatible plugins, but it’s worth checking Daniel Bachhuber’s initial Compatibility Database (no longer maintained, but housing info for 5,000 plugins). If in doubt, check with your plugin’s creator.

WordPress 5.0 has significant accessibility issues

Perhaps the biggest beef with WordPress 5.0 is coming from inside the WordPress developer community. The all-volunteer WordPress Accessibility Team has been working diligently to advise developers and test Gutenberg to ensure it meets the needs of everyone trying to access the web. Given that fully 30% of websites run on WordPress, this really matters. A lot.

We’re not just talking about people using assistive technology (although their experience will likely suffer when Gutenberg launches). We’re also talking about average users who might have temporary or permanent cognitive or physical challenges. This is, by some counts, one in five Americans. For these folks, the Gutenberg editor in its current state may be difficult or, in some cases, impossible to use.

In a recent report on Gutenberg’s accessibility, developer Joe Dolson describes a number of examples. Here’s just one (emphasis mine):

“Constantly shifting controls are confusing for screen reader users in particular, as they don’t get the visual affordance to know when something is no longer available in the interface. The classic editing experience was linear, contained within a single block. The controls were in a single fixed location on the page. This provides a predictability that is no longer present in the interface. This issue has been regularly reported by users of screen readers, but has not been effectively resolved.”

There are currently 90 open accessibility issues in Gutenberg, and it’s questionable whether or not they’ll be fixed in time for the initial release.

So what are your options?

WordPress 5.0 is currently scheduled to drop on Nov. 27 any day now (though this is very much subject to change). When it does, you’ll face a critical decision. You have several options:

1. Stay on the current version of WordPress

This is the old “if it ain’t broke” approach, where you stick with what you’ve got. Sticking with an earlier release of WordPress is fine for the time being, but eventually security will become a risk. Plugins and integrations that are current now are likely to become unsupported in the future, as their developers update them to run the latest versions of WordPress. Sooner or later, you’ll need to upgrade—and sooner is more recommended than later. I do not recommend this approach.

2. Upgrade to WordPress 5.0 and embrace the change

There’s a lot to be said for upgrading to the current version of any given software: generally speaking, current versions tend to be more stable (particularly .x versions released after the first major update). Just be aware that you need to audit your site content and potentially rebuild a lot of it. There will definitely be a learning curve for both site managers and content authors. If you have style guidelines already, you’ll probably need to revisit them given the new reality your authors will be publishing within. If you don’t have style guidelines, you’ll probably need to create some, so authors don’t feel totally lost. I do not recommend this approach.

3. Upgrade to WordPress 5.0 and install the Classic Editor

This is the solution WordPress is suggesting for teams that don’t want to switch to Gutenberg. It’s a somewhat controversial recommendation philosophically, because it’s really just a workaround and not a long-term solution. It also poses some of the same challenges as not upgrading WordPress at all. WordPress confirms it will eventually discontinue support of the plugin, rendering it obsolete in a few years. Despite this temporary solution, it’s the approach I’m recommending to clients at this time. That three-year window should (in theory) be enough time to bring Gutenberg up to snuff and allow site owners to integrate Gutenberg into their web strategy (or transition away from WordPress entirely). You can and should install the Classic Editor plugin now, before even upgrading to WordPress 5.0, so there’s no risk of accidentally converting to the Gutenberg editor.

4. Upgrade to WordPress 5.0 and disable Gutenberg

Developer Jeff Star is soundly in the camp of pros who intend to update to Gutenberg on his schedule, not WordPress’. He’s developed a free plugin that allows you to disable Gutenberg across your whole site, only on specific post types, or only for specific user roles. This is rad, because it allows you to move pages over to Gutenberg as you test and build, rather than having to test and rebuild everything, then convert it all in one shot. He also offers a tutorial for disabling Gutenberg directly in the codebase. Because I haven’t tested any of Jeff’s work, I can’t outright recommend it but it’s worth exploring and discussing with your development team.

Upgrading to WordPress 5.0 and Gutenberg: a content checklist

Let’s assume you’ve decided to embrace Gutenberg, despite the alarm bells and concerns outlined earlier. Or perhaps you’d like to eventually use Gutenberg and you want to start preparing your content now so the transition isn’t a hellaciously rushed nightmare. Or maybe you just really love to live on the bleeding edge, and be first at everything. Whatever your motivation, this is a fairly comprehensive checklist for you and your content team.

1. Prepare your live site

This may be stating the obvious, but this is absolutely the first thing you need to do.

• Back it up! All of it. All your content. If anything goes sideways, you’re going to hate yourself if you haven’t preserved a copy of your site content.
• Disable auto-updates by either tweaking your code or using a plugin. This gives you the opportunity to upgrade to WordPress 5.0 only once you’ve thoroughly tested it.
• Install the Classic Editor plugin. Are you detecting a theme now? Even though you intend to use Gutenberg, you want your live site protected until you’re ready to convert.
• Create a staging version of your website if you don’t have one already (or have your development team do it for you). This will allow you to test and break things without worrying about knocking your site out of business.

Once you’ve set up your testing area, it’s time for a little housekeeping.

2. Inventory your website content

I’m not talking about a traditional content inventory, where you document every single URL and identify various criteria. You don’t need to get deep in the weeds here. But you do need to understand how your content is structured and what elements you may need to redesign.

• Page layouts
  Your theme likely already uses page templates to layout similar content consistently. You’ll need to recreate these using blocks. Knowing how many templates you need to create, of course, will help you plan ahead.
• Content components
  Now take a look at each template and break it down into chunks. Are there common chunks, such as a header and paragraph pair? Maybe your cooking blog has a cookbook review template that always includes a sidebar featuring the book title, author, and price. These chunks are good candidates for new blocks.
• Content styles
  Document the visual style for each content component. ideally, you won’t need to manually restyle each block (because your CSS is clean and up-to-date, right?). But having these handy will help you check any post-update anomalies and quickly fix them.
• Media embeds
  Get a handle on how your site handles images, videos, iframes, and other embedded content. These, too, are good candidates for blocks. Alignment, accompanying headers or captions, and sizing can all be assigned at the block level so authors don’t have to mess with that stuff.
• Custom fields
  When creating new pages and posts, does your visual editor offer additional fields in which to enter details, beyond the big empty box you dump your content into? Perhaps you add an author or contributor name, A realtor’s site might have custom fields for street address, MLS number, or other details. It’s important to note all your custom fields and their behavior, as you’ll need to rebuild each one as a block (or, if they always appear together, as a single block). Don’t forget that different templates may use different custom fields. Note ‘em all.
• Plugins
  By now, you probably know what you need to do here. For each plugin, identify if the developer has a Gutenburg compatibility plan. If a plugin hasn’t been recently updated, pay close attention — contact the developer directly to find out. This is a great opportunity to reevaluate your plugins and make sure they’re still working for you. Do they add custom fields or otherwise impact how content on the site appears? You’ll need to pay close attention to these when you update to Gutenberg.

3. Install Gutenberg and start messing around

You actually have two options for this. The simplest approach is to install the Gutenberg plugin. But since you’ve set up a staging server, you might as well go all in.

• Upgrade your test site to WordPress 5.0 beta.
• Create a new post, and behold. Looks mighty different, don’t it? Don’t freak out. Just start playing with the interface. Remember: it’s okay to break things on your test site!
• Explore the interface, click on everything, expose all the different controls. Just get familiar with how it all works.
• Add some blocks to your page. You’ll discover that 5.0 comes with some common content blocks.
• Build some new blocks. Create your own blocks, save them, drop them into your page. Be sure to play with layout, as well as visual styles. Rearrange your blocks. You’re getting the idea now.
• Try creating new page templates using the blocks you just created.

Once you’re comfortable with the basics, you’re ready to mess with your existing content.

4. Audit your website content

Gutenberg won’t necessarily adjust your existing content automatically. However, if you turn off or uninstall existing plugins or page building tools, like WPBakery or Themify, you might find that content built with those tools behaves differently—or breaks or disappears altogether. That’s why we’re doing a thorough check of your site content before pushing Gutenberg live.

It pays to be systematic here, particularly if you have a large site or complex site architecture. Without editing any pages yet, simply start clicking through your test site. With your inventory next to you, this next checklist will look familiar.

• Page layouts
  Have elements shifted or disappeared?
• Content styles
  Are styles consistent for components like headers, body copy, captions, images, and so on? Do they adhere to your existing design guidelines?
• Media embeds
  Where do you have video, audio, iframes or other embedded content across your site? Do these elements still work?
• Functionality
  Do forms still submit correctly? Does calendar navigation still work? Are links fully functional?
• Plugins
  Do existing plugins still work? If not, you may need to check with each plugin developer to identify if and how they plan to accommodate Gutenberg.

5. Test existing content

Now we’re going to start messing with the existing content to see what happens when we edit it.

• Open a sample post in edit mode. For each page template you’ve identified in your audit, try editing a page that uses this template. Go through your audit list for missing content or unexpected behavior. You might find that whole chunks of content have disappeared. This is a huge red flag—you cannot safely edit this content on the live site using Gutenberg without the risk of losing parts of it! (Good thing this is your staging site and you’ve backed everything up on your live site.)
• Try editing any widgets you may have created to embed in individual pages. If your widget content is also impacted, you’ll need to recreate these as blocks.

6. Clean up broken content

With your audit complete, you should have a pretty good idea of the work ahead of you.

• Prioritize the fixes:
  • Stuff that breaks the functionality of your site should be fixed first. Since WordPress 5.0 changes a ton of code under the hood, it’s possible your development team will need to do some troubleshooting.
  • Stuff that messes with the structure of your site should be fixed next. This generally means building out all the blocks you’ll need, then assembling those into new page templates that will replace the old. With a plugin like Disable Gutenberg, you can leave the Classic Editor applied to less problematic pages while you tackle the big ones in Gutenberg.
  • Critical content should be added next.
  • Content that displays strangely should be fixed next.
  • Non-critical missing content should be fixed last.
• Test again before you push these changes to your live site. This should go without saying.

7. Creating new content: plan before you post

• Create consistent components
  If you have a style guide, consider creating repeatable blocks for each style.
• Create your page templates
  You can create a set of layout templates to extend the design of your site or blog, without having to custom code new php pages.
• Document your guidelines
  If anyone other than yourself creates site content, you’ll want to document the rules for how and when specific blocks or templates should be used.
• Train your team
  This may seem obvious, but most folks don’t spend enough time providing staff with the support needed to create great content. Set aside actual work hours, and give your authors access to the test site. Walk them through the changes, and have them create some new content.

If you’re a developer

• Take a stand
  By now, you probably have an opinion on whether or not it’s in your clients’ best interest to upgrade to Gutenberg. Don’t be afraid to share it, and explain why. You’re the expert, after all.
• Talk to your clients
  Don’t be afraid to send them here for the full context. If you’re advising folks to hold off on transitioning to Gutenberg, this checklist should help them understand what a commitment this is. It can be costly and time consuming to completely refactor a large site. If you want to make extra sure your clients can’t accidentally switch to Gutenberg from their Admin area, consider installing the Classic Editor Addon plugin in addition to Classic Editor. This hides the Gutenberg switch from them in their Admin area.
• Plan for different client scenarios
  Regardless of what you’ll advise your clients to do, you should still be prepared for the following situations:
  • Clients who want a preparatory audit (I can do these for you, though I’m currently booked through January)
  • Clients who don’t want to upgrade at all
  • Clients who want to upgrade but install Classic Editor
  • Clients who want to embrace the new editor
• Recognize when upgrading is appropriate
  There are two main cases where Gutenberg may be appropriate.
  • For brand new sites, starting out with Gutenberg might be a good idea. Unless you plan to move away from WordPress as your development platform, you’re going to need to upgrade someday. Trying to fight future updates just to stick with the Classic Editor will be an uphill battle. Starting new sites on Gutenberg will avoid the fiasco of having to transition later.
  • Websites in need of an update or redesign may also represent a good opportunity to move to Gutenberg. Site redesigns typically require information architecture (IA) updates, content revision, and new content creation. If you’re already investing in this work, it’s likely to be more cost-effective to integrate block design (which is essentially content modeling at heart) to these efforts now, instead of trying to transition to Gutenberg later.

Ultimately, only you can determine what’s best for your (or your clients’) website. If you don’t want to adopt an entirely new system, or run the risk of managing a potentially buggy and inaccessible site framework, you’d be wise to hold off. Turn off auto-updates, test your site on staging, then upgrade to WordPress 5.0 and install the Classic Editor. And if you have to live on the bleeding edge, be prepared to fix things as they break.