> For the complete documentation index, see [llms.txt](https://docs.acpt.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.acpt.io/integrations/gutenberg/block-bindings.md).

# Block Bindings

Connect ACPT fields to core WordPress blocks using the native Block Bindings API

WordPress's own [Block Bindings API](https://developer.wordpress.org/block-editor/reference-guides/block-api/block-bindings/) lets you connect a supported block attribute — like a Paragraph's text, or an Image's URL — directly to a data source, without needing one of ACPT's own dedicated Gutenberg blocks. ACPT registers itself as a binding source (`acpt/field`), so any bindable meta field can be connected to a supported core block from WordPress's native **Connect** UI.

{% hint style="info" %}
This is different from ACPT's own [Basic fields block](/integrations/gutenberg/basic-fields-block.md), [Relational fields block](/integrations/gutenberg/relational-fields-block.md), and [Repeater & Flexible Content](/integrations/gutenberg/repeater-and-flexible-content.md) blocks. Block Bindings connect a field to an attribute of WordPress's **own** core blocks (Paragraph, Heading, Image, Button); ACPT's blocks are dedicated blocks in their own right.
{% endhint %}

### Requirements

Block Bindings requires **WordPress 6.7 or later**. On older WordPress versions, the feature is simply unavailable — ACPT's other Gutenberg blocks are unaffected either way.

{% hint style="info" %}
WordPress 6.5 introduced the server-side half of the Block Bindings API; the client-side function ACPT needs to register its own source in the editor's **Connect** UI landed two releases later, in 6.7 — that's why 6.7 is the practical minimum.
{% endhint %}

### Connecting a field to a block

1. Add (or select) one of the supported blocks below.
2. Open the block's **Attributes** panel in the settings sidebar.
3. Click the attribute you want to connect.
4. Choose **ACPT Custom Fields** as the source, then pick a field from the list.

Only fields whose value can be represented as the attribute's own type are offered — WordPress itself filters the list, so you'll only ever see genuinely compatible fields for the attribute you're connecting.

### Supported blocks and attributes

| Block     | Attribute(s)         |
| --------- | -------------------- |
| Paragraph | Content              |
| Heading   | Content              |
| Image     | URL, Alt text, Title |
| Button    | Text, URL            |

{% hint style="info" %}
ACPT's own binding source doesn't restrict itself to this specific list of blocks — it's WordPress core that currently only exposes these attributes to the Block Bindings **Connect** UI. As WordPress core adds bindings support to more blocks/attributes, any compatible ACPT field automatically becomes connectable there too, with no ACPT update required.
{% endhint %}

### Supported field types

The following [field types](/meta-fields/field-types.md) can be used in a block binding: Text, Textarea, ID, Number, Email, Password, Select, Select Multi, Radio, Checkbox, List, Toggle, Date, Date Range, Time, Color, Editor, URL, Image, File.

Fields of other types — Repeater, Flexible Content, Gallery, and other structural/relational field types — can't be represented as a single attribute value, so they never appear as a connectable option.

{% hint style="warning" %}
Being in this list makes a field *eligible* for block bindings (and is what makes the **Allow in block bindings** toggle below appear on that field) — it doesn't guarantee the field can actually be connected to one of the blocks/attributes above today. Because Paragraph, Heading, Image, and Button's bindable attributes are all plain text, **Number, Select Multi, Checkbox, List, Toggle, and Date Range** fields won't currently show up as a connectable option for any of them, even though they're technically eligible. They'll become usable the moment WordPress core exposes a matching non-text attribute on a supported block.
{% endhint %}

{% hint style="info" %}
For URL, Image, and File fields, only the underlying URL is bound by default — connecting one to the Image block's Alt text or Title attribute automatically supplies the image/file's alt text or title instead, not its URL.
{% endhint %}

### Where a field is bindable

* **Custom post type fields** are only offered while editing a post of the matching post type — or, in the Site Editor, on a `single-{post type}`/`archive-{post type}` template.
* **Taxonomy fields** are only offered in the Site Editor, on a `taxonomy-{taxonomy}` template.
* **Option page fields** are always available, in every context.

### Editing a bound field inline

{% hint style="warning" %}
Inline editing is newer and more experimental than the rest of Block Bindings support — expect rough edges.
{% endhint %}

For some bound fields, you can edit the value directly inside the block in the editor, the same way you'd edit any other block content — no need to go back to the field's own settings screen. The edit is saved immediately back to the underlying field's real stored value, independent of the post's own **Update**/**Publish** button.

Whether the inline-edit control actually appears for a given binding depends on all of the following:

* **Field type** — only **Text, Textarea, Editor, Number, and Email** fields can be edited inline. Every other bindable field type (including Select, Select Multi, Radio, Checkbox, List, Toggle, Date, Date Range, Time, Color, Phone, URL, Image, and File) remains read-only inside the block; use the field's own settings screen to change its value.
* **Location** — only **custom post type** and **option page** fields can be edited inline. **Taxonomy fields are never editable inline** — they can still be *connected* (read-only) on a Site Editor `taxonomy-{taxonomy}` template, same as before, but there's no reliable way for the editor to know which specific term to save an edit back to.
* **Permission** — you need the same capability required to manage WordPress **Settings** (Administrators, by default). Editors and Authors without that capability will see the bound value but can't edit it inline, even if the field type and location otherwise qualify.
* **Whether WordPress core supports editing for that specific block/attribute** — WordPress core, not ACPT, decides which bound block attributes get an inline-editing affordance at all (independent from which attributes are merely *connectable*, covered above). This can vary by WordPress version.

{% hint style="info" %}
The **Allow in block bindings** toggle (below) still applies — a field disallowed there is neither connectable nor editable, regardless of its type.
{% endhint %}

### Allow or disallow a field from block bindings

Every field of a supported type is bindable by default. To exclude a specific field, open its settings in the [Meta Fields Manager](/meta-fields/the-meta-fields-manager.md) and, in the **Advanced options** tab, turn off **Allow in block bindings**.

{% hint style="info" %}
This toggle only appears for field types that support block bindings at all (see the list above) — it isn't shown for a field type that could never be bound in the first place.
{% endhint %}