WordPress get_template_part Example: Pass Reusable Template Args Cleanly

Last reviewed: April 29, 2026

Theme code becomes hard to maintain when the same article card, hero block, or CTA section is duplicated across archive, search, and landing templates. get_template_part() is the safer way to split that UI into reusable pieces without losing child-theme override behavior.

This guide shows how to use get_template_part() with named variants and the modern $args parameter so reusable template parts stay explicit and predictable.

Load a reusable template part with arguments

<?php
get_template_part(
	'template-parts/cards/article',
	null,
	array(
		'title_tag' => 'h2',
		'show_meta' => true,
		'variant'   => 'compact',
	)
);

Passing an argument array is usually cleaner than depending on ad hoc globals or temporary variables scattered through the template stack.

Read the arguments inside the partial

<?php
$title_tag = isset( $args['title_tag'] ) ? $args['title_tag'] : 'h3';
$show_meta = ! empty( $args['show_meta'] );
$variant   = isset( $args['variant'] ) ? $args['variant'] : 'default';
?>

<article class="article-card article-card--<?php echo esc_attr( $variant ); ?>">
	<<?php echo tag_escape( $title_tag ); ?>><?php the_title(); ?></<?php echo tag_escape( $title_tag ); ?>>
	<?php if ( $show_meta ) : ?>
		<p class="article-card__meta"><?php echo esc_html( get_the_date() ); ?></p>
	<?php endif; ?>
</article>

Keep the argument contract short and explicit. The more a partial depends on invisible context, the less reusable it really is.

Use named variants when the UI needs specialization

get_template_part( 'template-parts/hero', 'security' );

That will make WordPress look for template-parts/hero-security.php first, then fall back to template-parts/hero.php. It is a clean pattern for slight layout variations.

Remember that the same partial can be included more than once

The WordPress reference notes that the template part is loaded with require, not require_once. That matters when a card or CTA fragment must appear in several places during one request.

Production checklist

• Use $args for explicit per-render options.
• Prefer small, role-based partials over giant all-purpose fragments.
• Escape every argument before output.
• Use named variants only when the specialization is real.
• Keep the file structure predictable under a dedicated template-parts folder.
• Test archive, single, and search contexts after refactoring a shared partial.

Common mistakes

• Passing too much hidden context. A partial that needs everything is not really modular.
• Relying on globals instead of arguments. The coupling becomes harder to reason about.
• Skipping output escaping. Template parts still render user-controlled data.
• Using one huge partial for unrelated layouts. Smaller focused components age better.
• Forgetting child-theme override behavior. File naming should stay deliberate.

Related reading

If the theme needs to decide which root template runs at all, pair this with the template hierarchy guide. If the partial renders featured media, keep the image output aligned with the wp_get_attachment_image article.

References and further reading

• WordPress Code Reference: get_template_part()
• WordPress Theme Handbook: Template Files
• WordPress Code Reference: locate_template()