Brian Coords
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.
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.
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.
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:
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.
Hi Adam,
Thanks for taking time to explain the block bindings API in a way that us “non-coders” can understand. I’m now looking forward to seeing a future integration with ACF. Even if connected to only four block types, that would handle the use cases I can imagine.
Hey Mike,
Liam here, one of the ACF devs. I’ve been the one from our team following along with the core PRs and tickets for this feature and working to get support baked into ACF.
I published a demo plugin which shows roughly how this kind of integration will work with ACF once we ship it here if you want to try it out: https://github.com/lgladdy/acf-block-bindings
I think that until there’s a UI for the feature, the usage will be limited, but do expect to have something shipped in ACF well before the UI ships for those folks who want to do manual connections!
Hi Liam,
Thanks for the link to the demo plugin. I’ll have a look. This is a bit above my head, so I’m looking forward to learning something new.
Sorry…should have said “Hi Brian”.
This is the kind of content that I’d like to see on WP Tavern. I really hope that this wins out over clickbait junk that tries to game the metrics.
Hey Brian, thank you very much for this great overview of this API.
i can’t wait to use it already! This is a major block (pun intended) for me to use the block editor in production.
How would you suggest to add my own UI to the block editor so that I can use custom fields?
Or maybe I should just wait for core to get there?
How would you suggest to add my own UI to the block editor so that I can use custom fields?
I struggle with this question too. It really depends on what you’re building, how much control you want over the experience, and if you can wait for core to provide the UI for this. I’m also interested to see how ACF and Pods do it.
For ACF, we won’t be doing our own UI, rather waiting for the WordPress one in 6.6 (if it makes it there!)
We’d rather contribute to helping achieve that, than putting the same effort in our side and ending up with loads of different UIs for achieving the same thing in different plugins and Core.
I’ll be cooking up something for this that we’ll cover on the WordPress Developer Blog. The first steps were to get some introductory resources up to show how the underlying API works. Now we need to show how all these various WP features work together in a more cohesive way.
If you have any specific use cases in mind, please share them. I’m hoping to cover a lot of ground that will be helpful for many different scenarios.
Your email address will not be published.
This site uses Akismet to reduce spam. Learn how your comment data is processed.
Enter your email address to subscribe to this blog and receive notifications of new posts by email.
WordPress Tavern is a website about all things WordPress. We cover news and events, write plugin and theme reviews, and talk about key issues within the WordPress ecosystem…
© All Rights Reserved. Powered by WordPress, hosted by Pressable
Leave a Reply