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

For the past year I have been on a mission. I looked forward to each release of the Gutenberg plugin, followed issues and participated when I could. I held out a glimmer of hope for one feature in particular.

I wanted to use featured images in a cover block. This day has finally arrived.

In particular, my assignment was to create the following layout entirely from the WordPress editor, without any code:

This was part of a set of templates I had designed for a false photography portfolio in 2021. General layout has long been possible in WordPress through the editor. However, this was not dynamic, which meant that each cover block and its image had to be added manually instead of loading posted images.

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

WordPress editor with a Cover block.  Highlighted in the toolbar is the
Toggle the Cover block to use the selected image.

Two days ago, that improvement landed in Gutenberg plugin. It should ship with version 13.0 next week.

I don’t know why I was so obsessed with this specific model. It’s not too complex. Deep down, maybe a part of me felt that when WordPress reached the point where I could build it from the editor, we would be at a place where anything was possible. In reality, I know there’s a lot more ground to cover and features to implement, but it still feels like a milestone that shouldn’t go unnoticed.

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

Query loop block in the WordPress editor that displays the featured image for posts in the background of a cover block.
Unwanted spaces between posts in Query Loop block.

I had to cheat a bit and reduce those with CSS. There is a ticket to bring dimension checks to Query Loop and/or Post Template blocks, but it has not yet been implemented. Theme authors currently need to add a “no-space” custom block style to address the shortcoming, but the layout is now achievable.

While I may be singularly focused on this particular design, the change opens up a world of layout possibilities for theme authors. One style is to use the featured image as the 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 featured image when viewing a single article.

This is now possible directly from the site editor.

I was able to recreate it in minutes by modifying the unique template of my active theme. I wrapped the header template part in a cover, turned 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 a cover block.
Cover background with selected image enabled.

This change will give some freedom to block themes they haven’t had since building on classic WordPress. Users will also be able to make their own edits to the output.

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

WordPress has a block problem. Those added by the core alone start overwhelming the inserter UI, and when you add a few plugins into the mix, things can get unwieldy. Many blocks are essentially variations of basic HTML elements. For example, Post Title is just a variation of element, and WordPress already has a Heading block.

These variations duplicate developers’ efforts, create scenarios where each block supports different features, and often litters the interface.

Cory Birdsong opened a ticket in January who seeks to solve this problem. His proposed solution:

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

Reusing the posted image seemed the most obvious starting point. Theme authors have long been calling 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 and text and Group blocks.

With WordPress 6.0 coming next month, we won’t see wide-scale support for binding dynamic data to more generic blocks. However, this could have implications for the future.

What if, instead of plugin authors creating individual blocks, they could just offer a switch to display content through a custom datasource? There are certainly use cases beyond WordPress core where this could be useful.

For now, at least, I’ll probably spend the rest of the day tinkering with featured images and cover blocks.

Comments are closed.