WordPress | Dynamic template parts for block themes

WordPress has published a practical tutorial on dynamically loading template parts in block themes, giving theme authors a cleaner way to change headers, sidebars, footers, banners, comments, or other reusable layout sections without duplicating entire templates. Published on June 18, 2026, the guide focuses on using the render_block_data filter to swap a Template Part block's slug before WordPress renders the page.


WordPress block theme sidebar template part displayed in a single post layout

{getToc} $title={Table of Contents}

WordPress block themes can load template parts more flexibly


Block themes make it easier to build layouts with HTML-based templates, but they also change how theme authors handle conditional layout logic. In a classic theme, loading a different header, sidebar, footer, or template part could be handled directly in PHP. In a block theme, the top-level template is usually HTML, so that same logic cannot be placed in the template file in the same way.


The tutorial shows a more flexible approach: intercept the block data before rendering and change the Template Part block's slug when a specific condition is met. For WordPress theme creators, this can reduce repeated template files and make block theme layouts easier to maintain when only one section of the page needs to change.



How the render_block_data filter helps


The key hook is render_block_data, which runs before a block is rendered. It gives developers access to the parsed block data, including the block name and attributes. When the block is core/template-part, the important attribute is slug, because that value tells WordPress which template part file should be loaded.


By checking the current page context and replacing the slug only when needed, a theme can keep a default template part while loading a more specific version for certain categories, post types, sections, or layout needs. This is useful for sidebars, but the same idea can also apply to headers, footers, banners, comments areas, and other reusable template parts.


Why this is useful for theme creators


The practical benefit is less duplication. Instead of creating several top-level templates that are almost identical, a theme can keep one main template and only switch the part that needs to be different. For example, a single post template can load a default sidebar for most posts, then load a category-specific sidebar when a matching template part file exists.


This can make block themes cleaner for designers who build editorial sites, magazines, portfolios, documentation sites, product blogs, or niche publishing templates. It also keeps the layout system more modular, because the conditional behavior is attached to the part that changes instead of forcing the entire page template to be copied.


What to check before using this pattern


This technique works best when the theme has clear naming rules for template part files. The tutorial uses a default parts/sidebar-post.html file and then checks for category-specific alternatives such as parts/sidebar-post-artist-spotlight.html or parts/sidebar-post-album-reviews.html. If a matching file exists, WordPress loads it. If not, the default part remains in place.


Theme authors should also be careful with performance and scope. The filter runs for every block on the page, so the implementation should exit early when the block is not a Template Part block, when the slug does not match the target part, or when the current page context is not relevant. Keeping those checks narrow helps the pattern stay predictable and lightweight.


REMEMBER: When using render_block_data, always return the parsed block data and add early checks so your logic only runs for the specific Template Part block you want to modify.{alertSuccess}

Daisuki's Take: What This Means for Web Designers


For web designers working with WordPress block themes, this tutorial is valuable because it shows a cleaner way to make layouts feel dynamic without turning the theme into a pile of duplicated templates. That matters when a site needs different sidebars, banners, or page sections while still keeping the overall structure consistent.


We think this pattern is especially useful for template creators who want to build flexible themes for real publishing workflows. A blog, magazine, or resource site often needs different contextual areas, but copying a full template for every variation can become difficult to maintain.


The takeaway is to think in smaller reusable parts. If only one area of the page needs to change, it may be better to swap that template part dynamically instead of duplicating the whole layout. For block theme work, that kind of structure can make a theme easier to update, easier to test, and easier to scale.



Sources and Recommended Links