My team and I have been working on a music-related WordPress project. For the project, I needed a way to display a different sidebar depending on what page the site visitor was viewing. It\u2019s a question that comes up from time to time from block theme authors.<\/p>\n\n\n\n
In classic themes, this always felt straightforward: you just dropped your logic for loading a different template part right in the template itself. While there are architectural design issues with putting logic code in templates\u2014which are largely irrelevant for this post\u2014it simply worked. You could call For block themes, you cannot do that in HTML-based templates. Even in PHP-registered patterns, you don\u2019t have access to most data before they are processed (patterns are registered on The answer for block themes has been to use multiple top-level templates. Create a template for this category, another one for that tag, a third for something else entirely. It works, but it also means maintaining a growing pile of nearly identical templates that differ only in which template part they load.<\/p>\n\n\n\n There’s a better way. WordPress lets you intercept block data before it renders and swap out a template part’s slug on the fly\u2014replacing a default template part with a context-specific one. And while my use case is sidebars, the same technique works for any template part: headers, footers, banners, comments sections, whatever your theme needs.<\/p>\n\n\n\n This tutorial will walk you through how to build this system, starting with the core filter and expanding into broader use cases.<\/p>\n\n\n\n Table of Contents<\/p>\n\n\n\nget_sidebar()<\/code>, get_header()<\/code>, get_footer()<\/code>, or get_template_part()<\/code> and pass any variable to the functions\u2019 parameters to get what you needed.<\/p>\n\n\n\ninit<\/code>), so contextually loading template parts<\/a> won\u2019t work.<\/p>\n\n\n\n