The Block Bindings API Brings Dynamic Data to Blocks

As the block editor continues to evolve its content management capabilities, the lack of support for custom fields has been one of the key roadblocks for users and developers. While custom fields in WordPress are still widely used, in the block editor they’ve been relegated to a drawer at the bottom of the screen, and haven’t been as deeply integrated as many would like. With the coming Block Bindings API, things are about to change in a very good way.

What is the Block Bindings API?

One of the best ways to explain the Block Bindings API is to start with a plugin like WooCommerce.

Imagine you are building your WooCommerce store and you’re designing the homepage of your site with blocks. You’re using a Query Loop to display your most popular products, which means many of the blocks you’ll be reaching for are probably pulling important custom information about your products- product descriptions, images, galleries, add-to-cart buttons, and more.

Right now, WooCommerce needs to create and manage individual custom blocks for each of those separate pieces of content. That’s a lot of duplicate code and technological overhead. Plus, as new design tools are added to the block editor, the development team has to go back each release and make sure their custom blocks can support new features properly. Wouldn’t it make much more sense if they could use core blocks – like a paragraph, heading, or button block – and just tell WordPress to “connect” that block to the product data?

That’s just one example of the promise of the Block Bindings API, and custom fields are only one of many use-cases. Once the foundation has been laid, this feature can extend to all types of data that have been relatively hard to manage in the block editor, from populating post and site information (like Author Name or Featured Image) to helping Synced Patterns become more robust.

Can dynamic data save time and resources?

To learn more about the Block Bindings API, I reached out to Scott Kingsley Clark, Lead Developer of the Pods Framework and the driving force behind the Fields API feature project in WordPress Core. The Fields API proposal circles around a similar issue in WordPress: how can we help developers avoid writing the same code over and over?

That’s the problem that tools like Pods and Advanced Custom Fields rose to solve. They save developers from writing the same custom post type code, custom settings screens, and custom field inputs from scratch on every project. Scott drew the connection between his work and WooCommerce, pointing out that many of the contributors to the Block Binding API are in fact contributors to WooCommerce as well.

“The new WooCommerce Product edit screen is powered by Blocks,” Scott explains, “and you can totally see the progression over the releases they’ve done on that feature as they’ve abstracted more things and started to find ways to consolidate, instead of ‘every specific field has to be their own specific block’ which has been holding them back.”

Scott has been providing feedback on the API and is working on making sure the Pods Framework has an integration ready to go before WordPress 6.5 releases on March 26th.

I also asked Iain Poulson, Product Manager for Advanced Custom Fields, if we might see ACF’s custom fields using this API to connect to core blocks in the future.

“The ACF team have been following the development of the Block Bindings API closely over the last few months,” says Iain. “We’re currently exploring building our own binding source to allow users to use ACF field values to be bound to block attributes, and hope to have a working prototype soon.”

There was originally a chance that custom fields from plugins like Pods and ACF might work out of the box, but some last minute security cleanup meant that any plugin with a more custom approach will need to build their own integration with the API.

“We’re aware of a PR merged today into WordPress core which is likely to mean ACF fields won’t be bindable without this work,” Iain told me earlier this week. “We expect the future to change significantly over coming releases of WordPress with new UIs for connections and the ability to update values from the binding itself, all of these features we’d love to bring to ACF users, and will be working with the WordPress core team to make sure we can.”

It’s exciting to know that major plugins are invested in this new API. What’s also important here is to temper expectations about the API. There’s a long roadmap and plenty of experimentation that needs to happen before we see it deeply embedded in developer workflows.

This is an API without a UI?

Though the WordPress 6.5 release includes the Block Bindings API in core, we’re not going to see an actual user interface for this feature just yet. This is still an “under the hood” feature, but its inclusion means it’s ready for plugin and theme developers to start building on top of.

In 6.5, Block Binding can only be used one of two ways, both of which involve touching a little code:

1. You can take the approach advocated in the WordPress Developer Blog: switch the block editor into the “Code editor” mode and add the binding metadata directly to the block HTML.
2. You can utilize the Block Variations API to add a version of a core block with your binding metadata already baked in. This will require placing some JavaScript in a theme or plugin, but the benefit is that it “just works” once you’re inside the content editor, because your variation shows up as its own block in the block inserter.

The current implementation only supports four core blocks (Paragraph, Heading, Button, and Image), the truth is that those four blocks are some of the most commonly used content blocks and will make up the vast majority of use cases, though other blocks are planned. For end users, this means that any blocks using this API will function exactly like the core blocks they’re already familiar with, a win for usability.

The tracking issue for the project makes it clear that a no-code interface for the Block Bindings API is coming, with some proof-of-concept examples already being explored. By taking this API-first approach, the core team can see how the feature is used in the wild before committing to change in the block editor, and perhaps take some inspiration as plugin teams build out their own integrations.

If you’re an end user, you might not notice anything new just yet. But if you’re a plugin or theme developer, it might be time to explore the Block Bindings API and see if you can’t take advantage of this time-saving feature.