WordCamp Europe 2026 - Block Bindings for All!

WordCamp Europe 2026 - Block Bindings for All! ![rw-book-cover](https://img.youtube.com/vi/HevnYGB86R0/maxresdefault.jpg) 🔗 **Source:** [WordCamp Europe 2026 - Block Bindings for All!](https://www.youtube.com/watch?v=HevnYGB86R0) > [!note]+ Document Notes > tags: [block-bindings, full-site-editing, wordpress-development, meta-fields, content-modeling, gutenberg] > author: Rob Stinson > source: WordCamp Europe > reference: https://www.youtube.com/watch?v=HevnYGB86R0 > date created: {{date:YYYY-MM-DD}} {{time:HH:mm}} > > # 🏷️ Title: Block Bindings For All! - WordCamp Europe 2026 >  ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ## 📝 Summary - **What happened**: Rob Stinson presented a comprehensive overview of WordPress Block Bindings at WordCamp Europe 2026, demonstrating how developers can connect dynamic data to blocks in the full-site editing era. - **Why it matters**: Block bindings solve the critical problem of separating content from presentation while maintaining the ability to use data both programmatically server-side and in the presentation layer. - **Key stakeholders**: WordPress developers, theme builders, plugin developers, and site builders working with custom post types and metadata. - **Risks and tradeoffs**: Limited out-of-box support, different behavior between template and post editors, and complexity in matching attribute schemas. - **Bottom line**: Block bindings represent a powerful but still-evolving solution for dynamic content in WordPress's block-based future. ## 📖 Main Content Block bindings address a fundamental challenge in WordPress's evolution from classic editor to full-site editing: how to maintain the separation between content and presentation while enabling dynamic data usage across both server-side code and the visual editor interface. The core concept involves registering data sources that can feed content into block attributes dynamically. The simplest implementation starts with post meta registration using `show_in_rest: true`, which exposes custom fields in the editor's attributes panel. However, the real power emerges in full-site editing templates where context becomes crucial. ### Registration Methods **Server-side registration** involves creating callback functions that fetch data based on context. The system supports four main binding sources out of the box: core post meta, pattern overrides, and two others mentioned but not detailed in the presentation. Custom sources require careful attention to schema matching between the data source and target block attributes. **Client-side registration** uses JavaScript equivalents of server-side registration, with the critical `getFieldsList` function enabling the default block editor UI for adding bindings. This approach also supports dynamic value fetching and inline editing capabilities. ### Implementation Strategies Multiple strategies exist for exposing bindings to users: server-side registration can be hardcoded into patterns and template parts, integrated with post type registration to define locked block structures, or implemented through block variations that behave as unique, non-editable blocks with predefined bindings. The presentation highlighted practical applications like exposing EXIF metadata for featured images, allowing photographers to display camera information automatically alongside photos. ### Current Limitations Several constraints affect current implementations: certain blocks like embeds don't work well with bindings because URL changes alter stored HTML markup. Template editing behaves differently from post editing, with bound properties becoming non-editable in template contexts. Blocks with bound attributes always display regardless of data availability, requiring additional plugins for conditional visibility. ## 🗒️ Notes #### ⏱️ [00:01:30](https://www.youtube.com/watch?v=HevnYGB86R0&t=90) Introduction and Problem Statement - WordPress evolution from classic editor to blocks/full-site editing requires solving content-presentation separation differently - Core challenge: using content and data both programmatically server-side and in presentation layer - Block bindings provide the solution framework #### ⏱️ [00:02:15](https://www.youtube.com/watch?v=HevnYGB86R0&t=135) Hello World Example - Post Meta Registration - Simplest approach: register post meta with `show_in_rest: true` - Exposes custom meta in editor sidebar under "attributes" section - Schema type matching required between source and target block attributes - Enables inline editing that updates database directly #### ⏱️ [00:03:45](https://www.youtube.com/watch?v=HevnYGB86R0&t=225) Real World Usage - Full Site Editing Templates - Primary use case: full-site editing templates where post context isn't available during editing - Context provided by blocks like query loop becomes essential - Bound properties become non-editable in template context - Still requires traditional meta boxes or sidebar fields for content management #### ⏱️ [00:05:00](https://www.youtube.com/watch?v=HevnYGB86R0&t=300) Block Binding Source Registration - Server-side registration uses callback functions to fetch data - Context creation and consumption is flexible - can filter existing blocks for additional context - HTML metadata stored as regular attributes with bindings property - Four main out-of-box sources available (as of WordPress 7.0 release) #### ⏱️ [00:07:30](https://www.youtube.com/watch?v=HevnYGB86R0&t=450) Extending Beyond Default Support - Filter available to enable bindings for any blocks and attributes - Complex attribute schemas create challenges - matching requirement still applies - Example: mathematical formulas in post meta require extending core math block - Schema complexity directly correlates with implementation difficulty #### ⏱️ [00:09:00](https://www.youtube.com/watch?v=HevnYGB86R0&t=540) User Exposure Strategies - Server-side: hardcoded in patterns/templates, post type registration integration, block variations - Block variations can behave as unique, non-editable blocks - Client-side JavaScript registration extends default editor UI - Real implementations typically combine multiple strategies #### ⏱️ [00:11:15](https://www.youtube.com/watch?v=HevnYGB86R0&t=675) Client-Side Implementation Details - JavaScript equivalent of server-side registration - `getFieldsList` function critical for extending block editor UI - Optional methods for dynamic value fetching and inline editing - EXIF metadata example: exposing camera information for featured images #### ⏱️ [00:13:00](https://www.youtube.com/watch?v=HevnYGB86R0&t=780) Cheat Code and Synced Patterns - Register post meta then filter `get_post_metadata` to return dynamic values - Provides UI benefits without database storage - Synced patterns use block bindings for text/image overrides - Override data stored with synced pattern reference in attributes #### ⏱️ [00:14:30](https://www.youtube.com/watch?v=HevnYGB86R0&t=870) Current Limitations - Embed blocks problematic due to URL changes affecting stored HTML - Template vs post editor behavior differences - Bound blocks always display regardless of data availability - No default output formatting options (e.g., date format variations) - Requires additional plugins like Block Visibility for conditional display #### ⏱️ [00:16:00](https://www.youtube.com/watch?v=HevnYGB86R0&t=960) Existing Solutions and Future Outlook - Remote Data Blocks by VIP: connects to APIs and remote sources - Create Content Model by Brian Cords: visual custom post type definition - WordPress 7.0: more extensible synced pattern overrides - Content modeling coming to WordPress core ## 📚 References - [WordPress Playground Demo](https://playground.wordpress.net) - mentioned for trying out examples - [Plugin Repository](https://wordpress.org/plugins/) - for accessing related tools - [Remote Data Blocks by VIP](https://wpvip.com) - [Create Content Model by Brian Cords](https://automatic.com) - WordPress 7.0 synced pattern overrides documentation ## 🗣️ Paraphrase Rob Stinson explains how WordPress's evolution to block-based editing created new challenges for managing dynamic content. In the classic editor era, separating content from presentation was straightforward, but full-site editing requires different approaches to maintain that separation while enabling both programmatic server-side access and visual editor functionality. Block bindings provide the solution by allowing developers to connect data sources to block attributes dynamically. The implementation ranges from simple post meta registration to complex custom sources with schema matching requirements. While the current system has limitations around conditional display and format customization, emerging tools and WordPress core developments promise expanded capabilities for content modeling and dynamic data management. ## 📰 Newsletter 🚀 **Block Bindings: The Future of Dynamic WordPress Content** WordPress developers, take note! Block bindings are revolutionizing how we handle dynamic content in the full-site editing era. Rob Stinson's WordCamp Europe presentation reveals this powerful system for connecting database content to blocks without sacrificing the visual editing experience. **Quick wins for your toolkit:** - Start with post meta + `show_in_rest: true` for instant custom field editing - Use block variations to create "smart blocks" with predefined data connections - Try the EXIF metadata example for photography sites - Explore Remote Data Blocks (VIP) for API integrations **Developer resources:** - [WordPress Playground demos](https://playground.wordpress.net) for hands-on testing - Create Content Model plugin for visual post type building - WordPress 7.0's enhanced synced pattern overrides The limitations are real (embed blocks, conditional display), but the potential is massive. Content modeling is coming to core, and the community is building amazing extensions. Time to start experimenting! 🎯 ## ✅ Action Items #### WordPress - **Core**: Expand default block binding support beyond current four sources - **Core**: Improve embed block compatibility with dynamic URL binding - **Core**: Add conditional display options for bound blocks without data - **Core**: Implement default output formatting options (date formats, etc.) - **Core**: Standardize template vs post editor binding behavior - **Documentation**: Create comprehensive block bindings developer guide with schema matching examples - **Community**: Organize binding-focused workshops at WordCamps #### DevRel - **Developer advocacy**: Create block bindings showcase with real-world implementations - **Education**: Develop progressive tutorial series from post meta to complex custom sources - **Developer experience**: Build block binding starter templates and boilerplate code - **Developer marketing**: Highlight success stories from VIP Remote Data Blocks and similar tools - **Community management**: Foster block bindings discussion forum or Slack channel #### Community - **Maintainers**: Integrate block bindings examples into theme review guidelines - **Contributors**: Contribute to core improvements for embed block binding support - **Ecosystem**: Build compatibility layer plugins for smoother binding transitions ## 🧪 Hypotheses - Block bindings adoption will accelerate once conditional display and formatting options reach core WordPress - The schema matching requirement creates the biggest barrier to widespread developer adoption - Full-site editing templates will become the primary use case, overshadowing post-context binding usage - Third-party solutions like Remote Data Blocks will influence core WordPress binding feature development - Content modeling tools will consolidate around block binding standards within 18 months ### 📊 Methodology - Survey WordPress developers on block binding implementation challenges and schema matching pain points - A/B test tutorial approaches: code-first vs. UI-first binding education - Track adoption metrics across different binding strategies (server-side vs client-side registration) - Case study analysis of existing implementations (VIP, Create Content Model, custom solutions) - Performance benchmarking of bound vs. static content across template complexity levels ### ❓ Questions - How will WordPress core resolve the template vs. post editor behavior inconsistency? - What's the roadmap for bringing content modeling fully into core WordPress? - Can the embed block binding limitations be solved without fundamental architecture changes? - Will block variations become the preferred method for exposing bindings to end users? - How will the community handle backward compatibility as binding capabilities expand? ### 🔮 Future Research - Impact of WordPress 7.0 synced pattern improvements on binding adoption rates - Development patterns emerging from Remote Data Blocks and similar solutions - Schema matching automation possibilities and developer experience improvements - Integration opportunities between block bindings and emerging headless WordPress patterns - Performance implications of widespread binding adoption in high-traffic environments ### 💡 Implications - **Practice**: Developers need to rethink content architecture for block-first design patterns - **Policy**: WordPress theme review guidelines should incorporate block binding best practices - **Security**: Dynamic data binding introduces new attack vectors requiring validation frameworks - **Education**: Developer training must evolve beyond traditional post meta approaches - **Funding**: Investment in binding-focused tools and plugins likely to increase significantly ### 🧠 Learning Styles Assessment - **Reading level**: Technical documentation level (Flesch-Kincaid Grade 12-14) #### 👀 Visual learners - **Present**: Code examples, HTML structure demonstrations, editor interface screenshots - **Improve**: Architecture diagrams showing data flow from source to block, before/after comparisons of bound vs. static content, step-by-step visual tutorials #### 🔊 Aural learners - **Present**: Conference presentation format with spoken explanations - **Improve**: Podcast-format deep dives on complex topics, audio walkthroughs of code examples #### 🗣️ Verbal learners - **Present**: Clear terminology definitions, analogies to classic editor patterns - **Improve**: Glossary of binding-specific terms, plain-language explanations of schema matching #### 🧩 Kinesthetic learners - **Present**: WordPress Playground hands-on examples, downloadable code samples - **Improve**: Interactive tutorials, step-by-step implementation checklists, sandbox environments #### 🧠 Logical learners - **Present**: Systematic progression from simple to complex examples, clear cause-effect relationships - **Improve**: Decision trees for choosing binding strategies, troubleshooting flowcharts, performance impact tables #### 🧑‍🤝‍🧑 Social learners - **Present**: Community conference setting, Q&A opportunities - **Improve**: Binding-focused discussion forums, peer review processes for implementations, collaborative coding sessions #### 🧘‍♀️ Solitary learners - **Present**: Self-contained code examples, independent exploration paths - **Improve**: Self-assessment quizzes, reflection prompts on implementation choices, personal project ideas #### 🌿 Naturalistic learners - **Present**: Evolution metaphors (classic to block editor transition) - **Improve**: Ecosystem thinking about plugin compatibility, organic growth patterns in adoption ### 📊 Accessibility Assessment #### Screen reader semantics - **Present**: Proper heading structure, code block semantics - **Improve**: Alt text for diagram examples, ARIA labels for interactive elements in tutorials #### Keyboard navigation - **Present**: Standard web navigation patterns - **Improve**: Keyboard shortcuts for common block binding operations, skip links in long tutorials #### Contrast and readability - **Present**: Standard text contrast ratios - **Improve**: Syntax highlighting with high contrast themes, larger font options for code examples #### Text resizing and reflow - **Present**: Responsive design principles - **Improve**: Code examples that remain readable at 200% zoom, mobile-friendly tutorial layouts #### Media and captions - **Present**: Video presentation with transcript - **Improve**: Detailed audio descriptions for visual code demonstrations, downloadable transcripts #### Forms and interactions - **Present**: Standard form elements in WordPress admin - **Improve**: Clear error messages for schema mismatches, helpful validation feedback #### Standards reference - Ensure WCAG 2.2 AA compliance for all educational materials and documentation ### 🌍 DEIB Assessment #### Cultural breadth - **Present**: English-focused presentation from European conference - **Improve**: Multi-language code examples, international date/currency binding examples, global community case studies #### Inclusive language - **Present**: Technical jargon with some explanation - **Improve**: Plain-language summaries, expanded glossary, avoid assumptions about prior WordPress experience #### Neurodiversity support - **Present**: Structured presentation with clear sections - **Improve**: More frequent headings, consistent code formatting patterns, multiple explanation approaches #### Representation - **Present**: Single presenter perspective - **Improve**: Diverse case studies, multiple implementation approaches, community contributor spotlights #### Psychological safety - **Present**: Professional conference environment - **Improve**: "No stupid questions" policies, beginner-friendly entry points, multiple skill level pathways ### ✅ Logical Validity #### Strong reasoning - **Deductive logic**: Clear progression from problem identification (content/presentation separation) to solution (block bindings) with specific implementation steps - **Inductive evidence**: Multiple concrete examples (post meta, EXIF data, mathematical formulas) supporting general principles - **Causal relationships**: Well-established connections between schema matching requirements and implementation complexity #### Fallacies - **Appeal to novelty**: Slight tendency to present block bindings as inherently better without fully addressing trade-offs with existing solutions - **Hasty generalization**: Limited discussion of use cases where block bindings might not be optimal - **False dichotomy**: Frames choice as either traditional meta boxes or block bindings without exploring hybrid approaches #### Tone of voice - **Professional-technical** with accessible explanations and practical focus. Uses first-person experience ("I created a feature") to build credibility while maintaining instructional clarity. ### 🛡️ DARVO Analysis No DARVO patterns detected. The presentation maintains a constructive, educational tone focused on technical solutions rather than defensive rhetoric. ## 🎯 Conclusion Block bindings represent a significant evolution in WordPress development, providing essential infrastructure for dynamic content in the block editor era. While current limitations around conditional display and schema complexity exist, the foundation is solid and expanding rapidly. **Practical next steps for developers:** - Start experimenting with post meta bindings in current projects - Evaluate existing plugins like Remote Data Blocks for immediate needs - Begin planning content architecture with binding-first design patterns - Stay engaged with core WordPress development as content modeling features mature The future of WordPress development increasingly relies on understanding and leveraging these binding mechanisms effectively. --- ## Full Transcript [00:19] So, uh, I'll be honest with you. Uh, for [00:21] the next speaker, uh, his name is Rob, [00:24] and he wrote his own introduction. He [00:27] said, and I quote, "He's awesome. He's [00:30] been in WordPress for two decades. He [00:32] can do origami and he came to my [00:34] wedding." [00:35] >> Uh, but in all seriousness, he's our [00:37] principal engineer humanade and has [00:40] solved some of the world's biggest web [00:42] puzzles. Uh, please let me welcome Rob. [00:45] I have not been able to pronounce his [00:47] last name properly for the last 10 [00:48] years. Orog. Yeah. [00:57] All right. [00:58] You did actually pronounce it correctly [01:00] then. So [01:03] um Oh yeah. So cheers John. So I'm Rob. [01:07] Um yeah been working with WordPress for [01:09] about two decades and things change a [01:12] lot. So in this new world of uh blocks [01:15] and fullsight editing um we got answer [01:19] solved problems again in different ways. [01:21] Um, now that content and presentation [01:24] are so meshed together, how do we go [01:27] back to being able to use content and [01:29] data both programmatically server side [01:32] and in that presentation layer? So the [01:35] clue was in the title of the talk [01:37] really. Um, it was block bindings. Um, [01:41] we'll get straight into the hello world [01:43] example. So the easiest way is to uh [01:47] register some post meta and make sure [01:50] that you have show and rest true. Uh is [01:53] that playing? [01:56] Oh, [01:57] maybe not. [02:00] Uh never mind. [02:03] Um, [02:07] oh well, [02:09] I'll have to um explain obviously if the [02:12] other videos work, but yeah, registering [02:14] post meta uh is the easiest way to get [02:17] started. And this will expose your um uh [02:22] submet in the sidebar of the editor. [02:26] There's a little section called [02:27] attributes. As long as your schema type [02:30] for the attribute matches the schema [02:32] type of an attribute that you want to [02:34] bind uh then this interface will come [02:37] up. [02:39] Um [02:41] editing bound post meta fields uh that [02:44] will also if you edit it in the context [02:46] of the post editor it'll also update in [02:48] the database. Um, but we're not seeing [02:52] like there's not much more advantage to [02:54] this um over just regularly editing [02:57] uh post content at the moment. Uh, so [03:00] what's the the real world example? [03:03] Uh, [03:06] oops. Is this one going to go? [03:10] This is way better if the video is [03:12] actually played. [03:14] Um, [03:18] so you're going to normally be using [03:20] block bindings in fullsite editing [03:23] templates. And the difference there is, [03:27] uh, you won't see the actual content [03:30] because you don't have the context of [03:32] the post ID or anything like that when [03:35] you're editing a template. Um, [03:38] so context is important. That's provided [03:40] by blocks like the query loop. Um [03:44] uh but yeah, in that context of a [03:47] template, the bound properties are not [03:49] editable at all. Um [03:53] uh so you still have to go back to the [03:55] legacy way of doing things with like [03:57] custom meta boxes or a field in the [03:59] sidebar or something to manage that [04:00] metadata for it to be able to show. Um [04:06] so this is what registering a [04:07] blockbinding source looks like. Uh it is [04:11] basically a callback to fetch some data. [04:15] Um [04:17] uh and again the key thing here is [04:19] mentioning like the context. Uh you can [04:22] create and consume any context that you [04:23] like. When you register blocks uh you [04:26] can filter existing blocks their [04:28] registration metadata to um uh allow [04:32] them to use additional context or [04:34] provide it. Uh which gives you a lot of [04:37] options. So, uh the [04:41] uh [04:44] oh yeah [04:46] um [04:47] this metadata markup in the HTML uh it's [04:52] just like regular attributes. We have [04:54] the metadata property within that uh we [04:58] have the bindings property and then you [05:00] specify all of your attributes and the [05:02] source that feeds that attribute. Uh [05:07] so out of the box uh support is still a [05:11] little bit limited by default. Uh you [05:14] can get quite far with these options. [05:16] They're the main kind of content editing [05:18] options available. Uh and then the [05:22] blockbinding sources uh that you get out [05:24] of the box as well. We've got four main [05:27] ones at the moment at least as the time [05:29] of writing. WordPress 7 was released in [05:31] between making these slides uh and this [05:34] talk. Uh core post meta is an [05:38] interesting example because you can uh [05:42] uh provide additional arguments to this [05:45] uh callback [05:47] uh to like choose the particular meta [05:50] key or something that you want to fetch. [05:52] Um [05:54] now to go further outside of the box uh [05:58] we've got a filter. we can now uh enable [06:02] bindings for any other blocks and any [06:04] other attributes. Um more complex [06:07] attributes that's going to be harder to [06:09] work with because the schemas have to [06:11] match. Uh but in this example, if you [06:13] wanted to store uh a mathematical [06:15] formula in post meta, uh you would need [06:18] to use this filter to extend a core math [06:20] block to do that. [06:23] Uh [06:26] so how do we get block bindings [06:29] available to users in in the editor? So [06:32] we've got a few strategies for exposing [06:33] bindings. Uh server side registration [06:37] that can be hardcoded into patterns uh [06:40] template parts. Uh uh it can be part of [06:43] the post type registration. There's a [06:45] way to define and lock down the blocks [06:49] that make up a a post. Um, you've also [06:53] got block variations as an option. Uh, [06:55] so, uh, a block variation lets you [06:58] define all of the attributes that get [06:59] set when you insert that. Uh, you can [07:01] even make them behave as if it's a [07:03] unique block, uh, that always will have [07:05] this binding and be non-editable. [07:08] Um, there's also client side [07:10] registration. So, this is a JavaScript [07:12] equivalent of the server side um, [07:15] blockbinding source registration. [07:18] uh and that extends the default editor [07:20] UI for adding these uh and you'll [07:23] probably in real life uh use [07:25] combinations of these. [07:28] So the JavaScript for create uh creating [07:31] a binding source on on uh the client [07:33] side uh largely the same but the key [07:36] function to be aware of here is this get [07:38] fields list one without that it won't [07:41] extend the default block editor UI for [07:43] adding bindings uh and then you can [07:45] optionally set uh methods for fetching [07:47] that value dynamically and even updating [07:50] it in line in the editor. [07:53] Uh [07:55] again, a video that won't play. Um what [07:59] you need to imagine here um and at the [08:02] end I've got a resource that you can [08:03] actually try this out on playground um [08:06] or get the code. Uh uh I created a [08:09] feature that would expose um the XF [08:14] metadata for the post featured image uh [08:17] through block bindings. So you could add [08:19] extra data underneath the image to say [08:21] like um what camera was used to take the [08:24] photo for example. [08:26] Uh [08:28] so there's also a cheat code uh if you [08:30] want to get the UI for free uh register [08:33] some post meta and then filter get post [08:35] meta data but rather than even going to [08:38] the database just return a dynamic value [08:40] um it will kind of give you the same [08:42] result. Uh so that's a a cheats win. [08:47] maybe don't always do this, but um [08:51] uh another video worth mentioning synced [08:54] patterns work through via block [08:56] bindings. Um the synced pattern itself, [09:00] you can set some overrides for the text [09:03] for the image. Um and then you can also [09:07] um [09:09] yeah, the override [09:11] data is stored with this reference to [09:13] the synced pattern uh in the attributes. [09:16] So that's another example of core block [09:18] bindings. Uh there are a bunch of [09:23] limitations to this still. So uh binding [09:27] ids and things um or say the embed block [09:31] for example binding the URL doesn't work [09:34] very well because when you paste in the [09:36] ID or the URL for an embed block that [09:40] changes the markup that is stored in the [09:42] database in the HTML. uh and that [09:45] doesn't really play ball with with [09:46] dynamic content. Uh so that's one to [09:49] watch out for. Um [09:52] again that template versus post editor [09:54] behavior. So editing content the post [09:56] rather than the full editing template [10:00] bindings will behave differently in [10:01] those two settings. [10:03] Um block bindings or blocks that are [10:06] have uh bound attributes. They'll always [10:09] still show up even if the data doesn't [10:12] return anything. So you need to look to [10:15] plugins like block visibility or [10:16] something to add uh conditional display [10:20] options. [10:21] Uh and there's no kind of default output [10:24] options beyond that to say if you want [10:27] to show a date uh that you've bound to a [10:30] block in in different formats for [10:32] example. Uh so there's still lots of [10:34] like improvements that can come with [10:36] these uh looking further to the future [10:40] uh and good examples of block bindings [10:43] out there in the wild that you can use [10:44] now. Uh remote data blocks by VIP allows [10:47] you to bind attributes um of blocks to [10:52] remote data sources, APIs, uh anything [10:55] really that you can register and run in [10:57] PHP. Uh you've also got create content [11:00] model. this by Brian Cords with [11:03] automatic uh you can define your custom [11:06] post types and some of the metadata and [11:09] model that data in a in a block editor [11:13] environment. So that one's worth a look. [11:16] Um and then further to the future, uh [11:20] synced pattern overrides in WP7. Well, I [11:23] guess the future is now, right? Um [11:27] that's more extensible now. was [11:29] completely locked down before but you [11:30] can apply that to lots of more uh blocks [11:33] and attributes. Uh and then that content [11:35] modeling that I mentioned is coming to [11:37] core as well. Uh so yeah try it in [11:41] playground. Uh the plug-in repo and [11:44] these slides are probably better as a [11:46] reference. Um the videos might actually [11:49] play [11:51] if you look at it there. But yeah, thank [11:52] you very much. [11:54] >> Thank you Rob.  📄 **Full text:** ![[Full Document Contents/Articles/WordCamp Europe 2026 - Block Bindings for All!.md|WordCamp Europe 2026 - Block Bindings for All! by YouTube]] ## Highlights - back to being able to use content and data both programmatically server side and in that presentation layer? So the clue was in the title of the talk really. Um, it was block bindings. Um, ([View Highlight](https://read.readwise.io/read/01kteqy3tqzr3g58c3t4g9kpc9)) - Note: The problem Block Bindings solves: using content/data both programmatically server-side and in the presentation layer — reuniting the two after the block editor split them. - Tags: atom/literature/h2, block-bindings, wceu-2026 - bindings. Uh server side registration that can be hardcoded into patterns uh template parts. Uh uh it can be part of the post type registration. There's a way to define and lock down the blocks that make up a a post. Um, you've also got block variations as an option. Uh, ([View Highlight](https://read.readwise.io/read/01kteqxwvd9mbcaefxcbj51qdg)) - Note: Block Bindings as the bridge back to programmatic content control: server-side registration hardcoded into patterns/template parts/post-type registration, with a way to define and lock down a post's blocks. - Tags: wceu-2026, block-bindings, atom/literature/h1 - you can set some overrides for the text for the image. Um and then you can also um yeah, the override data is stored with this reference to the synced pattern uh in the attributes. So that's another example of core block bindings. Uh there are a bunch of limitations to this still. So uh binding ids and things um or say the embed block ([View Highlight](https://read.readwise.io/read/01ktfby0mjbsgytp2k9tkgaw2t)) - Tags: 👻 ai highlighted