We Answer Your WordPress Block Editor Questions

Our recent webinar Gutenberg Full-Site Editing: Unlocking Agility for Enterprise WordPress showcased how we implemented the new full-site editing features rolling out in WordPress’s Gutenberg block editor. We had a slew of great questions from the live audience, many of which we didn’t have time to answer.

This post is a wrap-up of all the queries we received, answered by experts from the WordPress VIP team and Athletics, our agency partner who led the full-site editing implementation on wpvip.com.


How can we start using Gutenberg full-site editing? Is it a plug-in or a separate platform we need to move to?


Jameson Proctor: Gutenberg has been a part of the WordPress core since the 5.0 release. Full-site editing came to WordPress core in the recent 5.8 release. Given that we are in the early days of Gutenberg full-site editing, you may need to install the Gutenberg plugin to use or experiment with current and upcoming full-site editing features.

What’s the release time frame for Gutenberg full-site editing features?


Anne McCarthy: As a reminder, full-site editing represents a collection of features coming together to create the experience of editing all parts of your site. Because it’s a collection of features, the project has the ability to gradually release features depending on how stable and valuable they are, amongst other factors. The first full-site editing-related features were introduced in WordPress 5.8 with more features planned for future releases. There are various places to keep up with the roadmap. I’d recommend following the What’s next in Gutenberg? blog series.

How will the Customizer change for editing menus and other appearance items?


David Bowman: For now, the Customizer is still available through the theme selection screen in wp-admin, although most of the features offered there are being moved to the site editor where they can be more powerful and intuitive.A look at the wpvip.com homepage editor

Does this mean fewer last-minute developer requests or tickets to get something site-related updated or fixed?


David: Yes! That’s a lot of what we were solving for: identifying areas of our site where creators need more hands-on control and building that into our tool.

Was there a Gutenberg full-site editing release that you were targeting? For example, did you build for features that will be included one release away?


David: We weren’t targeting a specific core release. We’re planning on relying on the Gutenberg plugin for a while and adapting as things change and are refined. 

Jameson: That said, the full site-editing features we used in the initial release of wpvip.com made it into the WordPress 5.8 release. However, if you’d like, you could always throttle risk tolerance by staying up to date on WordPress core and Gutenberg plugin development. Targeting features that are on the roadmap for the next release will minimize risk and potential refactoring.

What was your risk tolerance for beta or alpha features that may or may not change significantly?


David: We had a very high risk tolerance. We’re invested in pushing the technology in an enterprise use case. We expect to need to refactor and change things as the technology develops. Hopefully, some of that development is coming directly from us.

What parts of the WordPress VIP website are still templated primarily in PHP because Gutenberg full-site editing is still a work-in-progress? Would you recommend approaching any new themes in this paradigm. Or is it not quite ready for everyone to adopt?


Jameson: In short, none. At this point, adopting full-site editing is an “all-in” proposition. There are discussions in the Gutenberg plugin development community of allowing for both PHP and full-site editing templating, but, last we heard, no decision has been made.

Is it possible to show an example of how the Design System was implemented?


David: The two main places where your design system integrates with your theme is in your block library. The new theme.json file that controls block-based themes. We leveraged the core global styles features to implement our design tokens in the block editor. 

Beyond styling and tokens, we’re treating our block library as a manifestation of our design system components. Because those are all built with React, we’re working to consolidate and componentize as much of that as possible as our system develops. Here’s a great roundup of resources.A look at the WordPress VIP design system

In terms of how lightweight it is, how does this compare to Elementor or Beaver Builder? Are there plans for dynamic block loading, i.e., selective JS/CSS on a per page basis?


David: The customizability of the block editor and blocks in general means you can build your theme to be as lightweight as you need. If your creators need granular design control, you can add that. If they just need options and styles, you can limit it to those. In an enterprise context, Gutenberg full-site editing has the potential to be a very different kind of tool than something like Elementor. Insead of a design tool that you use to build themes and pages with a high degree of granularity, an enterprise could use the block editor as a much more intuitive and customizable means of controlling their theme.

Jameson: We’d say the editor experience is as lightweight as solutions such as Elementor, Beaver Builder, etc., maybe even moreso. This is due in part to how native to WordPress core full-site editing truly is.

In terms of dynamic block loading, this can be achieved by the manner in which you construct your block library. It does require careful planning to avoid duplicate JS/CSS. 

For wpvip.com, in terms of CSS, we’ve begun experimenting with Tailwind Just-in-Time mode to create a minified CSS bundle with just the styles we need. In terms of JavaScript, we use tree-shaking in webpack to eliminate dead code from our JS bundles.

Is using Vue as an alternative to React possible to build blocks for Gutenberg?


Jameson: You can of course use Vue on the front-end, but, as far as the back-end of the blocks, you need to work with React.

Would you recommend creating a Gutenberg full-site editing theme, individual block plugins, or a block library?


Jameson: We recommend starting with building blocks at the post and page level then moving on to full site editing. The full-site editing template editor in WordPress 5.8 is now opt-in instead of opt-out for classic themes, so you can get started with blocks without “taking the plunge.” Either way, we generally create a plugin that houses all our custom blocks to pair with our theme.

Can you take a site that is already built and migrate over to start using Gutenberg full-site editing templates on that site?


Jameson: Your content is as portable as ever. In fact, you don’t even necessarily need to migrate—you could simply download or create a full-site editing them and switch to it.

That said, depending on the complexity of your landing pages, you may need to rework them to take full advantage of the power of full-site editing.

Is it possible to export Gutenberg full-site editing templates and import them into another site?


Jameson: As long as the blocks referenced in your full-site editing block templates and block template parts are present in your other site—either through a theme or plugin implementation, then your templates can be imported into another site. In fact, this is one of the enterprise use cases we’re really excited about—i.e., creating a block library and suite of templates that could be used across multiple sites and styled accordingly.

Wrapping up

Finally, this just might be our favorite question we fielded, as we know the subject is on the minds of both developers and content marketers alike as they contemplate the implications of full-site editing.

Is there a concern with content editors having too much control and potentially breaking things or publishing too early?

Jameson: The new theme.json implementation along with custom block settings allows product teams to “bake” a good deal of governance into the editor UI—thereby realizing a “tools not rules” approach.

As long as the blocks you allow your content creators to work with interoperate properly, there’s no greater chance of breaking things than there is with other solutions. We’d actually argue there is less of a chance.

By taking advantage of a plugin such as Edit Flow, your team can institute the appropriate scheme of checks and balances to keep content from being published too early.

More full-site editing resources

If you missed the webinar presentation, catch up by watching the on-demand replay here. And dive deeper into full-site editing with our companion blog posts Gutenberg Full-Site Editing Is Here—What It Means for Enterprises and How We Redesigned Our Website With the Full-Site Editing Features in the Gutenberg Block Editor.

Contributors

Jameson Proctor

Executive Digital Director, Athletics

Anne McCarthy

Developer Relations Wrangler, Automattic

David Bowman

Design Director, WordPress VIP