Decision Time: What Block Patterns Should Ship With WordPress 5.5?

Screenshot of inserting the Numbered Features layout from the block patterns library into the block editor.
Inserting the Numbered Features block pattern into the editor.

The first beta release of WordPress 5.5 is mere days away. This test release is expected to ship on July 7, and it carries with it a slew of new features that have primarily been developed between Gutenberg 7.6 and 8.5. One of the more pressing decisions the development team has to make is which block patterns to include in the final release.

For the uninitiated, block patterns are a predefined configuration of multiple blocks. They provide end-users a way to quickly insert more complex layout patterns into the editor. Instead of piecing together multiple blocks, nesting them within the proper group container, and getting everything perfect, the user merely searches the pattern library and selects the pattern they prefer. It is then inserted into the editor where the user can edit the content, such as altering the default text or changing the media.

It is an ingenious solution to an otherwise complicated problem. It also has the potential to move the block editor somewhat in the realm of actual page building.

For end-users, it could mean no longer spending hours learning how to recreate that pretty demo page that sold them on installing a specific theme. No more slogging through tutorials that feel like they were written for people with comp-sci degrees. Just click some buttons and watch the magic happen.

I have said that block patterns will change everything. I was patiently enthusiastic about the API when it first landed in Gutenberg 6.9. I was downright giddy to play around with the first patterns that shipped with Gutenberg 7.7.

Outside of a few that have made their way into Gutenberg in recent versions, I have not been particularly ecstatic about the default patterns the development team has included. In my mind, most were always test cases, patterns meant to iron the bugs out of the system. Then, some of the world-class designers we have in the WordPress ecosystem would design a handful of solid default patterns. I fully expect theme authors to push the limits of the system, but I was hoping that WordPress would use this opportunity to showcase what the block system can really do.

The closest that Gutenberg has come to shipping useful, modern block patterns have been its Testimonials, Numbered Features, and Features and Services patterns. These three were initially set on the chopping block (Testimonials have since been re-added), ready for the ax before WordPress 5.5 goes out to millions of users who could use such features instead of the tired and old solution of theme options. If these go, block patterns will likely land with a thud instead of the flash and bang the feature could make. We need to get users excited. We need to inspire the multitude of theme authors to build something greater — hey, look what you can do with this feature. Our development community needs to stand upon the shoulders of giants rather than feel like they are building from scratch.

We should not be afraid to be bold with the “1.0” of block patterns.

For the most part, with the latest patch on a ticket that is currently in flux, the team has nixed all but the least mundane patterns.

Block patterns are meant to represent common design layouts and configurations that we see around the web today. However, the current crop of patterns does not do justice to the idea. From the developer end of things, it is a powerful API. From the user side of things, it will feel like another half-baked plan to push in an unfinished feature before the deadline.

Maybe I am impatient. Maybe I need to get on board the ship-early-and-iterate-often train. But, the API has been in Gutenberg since November 2019. It is hard not to feel a little disappointed at the potential removal of the most opinionated patterns. They were the ones that I was eagerly awaiting to use. We can already easily put two images, columns of text, or buttons next to each other. The proposed patterns to ship with 5.5 do not feel like they will help users build the type of complex layouts the feature was meant to solve.

My rallying call, my plea to include some patterns with a little pizzazz in WordPress 5.5, might be cutting it close to the 11th hour. However, anyone eagerly awaiting this feature may have been as blindsided as I was yesterday when the pull request came down the pipeline to remove all but three basic patterns.

I want the narrator in the upcoming WordPress 5.5 release video to have a bit of pep in his voice instead of trying to give the hard sell on sticking two images next to each other.

I am not asking for complex pricing tables, a restaurant menu, or — God, forbid — a slider pattern. Those things are a bit more niche and not suitable for core. There is some middle ground we can meet, offering something of a bit more substance. And, if we cannot meet that middle ground, is the feature ready?

I’m the last person to suggest pulling the feature from the release, so I won’t venture down that dark path. I want block patterns. I want them now.

I do question whether we should ship such basic patterns with most users having to wait months for anything more useful. That’s unless their theme authors are generous enough to push out some new patterns between the major release cycles.

I am just a WordPress user asking to be amazed. Whet our appetites for a future where block patterns are everything.

What patterns would you like to see ship with WordPress 5.5?


