Featured Cover Blocks and the Future of Binding Data to Generic WordPress Blocks

Over the past year, I have been on a mission. I have eagerly awaited each release of the Gutenberg plugin, followed tickets, and chimed in when I could. I have been holding out some sliver of hope for one feature in particular.

I wanted to use featured images within a Cover block. That day has finally arrived.

In particular, my mission was to create the following layout entirely from the WordPress editor—no code involved:

Three blog posts stacked atop one another, each with the featured image as the background.

This was a part of a set of patterns I had designed for a faux photography portfolio in 2021. The general layout has long been possible in WordPress via the editor. However, it was not dynamic, which meant that each Cover block and its image had to be manually added instead of loading post featured images.

Two weeks ago, Andrei Draganescu added a pull request that changed everything. It implemented a toggle for the Cover block that allowed it to use the post’s featured image instead of a static image:

WordPress editor with a Cover block.  Highlighted in the toolbar is the "use featured image" toggle.
Switching the Cover block to use the featured image.

Two days ago, that enhancement landed in the Gutenberg plugin. It is expected to ship with version 13.0 next week.

I am unsure why I have been so obsessed with this specific pattern. It is not overly complex. Deep down, perhaps a part of me felt that when WordPress reached the point where I could create it from the editor, we would be at a place where anything was possible. In reality, I know that there is much more ground to cover and features to implement, but this still feels like a significant milestone that should not go unnoticed.

Even the pattern itself is not entirely possible via the editor. As shown in the following screenshot, there are gaps between each of the posts:

Query Loop block in the WordPress editor that shows the featured image for posts as the background of a Cover block.
Unwanted gaps between posts in the Query Loop block.

I had to cheat a bit and collapse those with CSS. There is a ticket to bring dimension controls to the Query Loop and/or Post Template blocks, but it has yet to be implemented. Theme authors must currently add a custom “no gap” block style to address the shortcoming, but the layout is now doable.

While I may be singularly focused on this particular design, the change opens a world of layout possibilities to theme authors. One style is to use the featured image as a background behind the site and post headers, as shown in the following screenshot:

A single-post view on the front end of a WordPress site.  It has a Cover image behind the site header and post headers.
Cover block using post featured image when viewing a single post.

That is now possible directly from the site editor.

I was able to recreate it in minutes by editing my active theme’s single template. I wrapped the Header template part in a Cover, toggled on the featured media switch, and added the Post Title and related blocks.

WordPress site editor with the single template in view.  The site header and post header areas are inside of a Cover block.
Cover background with featured image switched on.

This change will give some freedom to block themers that they have not had since building atop classic WordPress. Users will also be able to make their own tweaks to the output.

This enhancement is a win for theme authors and users. However, it also represents another shift that could create new possibilities for blocks in the future.

WordPress has a blocks problem. Those added by core alone are starting to overcrowd the inserter UI, and when you add a few plugins in the mix, things can become unwieldy. Many blocks are, essentially, variations on base HTML elements. For example, Post Title is merely a variation on the <h*> element, and WordPress already has a Heading block.

These variations duplicate developer efforts, create scenarios where each block supports different features, and often litter the interface.

Cory Birdsong opened a ticket in January that seeks to address this issue. His proposed solution:

Instead of making tons of individual blocks for this sort of thing, it seems like it would be better to create systems for using site/post metadata within existing generic blocks.

Reusing the post featured image seemed the most obvious starting place. Theme authors have long been clamoring for more control over its output, and the dedicated Post Featured Image block has been lackluster at best. There are tickets to bring the same “featured cover” implementation to the Media & Text and Group blocks.

With WordPress 6.0 landing next month, we will not see full-scale support for binding dynamic data to more generic blocks. However, it could have implications for the future.

What if, instead of plugin authors creating individual blocks, they could merely offer a switch to display content via a custom data source? There are certainly some use cases beyond core WordPress where this could be handy.

For now, at least, I am likely to spend the rest of the day tinkering with featured images and Cover blocks.

14

14 responses to “Featured Cover Blocks and the Future of Binding Data to Generic WordPress Blocks”

  1. One thing I haven’t seen mentioned is it possible to manually add an image and also toggle the featured image, so the manually added image would be used as a fallback when the post doesn’t have an assigned featured image?

  2. I hope Gutenberg can extend more by allowing developers to connect dynamic data to content of blocks, not just limited to the featured images. It will be very helpful like showing WooCommerce product price, gallery or showing data from custom fields like Meta Box.

    • Yes, there are several ways of hacking together something like that now via CSS and combos of blocks. Of course, there are shortcomings with all of them in comparison to a core standard that binds the data to the Cover block itself.

      For your current solution with the Group block, I would recommend using a custom block style. It would let you cut back on all the the nested selectors. Plus, the layout would be reusable, more so if offered as part of a pattern.

  3. Lack of dynamic data support is the sole reason why I cannot completely switch to Gutenberg. I await the day I can display custom fields/ACF data natively on Gutenberg without having to buy some premium blocks plugin.

Newsletter

Subscribe Via Email

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