Beyond the Basics: Custom Block Bindings in WordPress

I had a client recently, a real stickler for detail, who needed something tricky with their product listings. They wanted to display dynamic, custom product data directly on their single product pages. Nothing too wild, just a few unique attributes that weren’t standard WooCommerce fields. The catch? They wanted their marketing team to have some flexibility, a way to pick which custom attribute to show on the fly, right there in the editor. Standard Block Bindings in WordPress were a good start, but they didn’t quite expose the specific options we needed. We had to dive into Custom Block Bindings.

This is a common headache, isn’t it? You’ve got data living in custom fields, maybe an external API, or even just some quirky internal logic, and the default editor just gives you a blank stare. You can hardcode it, sure, but then every small change needs a dev. That’s a total nightmare for clients who want autonomy.

Honestly, my first thought was to just build a dedicated custom block for each bit of dynamic data, or leverage ACF fields and then manually pull them in with a bit of PHP. And yeah, that works. It always does. But it feels… heavy. Inelegant. Like bringing a tank to a knife fight. I knew there had to be a cleaner way to integrate with the existing Block Bindings UI, making it feel native, not like a bolted-on solution.

Unlocking Dynamic Content with Custom Block Bindings

That’s where WordPress 6.9 really shines with its Block Bindings improvements. Specifically, for us developers, the ability to register custom sources in the editor UI via a getFieldsList method changes the game. It allows us to expose our custom data sources in a user-friendly dropdown, just like the core Block Bindings do for post meta or site data. It’s about empowering the editor, and not forcing content creators to learn shortcodes or custom functions. This approach builds beautifully on the foundation outlined in the dev note, making dynamic content truly editable.

Here’s a simplified example of how you can expose your own custom fields to the Block Bindings UI. This snippet registers a custom source, let’s call it ‘bbioon_custom_data’, which could fetch anything you want:

<?php
/**
 * Plugin Name: Bbioon Block Bindings Custom Source
 * Description: Registers a custom Block Bindings source for dynamic content.
 * Version: 1.0.0
 * Author: Ahmad Wael
 */

function bbioon_register_custom_block_bindings_source() {
    // This part runs on the server to provide the actual values
    wp_register_script(
        'bbioon-custom-bindings-source',
        plugin_dir_url( __FILE__ ) . 'build/index.js',
        array( 'wp-blocks', 'wp-element', 'wp-data', 'wp-edit-post' ),
        '1.0.0',
        true
    );

    // Enqueue the script only when Block Editor is active
    add_action( 'enqueue_block_editor_assets', function() {
        wp_enqueue_script( 'bbioon-custom-bindings-source' );
    });

    // You can also use the new filter block_bindings_supported_attributes_{$block_type}
    // to limit which block attributes can be bound to your source.
    // add_filter( 'block_bindings_supported_attributes_core/paragraph', 'bbioon_limit_paragraph_bindings' );
    // function bbioon_limit_paragraph_bindings( $attributes ) {
    //     $attributes[] = 'bbioonCustomAttribute'; // Only allow binding to this custom attribute
    //     return $attributes;
    // }
}
add_action( 'init', 'bbioon_register_custom_block_bindings_source' );
?>

// JavaScript for the editor (build/index.js)
wp.blocks.registerBlockBindingsSource({
    name: 'bbioon/custom-data',
    label: 'Bbioon Custom Data',
    getValues: ({ bindings }) => {
        // Implement logic to fetch data based on selected field and args
        const field = bindings.content?.args?.bbioon_field;
        let value = '';

        if (field === 'special_product_note') {
            value = 'This product features eco-friendly materials.';
        } else if (field === 'delivery_estimate') {
            value = 'Ships in 3-5 business days.';
        }
        // In a real scenario, you'd fetch this from post meta or an API.
        return {
            content: value || bindings.content,
        };
    },
    getFieldsList() {
        return [
            {
                label: 'Special Product Note',
                type: 'string', // Must match attribute type
                args: {
                    bbioon_field: 'special_product_note',
                },
            },
            {
                label: 'Delivery Estimate',
                type: 'string',
                args: {
                    bbioon_field: 'delivery_estimate',
                },
            },
        ];
    },
});

See that getFieldsList() method? That’s the kicker. It’s what populates the dropdown in the editor, allowing a user to easily select “Special Product Note” or “Delivery Estimate” for a paragraph block, for example. The type property is crucial; it ensures only compatible fields show up. And don’t forget the block_bindings_supported_attributes_{$block_type} filter. That’s your server-side control for limiting what attributes can even be bound, giving you more granular control over your block themes.

Making the Editor Work For You, Not Against You

The real takeaway here is about integration and developer sanity. Instead of fighting the editor or layering on complex custom solutions, WordPress 6.9 gives us the tools to extend its native capabilities gracefully. We can now expose dynamic content options in a way that feels intuitive to content creators, all while maintaining strict control over the data on the backend. It’s a win-win: a better user experience and a cleaner codebase for us. Period. For emphasis.

Look, this stuff gets complicated fast. If you’re tired of debugging someone else’s mess and just want your site to work, drop my team a line. We’ve probably seen it before.