Introducing Block Hooks for Dynamic Blocks
[[3. Resources/Readwise/Full Document Contents/Articles/Introducing Block Hooks for Dynamic Blocks|Full Document Contents]]
## Document Notes
---
tags:
- #wordpress
- #blockhooks
- #development
Author: Nick Diego
Source: Make WordPress Core
Reference: https://make.wordpress.org/core/2023/10/15/introducing-block-hooks-for-dynamic-blocks/
date created: 2025-08-23 00:00
---
# Title: Introducing Block Hooks for Dynamic Blocks (WordPress 6.4)
## Table of Contents:
- [[#📝 Summary:]]
- [[#📖 Main Content:]]
- [[#🗒️ Notes]]
- [[#📖 References:]]
- [[#🗣️ Paraphrase:]]
- [[#📰 Newsletter:]]
- [[#✅ Action Items:]]
- [[#🧪 Hypotheses]]
- [[#📊 Methodology]]
- [[#❓ Questions]]
- [[#🔮 Future Research]]
- [[#💡 Implications]]
- [[#🧠 Learning Styles Assessment]]
- [[#📊 Accessibility Assessment]]
- [[#🌍 DEIB Assessment]]
- [[#✅ Logical validity]]
- [[#🔍 DARVO Analysis Prompt]]
- [[#🔍 SEO Evaluation]]
- [[#🎯 Conclusion]]
### References:
- Make/Core Dev Note: Introducing Block Hooks for dynamic blocks — https://make.wordpress.org/core/2023/10/15/introducing-block-hooks-for-dynamic-blocks/
- WordPress 6.4 release news — https://wordpress.org/news/2023/10/wordpress-6-4/
## 📝 Summary:
WordPress 6.4 adds Block Hooks, an extensibility mechanism for Block Themes that lets a block automatically insert itself relative to other blocks. It mirrors classic filters/actions patterns for the block era. Two guiding tenets govern the feature: automatic front-end insertion on plugin activation and user control in the editor. Current scope limits insertion to templates, template parts, and patterns (not user-modified content), and to dynamic blocks (static blocks with save functions trigger validation errors). Developers can declare hooks via block.json (simple/unconditional) or the hooked_block_types filter (flexible/conditional, with context awareness).
## 📖 Main Content:
Block Hooks allow plugins to programmatically extend block-based sites without manual placement. Typical use cases: inject a Like button before Post Content, add a Login/Logout after a header Navigation, or append UI elements inside container blocks as first or last child.
Two implementation paths:
- block.json blockHooks: Unconditional insertions relative to all instances of target blocks where templates are unmodified. Positions: before, after, firstChild, lastChild. When injected as first/last child, an Editor “Plugins” panel appears on the target block to toggle insertions.
- hooked_block_types filter: Allows conditional insertion using the context (template, template part, or pattern) and anchor block position, with parameters for the hooked blocks list, position, anchor block name, and context. Context types differ: WP_Block_Template object for templates/parts, array for patterns.
Constraints and tradeoffs:
- To honor automatic insertion and user control, hooks are confined to theme layout sources: templates, template parts, and patterns (theme-provided, directory, or registered programmatically).
- Not supported: user-modified templates/parts, post content, user-authored patterns, and static blocks (those with save functions).
- Only default block instances can be inserted; attributes cannot be set yet. Improvements are planned.
Practical implications:
- Plugin authors can ship opinionated default placements without overwriting user content.
- Theme authors retain layout integrity while giving users control via the editor.
- Site owners benefit from consistent, upgrade-safe enhancements.
### 🗒️ Notes
- Concept and purpose
- Emulates classic hooks for block themes to extend layouts.
- Automatic, relative placement around “anchor” blocks.
- Core tenets
- Auto front-end insertion upon plugin activation; removal upon deactivation.
- Users retain full editor control to keep/remove/move/customize the inserted block.
- Scope and limitations
- Works only in templates, template parts, patterns (theme or directory or registered).
- Excludes post content, user-modified templates/parts, and user-created patterns.
- Dynamic blocks only; static blocks with save() cause validation errors.
- Inserted blocks use default attributes; attribute customization is not yet supported.
- Implementation options
- block.json
- blockHooks object maps anchor block → position (before, after, firstChild, lastChild).
- Applies unconditionally to all qualifying instances.
- Editor adds “Plugins” settings panel for firstChild/lastChild to toggle injected blocks.
- hooked_block_types filter
- Conditional logic by template slug (e.g., single), template part area (e.g., header), or pattern slug.
- Parameters: $hooked_blocks, $position (before/after/first_child/last_child), $anchor_block, $context (object/array).
- Must type-check $context.
- Examples
- Insert Like button before core/post-title in Single template.
- Insert core/loginout as last child of a header template part group/navigation.
- Insert Like button after core/post-terms inside a specific pattern (e.g., twentytwentyfour/post-meta).
- Future improvements
- Attribute-setting on inserted instances.
- Broader scope and robustness tracked in the feature’s improvement issue(s).
Direct links to sections/examples in the article:
- Introduction to Block Hooks: https://make.wordpress.org/core/2023/10/15/introducing-block-hooks-for-dynamic-blocks/
- Tenets and limitations: https://make.wordpress.org/core/2023/10/15/introducing-block-hooks-for-dynamic-blocks/#:~:text=Tenets%20and%20current%20limitations
- Using Block Hooks: https://make.wordpress.org/core/2023/10/15/introducing-block-hooks-for-dynamic-blocks/#:~:text=Using%20Block%20Hooks
- block.json positions: https://make.wordpress.org/core/2023/10/15/introducing-block-hooks-for-dynamic-blocks/#:~:text=block.json
- hooked_block_types filter and parameters: https://make.wordpress.org/core/2023/10/15/introducing-block-hooks-for-dynamic-blocks/#:~:text=hooked_block_types
- Context type notes and future improvements: https://make.wordpress.org/core/2023/10/15/introducing-block-hooks-for-dynamic-blocks/#:~:text=It%E2%80%99s%20important%20to%20note%20that
## 📖 References:
- Make/Core: Introducing Block Hooks for dynamic blocks — https://make.wordpress.org/core/2023/10/15/introducing-block-hooks-for-dynamic-blocks/
- WordPress 6.4 announcement — https://wordpress.org/news/2023/10/wordpress-6-4/
## 🗣️ Paraphrase:
- Original idea: “The Block Hooks API allows a block to automatically insert itself relative to instances of other block types.”
- Paraphrase: The API lets one block declare where it should appear in relation to another block, and WordPress places it there automatically.
- Original idea: “The user has the ultimate control over any automatically inserted blocks.”
- Paraphrase: Even when a plugin adds blocks for you, you can still remove, move, or customize them in the editor, and your choices take precedence.
## 📰 Newsletter:
This week in WordPress: Hooks, but make them blocks. WordPress 6.4 shipped Block Hooks, letting plugins auto-insert dynamic blocks right where they belong—before, after, or inside other blocks—without mucking up your content. Think: a Like button slotted after Post Terms, or Login/Logout neatly tucked into your header nav. Users stay in control via the editor, and disabling a plugin removes its additions automatically. Heads-up: Block Hooks currently work in templates, template parts, and patterns, and only for dynamic blocks. Explore the dev note for examples and best practices in “Introducing Block Hooks for dynamic blocks” on Make/Core. For new builders, this is a great moment to learn how block.json and filters like hooked_block_types can supercharge extensibility. Plus, keep an eye on upcoming improvements like attribute configuration on inserted blocks. Happy hooking!
Link: Introducing Block Hooks — https://make.wordpress.org/core/2023/10/15/introducing-block-hooks-for-dynamic-blocks/
## ✅ Action Items:
Audience: Developer Advocate at GoDaddy (open source/WordPress), educator, contributor onboarding, sustai
> [!note]+ Document Notes
> tags:
> - #wordpress
> - #blockhooks
> - #development
> Author: Nick Diego
> Source: Make WordPress Core
> Reference: https://make.wordpress.org/core/2023/10/15/introducing-block-hooks-for-dynamic-blocks/
> date created: 2025-08-23 00:00
>
> # Title: Introducing Block Hooks for Dynamic Blocks (WordPress 6.4)
>
<!-- deep-read:sections start -->
## 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 Prompt](#-darvo-analysis-prompt)
- [🔍 SEO Evaluation](#-seo-evaluation)
- [🎯 Conclusion](#-conclusion)
### References:
- Make/Core Dev Note: Introducing Block Hooks for dynamic blocks — https://make.wordpress.org/core/2023/10/15/introducing-block-hooks-for-dynamic-blocks/
- WordPress 6.4 release news — https://wordpress.org/news/2023/10/wordpress-6-4/
## 📝 Summary:
WordPress 6.4 adds Block Hooks, an extensibility mechanism for Block Themes that lets a block automatically insert itself relative to other blocks. It mirrors classic filters/actions patterns for the block era. Two guiding tenets govern the feature: automatic front-end insertion on plugin activation and user control in the editor. Current scope limits insertion to templates, template parts, and patterns (not user-modified content), and to dynamic blocks (static blocks with save functions trigger validation errors). Developers can declare hooks via block.json (simple/unconditional) or the hooked_block_types filter (flexible/conditional, with context awareness).
## 📖 Main Content:
Block Hooks allow plugins to programmatically extend block-based sites without manual placement. Typical use cases: inject a Like button before Post Content, add a Login/Logout after a header Navigation, or append UI elements inside container blocks as first or last child.
Two implementation paths:
- block.json blockHooks: Unconditional insertions relative to all instances of target blocks where templates are unmodified. Positions: before, after, firstChild, lastChild. When injected as first/last child, an Editor “Plugins” panel appears on the target block to toggle insertions.
- hooked_block_types filter: Allows conditional insertion using the context (template, template part, or pattern) and anchor block position, with parameters for the hooked blocks list, position, anchor block name, and context. Context types differ: WP_Block_Template object for templates/parts, array for patterns.
Constraints and tradeoffs:
- To honor automatic insertion and user control, hooks are confined to theme layout sources: templates, template parts, and patterns (theme-provided, directory, or registered programmatically).
- Not supported: user-modified templates/parts, post content, user-authored patterns, and static blocks (those with save functions).
- Only default block instances can be inserted; attributes cannot be set yet. Improvements are planned.
Practical implications:
- Plugin authors can ship opinionated default placements without overwriting user content.
- Theme authors retain layout integrity while giving users control via the editor.
- Site owners benefit from consistent, upgrade-safe enhancements.
### 🗒️ Notes
- Concept and purpose
- Emulates classic hooks for block themes to extend layouts.
- Automatic, relative placement around “anchor” blocks.
- Core tenets
- Auto front-end insertion upon plugin activation; removal upon deactivation.
- Users retain full editor control to keep/remove/move/customize the inserted block.
- Scope and limitations
- Works only in templates, template parts, patterns (theme or directory or registered).
- Excludes post content, user-modified templates/parts, and user-created patterns.
- Dynamic blocks only; static blocks with save() cause validation errors.
- Inserted blocks use default attributes; attribute customization is not yet supported.
- Implementation options
- block.json
- blockHooks object maps anchor block → position (before, after, firstChild, lastChild).
- Applies unconditionally to all qualifying instances.
- Editor adds “Plugins” settings panel for firstChild/lastChild to toggle injected blocks.
- hooked_block_types filter
- Conditional logic by template slug (e.g., single), template part area (e.g., header), or pattern slug.
- Parameters: $hooked_blocks, $position (before/after/first_child/last_child), $anchor_block, $context (object/array).
- Must type-check $context.
- Examples
- Insert Like button before core/post-title in Single template.
- Insert core/loginout as last child of a header template part group/navigation.
- Insert Like button after core/post-terms inside a specific pattern (e.g., twentytwentyfour/post-meta).
- Future improvements
- Attribute-setting on inserted instances.
- Broader scope and robustness tracked in the feature’s improvement issue(s).
Direct links to sections/examples in the article:
- Introduction to Block Hooks: https://make.wordpress.org/core/2023/10/15/introducing-block-hooks-for-dynamic-blocks/
- Tenets and limitations: https://make.wordpress.org/core/2023/10/15/introducing-block-hooks-for-dynamic-blocks/#:~:text=Tenets%20and%20current%20limitations
- Using Block Hooks: https://make.wordpress.org/core/2023/10/15/introducing-block-hooks-for-dynamic-blocks/#:~:text=Using%20Block%20Hooks
- block.json positions: https://make.wordpress.org/core/2023/10/15/introducing-block-hooks-for-dynamic-blocks/#:~:text=block.json
- hooked_block_types filter and parameters: https://make.wordpress.org/core/2023/10/15/introducing-block-hooks-for-dynamic-blocks/#:~:text=hooked_block_types
- Context type notes and future improvements: https://make.wordpress.org/core/2023/10/15/introducing-block-hooks-for-dynamic-blocks/#:~:text=It%E2%80%99s%20important%20to%20note%20that
## 📖 References:
- Make/Core: Introducing Block Hooks for dynamic blocks — https://make.wordpress.org/core/2023/10/15/introducing-block-hooks-for-dynamic-blocks/
- WordPress 6.4 announcement — https://wordpress.org/news/2023/10/wordpress-6-4/
## 🗣️ Paraphrase:
- Original idea: “The Block Hooks API allows a block to automatically insert itself relative to instances of other block types.”
- Paraphrase: The API lets one block declare where it should appear in relation to another block, and WordPress places it there automatically.
- Original idea: “The user has the ultimate control over any automatically inserted blocks.”
- Paraphrase: Even when a plugin adds blocks for you, you can still remove, move, or customize them in the editor, and your choices take precedence.
## 📰 Newsletter:
This week in WordPress: Hooks, but make them blocks. WordPress 6.4 shipped Block Hooks, letting plugins auto-insert dynamic blocks right where they belong—before, after, or inside other blocks—without mucking up your content. Think: a Like button slotted after Post Terms, or Login/Logout neatly tucked into your header nav. Users stay in control via the editor, and disabling a plugin removes its additions automatically. Heads-up: Block Hooks currently work in templates, template parts, and patterns, and only for dynamic blocks. Explore the dev note for examples and best practices in “Introducing Block Hooks for dynamic blocks” on Make/Core. For new builders, this is a great moment to learn how block.json and filters like hooked_block_types can supercharge extensibility. Plus, keep an eye on upcoming improvements like attribute configuration on inserted blocks. Happy hooking!
Link: Introducing Block Hooks — https://make.wordpress.org/core/2023/10/15/introducing-block-hooks-for-dynamic-blocks/
## ✅ Action Items:
Audience: Developer Advocate at GoDaddy (open source/WordPress), educator, contributor onboarding, sustainable funding, aspiring OSPO director.
- Alignment prompt for future articles:
- “Analyze how this article’s feature or policy impacts: a) contributor experience (onboarding, docs, mentorship), b) open-source sustainability (maintenance load, funding implications, governance), c) developer education (teaching moments, curricula for PHP/JS/blocks/Git), and d) organizational OSPO strategy (risk/compliance, cross-team enablement, standards). Identify actionable ways to demo, document, and advocate for adoption, including accessible examples, sample curricula, and contributor-first workflows. Highlight transparency, inclusivity, and long-term maintainability within the WordPress ecosystem.”
- This article’s alignment:
- Contributor engagement: Block Hooks offers a clear, documented API surface, ideal for first issues and mentorship around block.json and filters.
- Education: Turn examples into labs—write a Like button plugin, toggle positions, and test template contexts.
- Advocacy: Promote patterns that respect user control and avoid content lock-in; document limitations (dynamic-only, not user-modified content).
- Sustainability: Encourages non-destructive, declarative extension points that reduce support burden and conflicts.
- OSPO goals: Model governance-friendly extensibility: safe defaults, editor transparency, clear scopes, and upgrade paths. Build internal guidance for plugin teams adopting Block Hooks.
## 🧪 Hypotheses:
- H1: Plugins using Block Hooks reduce manual setup time for site admins compared to traditional onboarding steps.
- H2: Declarative placement via Block Hooks results in fewer theme compatibility issues than custom render filters.
- H3: Editor-visible control of hooked blocks increases user trust and reduces plugin churn.
- H4: Limiting to dynamic blocks decreases front-end validation errors and support tickets.
- H5: Providing attribute configuration for hooked blocks (future feature) will increase developer adoption.
### 📊 Methodology:
- Data sources: Support tickets, plugin activation funnels, editor event telemetry, theme compatibility matrices, user surveys.
- Designs:
- A/B tests: Plugin with manual placement vs. Block Hooks auto-insertion.
- Cohort studies: Sites upgrading to 6.4 with plugins adopting Block Hooks vs. control.
- Usability tests: Editor tasks toggling first/last child insertions.
- Static vs. dynamic block error rate analysis pre/post 6.4.
- Analysis:
- Time-to-activate metrics, error rate comparisons, SUS scores, regression modeling for churn, chi-square for incident frequency.
### ❓ Questions:
- How should plugins communicate to users that a block was auto-inserted and is safe to move/remove?
- What governance guardrails should exist for themes that might override or hide hooked blocks?
- Which use cases most benefit from conditional context (template, area, pattern)?
- How can attribute defaults be safely introduced without breaking editor expectations?
### 🔮 Future Research:
- Attribute configuration for hooked blocks (schema, security, migration).
- Safe expansion into user-modified templates with conflict resolution UX.
- Telemetry standards for block insertion and user overrides.
- Interoperability guidelines between multiple hooking plugins targeting the same anchor.
### 💡 Implications:
- Advances best practices for non-destructive extensibility.
- Reduces friction in onboarding and setup, improving adoption.
- Informs policy for plugin repository guidelines around Block Hooks usage.
- Encourages clearer separation of content vs. layout in the block era.
### 🧠 Learning Styles Assessment:
- Readability: Upper-intermediate technical (approx. Grade 10–12).
1) Visual: Present — code blocks and structured headings. Improve with diagrams showing “anchor” vs. “hooked” positions and flowcharts for context typing.
2) Aural: Limited. Improve with an audio summary or short screencast walkthrough.
3) Verbal: Strong technical language and examples. Improve with analogies comparing Block Hooks to classic actions/filters.
4) Physical: Limited. Improve with hands-on labs and a starter repo.
5) Logical: Strong — step-by-step examples and parameters. Improve with decision trees for choosing block.json vs filter.
6) Social: Limited. Improve with links to discussion threads, Make/Core comments, and dev chat agendas.
7) Solitary: Moderate. Improve with reflection prompts and checklists for adoption readiness.
8) Naturalistic: Not applicable. Improve by using sustainability analogies (ecosystem balance of plugins/themes).
### 📊 Accessibility Assessment:
- Screen reader compatibility: Core site uses semantic HTML; images need consistent alt text. Improve by ensuring all example screenshots include descriptive alt text.
- Keyboard navigation: Generally good on Make sites; verify focus states on code blocks and anchored headings.
- Contrast/readability: Adequate; ensure high-contrast code snippets and scalable fonts.
- Text resizing: Generally responsive. Ensure pre/code blocks wrap and reflow without horizontal scroll on small screens.
### 🌍 DEIB Assessment:
- Cultural relevance: Global OSS audience but limited examples. Improve by including diverse use cases (e.g., multilingual sites, accessibility blocks).
- Inclusive language: Neutral and technical; define terms like “dynamic vs static” for non-native speakers.
- Neurodiversity support: Structure is good; improve by chunking text, using step lists, and concise summaries.
- Representation: No imagery; add examples reflecting varied communities and site types.
- Psychological safety: Encourage experimentation in non-production environments and provide clear rollback guidance.
### ✅ Logical validity:
- Sound reasoning:
- Deductive: If static blocks with save() cause validation errors, then restricting to dynamic blocks prevents those errors. Strengthens the safety rationale; could be enhanced with a brief explanation of validation mechanics.
- Causal: Activating a plugin → front-end insertion; deactivating → removal. Clear cause/effect aligned with tenets; could cite editor-state handling.
- Balanced view: Presents benefits alongside constraints, explaining tradeoffs to uphold user control; could add metrics or references to prior discussions.
- Logical flow: Intro → tenets/limits → how-to → examples → caveats → future work. Coherent progression aiding comprehension.
- Fallacies: None apparent; no appeals to authority or false dilemmas.
- Tone: Informative, pragmatic, contributor-friendly.
🔍 DARVO Analysis Prompt
- Deny: No denial present; the article acknowledges limitations upfront.
- Attack: No attacks on alternative approaches or stakeholders.
- Reverse Victim/Offender: Not present; no blame shifting.
- Conclusion: The piece is a technical explainer with neutral, collaborative tone; DARVO patterns are absent.
### 🔍 SEO Evaluation:
1) Keywords: “Block Hooks,” “WordPress 6.4,” “dynamic blocks,” “block.json,” “hooked_block_types” — present and natural.
2) Meta description: Not visible; recommend adding one including “Block Hooks” and “WordPress 6.4” within 150–160 chars.
3) Title tag: Clear and contains primary keywords.
4) Headers: Proper hierarchy; include key terms in H2/H3 (e.g., “Using Block Hooks,” “block.json,” “hooked_block_types”).
5) Content length: Sufficient for a dev note; focused and valuable.
6) Links: Internal links to related Make/Core resources could be expanded; external links minimal but acceptable.
7) URL: Clean, descriptive, keyword-rich.
8) Images: If present, ensure alt text and optimized sizes; code examples are already lightweight.
9) Mobile: Make sites are responsive; code wrapping should be verified.
10) Engagement: Code samples and examples encourage time-on-page; add CTAs to related docs or tutorials.
11) Schema: Consider Article schema; optionally add HowTo schema for step sections.
12) Social sharing: Ensure Open Graph/Twitter Cards with a concise summary and featured image.
## 🎯 Conclusion:
Block Hooks in WordPress 6.4 introduce a principled, user-respecting way for plugins to extend block-based layouts: automatic placement, editor visibility, and safe scoping to templates, template parts, and patterns. Today’s constraints (dynamic blocks only, no attribute injection, exclusion of user-modified content) are deliberate tradeoffs to preserve stability and control, with clear pathways for future enhancement. For developers, Block Hooks offer a modern, declarative alternative to fragile workarounds—streamlining onboarding, reducing conflicts, and aligning with sustainable open-source practices. You have read the entire article (100%).
<!-- deep-read:sections end -->
## Highlights
- Block Hooks work with Dynamic blocks, not Static blocks. Refer to [this article](https://developer.wordpress.org/news/2023/02/static-vs-dynamic-blocks-whats-the-difference/) on the difference between the two. ([View Highlight](https://read.readwise.io/read/01hcwq4xn3n7epqrt9m3pg5zgs))
- WordPress 6.4 introduces Block Hooks ([#53987](https://github.com/WordPress/gutenberg/issues/53987)), a feature that provides an extensibility mechanism for Block Themes. This is the first step in emulating WordPress’ [Hooks](https://developer.wordpress.org/plugins/hooks/) concept that allows developers to extend Classic Themes using filters and actions. ([View Highlight](https://read.readwise.io/read/01hcwpajgk6s39fg6c148pevna))
- the Block Hooks API allows a block to automatically insert itself relative to instances of other block types. ([View Highlight](https://read.readwise.io/read/01hcwpatcqycxrg12ftb652r0t))
- There are two core tenets of Block Hooks:
1. Front-end insertion should happen as soon as the plugin containing a hooked block is activated. In other words, the user isn’t required to insert the block in the Editor manually. Similarly, disabling the plugin should remove the hooked block from the front end.
2. The user has the ultimate control over any automatically inserted blocks. This means that a hooked block is visible in the Editor, and the user’s decision to keep, remove, customize, or move the block will be respected and reflected on the front end. ([View Highlight](https://read.readwise.io/read/01hcwpb1drfbmj3t1gvw919z1t))
- Block hooks are limited to templates, template parts, and patterns ([View Highlight](https://read.readwise.io/read/01hcwpb97nnes15r6t7v33afam))