For years, “this section needs dynamic data” meant “someone writes a custom block.” The Block Bindings API, introduced in WordPress 6.5, quietly ended that. Bindings connect an attribute of a core block — a paragraph’s text, an image’s URL, a button’s link — to a data source, so the block displays dynamic content while remaining a perfectly ordinary core block. Put bindings inside a pattern and you get something genuinely new: reusable, dynamic sections with zero custom code.
The shape of a binding
A binding lives in the block’s metadata attribute. This paragraph renders whatever the post’s team_role meta field contains:
<!-- wp:paragraph {"metadata":{"bindings":{
"content":{"source":"core/post-meta","args":{"key":"team_role"}}
}}} -->
<p>Role goes here</p>
<!-- /wp:paragraph -->Core supports binding the attributes that matter — paragraph and heading content, image url/alt/title, button text and url — and ships a core/post-meta source; plugins can register their own sources with a few lines of PHP.
Recipe: the team-member card
Build a card pattern — image, name heading, role paragraph, profile button — and bind each piece to post meta on a team post type. Drop the pattern into the post type’s template once. Every team member’s page now renders their own data through one pattern; redesign the card and every profile follows. That used to be a custom block, a render callback, and an afternoon.
Overrides are bindings too
Here is the part that ties the room together: pattern overrides — the feature that lets each instance of a synced pattern customize marked blocks — are implemented as a binding source (core/pattern-overrides). Marking a block overridable binds its attributes to per-instance values. WordPress 6.6 added the __default shorthand that wires all of a block’s supported attributes to overrides at once. Same API underneath; once you see it, bindings stop feeling like an advanced feature and start feeling like how patterns are supposed to work.
Where Pattern Builder helps
Hand-editing metadata JSON is nobody’s idea of fun. Pattern Builder surfaces a bindings panel right in the editor sidebar while you edit a pattern, so connecting a block attribute to a source is a form, not a syntax exercise — and because patterns are Pattern Builder’s whole subject, your bound patterns sit in the same library, upload to the same cloud, and convert between theme and user homes like any other pattern.
Dynamic data, core blocks, no build step. The custom-block era is not over — but for content sections, it is optional now.