9 responses to “Decision Time: What Block Patterns Should Ship With WordPress 5.5?”

  1. I believe this review on the release of block patterns is spot on! Great insight Justin!

    I use the newspack blocks plugin, and its homepage posts block is simply amazing. When I use this block it reminds me of what block patterns could do if only…

  2. I’m very new to the brave new Gutenburg way of things in WordPress and still finding my way around everything. One thing I’m not seeing is a way to handle responsive design decisions with blocks and patterns. For example, I’m forced to either clump images in a gallery that always places them side-by-side or atop one another, rather than being able to say “I want these side-by-side on tablets and desktops, but on mobile they really ought to be full width on their own”. The possibilities I’m seeing as I learn more are exciting, but my past experiences writing and modifying themes still have me feeling reluctant to dive in fully.

    • If your gallery is always placing images side by side instead of automatically adjusting to the screen size, that sounds like a theme issue. A four-column gallery, for example, should probably adjust down to two columns on typical tablet display and one column on a typical mobile display in portrait mode. Manual control of those things could become a burden over time as technologies and screen sizes change.

      With that said, I could see the argument for that level of control under some one-off situations where they are needed. But, typically, these are best handled globally on the theme level.

  3. None of them. The current solution assumes everyone will want to use block patterns all the time. As I wrote in

    It would appear to me that the current API for registering, deregistering and rendering block patterns is rather inefficient.
    It could benefit benefit from lazy loading, separating the rendering logic from the registration.

    If the API is not improved, sooner rather than later, then I envisage significant bloat when plugins and themes start adding their own Block patterns and categories.

  4. Outside of a few that have made their way into Gutenberg in recent versions, I have not been particularly ecstatic about the default patterns the development team has included. In my mind, most were always test cases, patterns meant to iron the bugs out of the system. Then, some of the world-class designers we have in the WordPress ecosystem would design a handful of solid default patterns.

    Hi Justin. Thanks for your thoughts on this, I also feel very strongly about patterns and their potential! You are correct the initial patterns included in the plugin were meant to test the APIs and interface more than anything, that’s why now upon the decision on which to include in core a few are being taken out. I’d classify patterns into two groups: those that offer convenience (already assembled columns, multiple buttons and images, etc) which can be more mundane and those that offer neat design starting points. I would also like to see more of the latter and feel we are barely scratching the surface on it.

    The lack of good and diverse imagery that could be bundled has been a bit of a challenge for designing broader patterns to include in core. The overall quality of these designs would also color the first impression of WordPress for many users, so I feel it’s important to put a lot of craft into them going forwards and be confident in their quality. One advantage is that the nature of patterns makes it easy to iterate on them — update, add, remove — building up towards a better collection. As you also said, I do expect themes to push this whole frontier forwards — already seeing some bundling more design-opinionated patterns fitting with their aesthetic, which is really cool. As to which would be bundled in core, I think it’s going to change over time, similar to how the default themes change, and as we learn more about their use. Once we get into the next cycle of default themes for this decade, I’d expect each new theme to also contribute their own patterns and experiment more with the feature. It’d be great to incorporate more design diversity here as well.

    Perhaps once a directory for patterns can be fleshed out, core might not ship with many patterns itself leaving it more open to designers and theme folks to contribute and curate through the directory and with much shorter cycles than core releases can afford. It’s also the case that some of the more opinionated ones have been a bit unrefined in design or structure (even for the Testimonial one, which is going back and forth, it’s not great that the markup is relying on a Paragraph block and not on a Quote block, so wouldn’t want to promote a pattern that might lead to users having less semantic output).

    Finally, please, do keep this feedback going! It’s super useful to see what different people are finding more compelling or useful among the bundled patterns as these are still being discussed for the upcoming 5.5 betas, where the broader testing and feedback loop should help decide which to include.

    • I’d really love to see the next default theme ship some custom patterns. That’s something to look forward to.

      I haven’t even thought about a potential pattern directory. That is an interesting idea. The developer half of my brain is already spinning right now, trying to figure out how feasible that is and what might need to be done to make it happen.

      Thanks for the feedback on the semantics issue with testimonials. I had not actually looked at the underlying HTML. That is a problem. I agree that I wouldn’t want to ship it without that being cleaned up first.

  5. Justin

    I think you’re take on Block Patterns is spot on. I’m not a designer yet I can create my own templates that are much more inspiring than what we have now in the BP library. If this isn’t done right – and right from the first release – this is going to back fire badly. Did I hear anyone say, “Post Format?”


Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

%d bloggers like this: