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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Executive Digital Director, Athletics
Developer Relations Wrangler, Automattic
Design Director, WordPress VIP