, ,

The block editor is still not a page builder

Another year, another ruckus from the page builder crowd complaining about the block editor. This current wave is in response to Kevin Geary’s recent video/post: I Tried Building a Layout With the WordPress Block Editor And it Didn’t Go Very Well– though if we’re being honest, I’m sure this tweet from Matt Mullenweg didn’t help.

I read Kevin’s article and watched (ok skimmed) the video. I think it raises some good concerns, but also rests on some false assumptions about the block editor. The problem is those false assumptions are not Kevin Geary’s fault, they’re the result of people trying to say that the block editor is a replacement for page builders. It’s not.

One of the complaints I heard online was that no one who uses the block editor ever responds to these criticisms or shows what the editor actually is capable of, so here goes. Before I start, I’m going to outline a few thoughts on page builders in general, then show (with a video) how I’d approach that pattern that was so hard to build.

What is a page builder?

A page builder is not just any old CMS that let’s you visually edit content- a page builder is a very specific “thing”. Yes, the block editor lets you visually edit content, but it’s not a “page builder” in the same way that a sports car is not a pickup truck. Yes, they both offer a similar experience (driving on a road/assembling “no-code” websites) but with vastly different features, intentions, and audiences.

In the block editor, one key concept has been restraint. Features are added slowly (often too slowly) and not everything you can do with theme.json has even been exposed in the UI. Features like block locking, a distinct font library, and partially-synced patterns are designed to further restrain the actual content editing experience.

If you want every single CSS setting that ever existed crammed into a airplane cockpit of panels and settings, that’s what a page builder is for. But that means that’s always going to be your editing interface, you’ll be opening up every single design option on every single element.

If you want to design a bespoke site, and then offer a heavily curated editing experience to a client or customer- where they can visually edit their content, but with some restraint- that’s the block editor. It’s why Nasa.gov and loads of other large publishers, enterprise-level orgs, and headless WordPress sites aren’t built using Elementor or Bricks. They want core WordPress with visual editing, but they don’t want bulky plugins for page building.

My point isn’t that one approach is better than the other- it’s that they’re built for different use cases. And I generally agree that people should stop creating the expectation that you can do everything you used to do in a page builder inside of the block editor. You can’t. And honestly, I hope it doesn’t come to that, because the current approach of building smaller atomic design elements (blocks and patterns) and locking them down inside a predefined theme (often only a few small files, including theme.json) is starting to get really good.

If you want to do extremely custom design completely inside of a theme-agnostic UI, then keep using your favorite page builder. But if you want to write or use a custom theme that offers an opinionated subset of designs and a nice visual editor, then use the block editor.

Building “that layout” in the block editor

So about that layout. I think it was a great example. It’s the type of layout that you tend to build pretty regularly. It’s not so advanced that it makes you nervous, but also not so basic that it won’t use any fancy CSS.

Using a different tool is hard. Nothing is as intuitive as the tools we are already using. If I had to build this in Elementor or Bricks, I’d probably be pretty confused too.

Rather than dig into the layout here, I’ve recorded a video of myself building the layout in the TwentyTwentyFour theme, no JavaScript, React, or custom blocks required. Along the way I try to focus on explaining a few things about the block editor. I don’t focus on matching the mockup 1:1 or on how I’d accomplish specific frontend/advanced CSS techniques. Instead I cover in no particular order:

  • What “alignment” and maximum content width means and why it’s important
  • How to make semantic elements like <section>
  • How to use flexbox controls in Groups, Rows, and Stacks to put content where you want it.
  • Why the block editor is good for developers making a (very lean) custom theme for a client- not for doing everything inside of a user interface
  • How to use register_block_style to add custom CSS that’s maintainable and user-friendly
  • How to save your design as a pattern and lock down the ability to edit the design.

Here’s the full video (keep scrolling to see a demo):

And finally, because we’re using the block editor, I copied and pasted the example layout from my local dev site to this blog post right now. (I do love being able to use native copy/paste to move blocks across sites and environments.) The site’s theme is actually Wabi, not TwentyTwentyFour, but this is the exact same HTML:

Thanks for reading and let me know if I missed anything important! If you like page builders, great! They’ll be around for a long time. If you want to build a more refined visual editing experience for content entry, consider the block editor.

11 responses to “The block editor is still not a page builder”

  1. Stephen Avatar

    hey man…solid work. I appreciate your response. I can see the intrinsic value of GB a little better.

    1. Brian Coords Avatar
      Brian Coords

      Thanks Stephen – I believe all these tools have a different value to a different set of users.

  2. […] The block editor is still not a page builder […]

  3. Casey Milne Avatar

    This was a great response, I enjoyed both the article and video. It really highlights the importance of calmly addressing concerns and acknowledging them. Snipping this excerpt as a reminder to myself and others: “… they’re the result of people trying to say that the block editor is a replacement for page builders. It’s not.”

    1. Brian Coords Avatar
      Brian Coords

      At the end of the day we’re all in the WordPress boat together- WP needs advanced page builders and it needs a great editing experience in core.

  4. jackbarron Avatar

    At this moment Gutenberg may not be ready for crafting a theme without code.
    But it beats any page builder if you’re blogging.

    1. Brian Coords Avatar
      Brian Coords

      I agree that the block editor is amazing for blogging. It does still require code but I find that most page builders also require custom CSS or else they require you to deal with a hundred panels that basically represent CSS properties. It’ll be interesting to see if page builders and Gutenberg get more alike or more distinct as time goes on.

  5. Miriam Schwab Avatar

    Your differentiation between the block editor and page builders is interesting.

    You mentioned the ability to lock things down more in the block editor, so I just wanted to point out that Elementor Pro offers the Element Manager that enables site managers to grant different levels of editing access based on user roles. For example, site managers can restrict access to the Editor altogether, or allow only certain types of users to make changes to the content.

    In addition, Elementor 3.19 (currently in beta) introduces the ability to hide certain widgets from the widget panel for certain website user levels to further control editing access.

    I’m pointing this out because these types of features indicate that page builders are also heading in a direction of greater control over editing permissions.

    1. Brian Coords Avatar
      Brian Coords

      Hey Miriam, Thanks for reading! I hope this article made it clear that I think there’s always going to be a need for builders like Elementor.

      The tools in Gutenberg for locking/controlling parts of the editor are still in their early stages as well. I’m curious over the next few years to see what features become common across all builders/gutenberg and what features are the differentiators or places that core just doesn’t want to go.

  6. Richard Hawkins Avatar
    Richard Hawkins

    This was excellent Brian, thank you…

    I think the following ticket (which I’m promoted as much as possible) would have saved Kevin about 10/15 minutes in his video. Certain key settings are too hidden in the block toolbar for a lot of users. From my own testing I’ve seen a lot of users overlook important stuff this way.


    1. Brian Coords Avatar
      Brian Coords

      Thanks Richard- I agree and hope you see some success with that ticket. Especially the example in the screenshot where the query loop settings are pretty randomly split between the sidebar and the toolbar.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.