Dynamic Template Parts in Block Themes Without Duplication

Every block theme project we touch eventually hits the same wall. The client wants a different sidebar on case study posts than on regular blog posts. Or a different header on the shop. Or a stripped-down footer on landing pages. And the cleanest way the block theme handbook gives you, on the surface, is to duplicate the entire template. Two templates. Three templates. Then someone edits one and forgets the other, and the brand identity starts drifting between page types.

I have watched this play out on builds where the editor was sharp and the developer was sharp and the templates still ended up out of sync. It is not a discipline problem. It is a tooling problem. Block themes intentionally do not support PHP conditionals inside HTML templates, so the polite answer for years has been duplicate-and-deal-with-it.

This week the WordPress Developer Blog published a clean way out, and it does not require a plugin, a child theme hack, or rebuilding the theme as a hybrid. It uses a filter that has been sitting in core since WordPress 5.1. Worth a careful look before you copy another template.

What is actually new

On June 18, 2026, Justin Tadlock published Dynamically loading template parts in block themes on the WordPress Developer Blog. The article shows how to use the render_block_data filter to swap the slug attribute of a core/template-part block right before it renders, based on whatever context PHP can see at that moment — the queried object, the post category, the page type, anything you can query.

The filter itself is not new. It landed in WordPress 5.1.0 in 2019, with the $parent_block argument added in 5.9.0. What is new is the explicit endorsement, on an official WordPress channel, that pointing it at template-part blocks is the right answer for context-sensitive layouts in block themes. Until now, the prevailing advice was either to duplicate templates or to register pattern-based variants.

The mechanic is tight. You hook render_block_data, check that the block being rendered is core/template-part, check that the current slug is the one you want to override (say, sidebar-post), confirm you are on a singular post view and that the queried object is a WP_Post, then rewrite $parsed_block['attrs']['slug'] to the context-specific value (sidebar-post-news, sidebar-post-case-study, whatever). Return the array. WordPress renders the swapped part. If the target file does not exist in parts/, the swap is skipped gracefully, so adding a per-category variant is opt-in and non-fatal.

The folder layout is the standard one defined by get_block_theme_folders() — parts/ is where template parts live in modern block themes (with block-template-parts/ kept as a legacy fallback). No new directory, no new naming convention. You drop sidebar-post-news.html next to sidebar-post.html and the filter routes to it.

Why it matters for WordPress / WooCommerce people

The honest reason this matters is that block themes have been losing edge cases to classic themes for three years on exactly this issue. A client says “different sidebar on product pages” and the dev shop has three bad options: duplicate the single template (and pay maintenance forever), build a plugin to register a custom template (and pay version-mismatch costs), or bolt on a hybrid PHP template that contradicts the whole block-theme model. None of those are good answers when you are pitching the Site Editor as the future.

For WooCommerce stores this is especially relevant. Product category pages, single product pages, cart, checkout, and account pages all routinely need different header heights, different footers, different cross-sell sidebars. The conventional answer has been to override WooCommerce templates in PHP. With render_block_data, you can keep the block theme intact and swap parts based on is_product_category(), is_checkout(), or any conditional WooCommerce already exposes — the same way you would have done it in functions.php a decade ago, but cleanly applied at the block layer.

It also matters because it composes well with the rest of the platform. The filter runs before the block is rendered, which means it runs before the block’s render_callback, before block bindings resolve, and before the block markup hits the response. That ordering means anything downstream — view transitions, speculative loading, the upcoming AI Client embeddings work targeted at WordPress 7.1 — sees the final swapped output, not the placeholder. No double-render. No cache-busting weirdness.

For default-theme work, this is the pattern that finally makes Twenty Twenty-Five and downstream block themes flexible enough for editorial sites without the duplication tax. We have a couple of magazine builds where the template count was creeping past twenty. This pattern can collapse them back to single digits.

What I would do (or not do) about it

I would adopt this pattern, carefully. Three rules from twenty years of touching production themes.

One: keep the filter callback in a mu-plugin or in the theme’s functions.php, not scattered across files. The filter runs on every block render. If you do anything expensive inside it, the cost compounds. Early-return as fast as possible. Check block name first, then slug, then context. Do the cheapest comparison up front.

Two: do not use this to express what should be a pattern. If the variant is purely visual and editors should be able to insert it themselves, register a synced or unsynced pattern and let the editor choose. Use render_block_data only when the swap should be invisible to the editor and tied to a system rule — category, post type, user role, locale, time of day. Editorial decisions belong in the editor. Routing decisions belong in code.

Three: name the swapped files consistently. sidebar-post.html is the default. sidebar-post-{category-slug}.html is the override. Pick a convention and stick to it across the project. Future-you, six months from now, opening the theme cold, will thank present-you for not getting cute with the naming.

What I would not do is apply this to the navigation block or the post content block. The article correctly scopes the technique to template parts. Slugs on those blocks behave differently and you will create harder-to-debug problems than the ones you set out to solve.

The block theme model just got more usable without getting more complicated. That is the kind of update I like — a quiet filter, used the right way, that removes a category of duplication from real codebases.