Template Parts (legacy)

Working with a theme framework like this one that utilizes action hooks to control just about everything can provide you with a completely dynamic Child theme development experience. With that said, I feel that there is a certain element that becomes lost in this process, and that’s the luxury of actually getting a look at your HTML markup and WordPress theme tags outside of deeply-hooked PHP functions.

When opening a standard theme file within the Theme Blvd framework to see how it’s constructed (i.e. page.php, single.php, archive.php, etc), I feel it’s important that you’re presented with something that you are at least somewhat familiar with as a WordPress theme developer. To do this meant the outer HTML markup had to be crafted just right to give you the most flexibility from your Child theme while still keeping most items hooked within. And so while these common theme files are not intended to be edited, it is at least possible as a last resort.

So, then what files are we intended to edit?

And this question brings us to our big point – As a WordPress theme developer, you shouldn’t completely lose the ability to work with some basic HTML and WordPress theme tags. With our framework, you can forget about copying and pasting the same wrapping HTML code into the common theme files like page.php, single.php, etc, and instead just work with the template parts nested within the core of the standard theme files.

Template part files explained

Within each main theme file, the framework utilizes WordPress’s get_template_part function with a slight twist. Each use of get_template_part corresponds to a dynamically generated file ID that you can change from your Child theme (if you want).

Here’s an example to a call to one of these template parts in the wild at page.php.

The use of get_template_part is what allows this file inclusion to be compatible with your Child theme. In the above screenshot, you can see that the use of get_template_part is setup to include a file named content-{file_id}.php. The framework uses the function themeblvd_get_part to pull that file id.

For example, by default, themeblvd_get_part('page') will simply return “page” in order to include the file named content-page.php, which looks something like what you see in the following screenshot:

So, in the event you wanted to change how the content area is displayed within a page, you’d simply copy content-page.php to your Child theme and make your edits from there. Now what you have is a simple theme file that looks familiar to you already as a WordPress theme developer, but is much less complicated than editing an entire theme file such as page.php, which contains certain items needed by the framework to construct the page, and also has a higher chance of being modified in future theme updates.

Default Template Parts

Working with default template parts

As a result of the “Default Template Parts” table, we have the following template part files within Jump Start.

Working within the scope of the content files that already exist, it’s very easy to make changes. You just simply copy the default files to your child theme and then make your edits to them.

Changing which content files are called

Changing a file ID

Here’s an example of how you could change the file ID for the “page” template part from your child theme’s functions.php.

function my_template_parts( $parts ) {
	$parts['page'] = 'my_new_file_id';
	return $parts;
}
add_filter( 'themeblvd_template_parts', 'my_template_parts' );

Incorporating the new file

Now that we’ve changed the file ID for what gets used in pages to “my_new_file_id” we’d need to now create a new file called content-my_new_file_id.php and place it in our Child theme’s directory.

Examples

The previous example of editing which file gets used for pages most likely isn’t something you’d often be doing, but hopefully that helped for you to understand how the system works. Now, let’s go over some more real-world examples that might be more practical.

Example #1: Create a new content file for how posts are displayed within search results

In looking back at the “Default Template Parts” table, we can see that currently both archives and search result pages use the same file id – archive – meaning both will use content-archive.php from the Parent theme in order to display each post.

But what if we want to have a different display for posts in a search results page? We could incorporate a new file id by doing something like this from the functions.php of our Child theme.

function my_template_parts( $parts ) {
	$parts['search_results'] = 'search_result';
	return $parts;
}
add_filter( 'themeblvd_template_parts', 'my_template_parts' );

And so now we can create a new file called content-search_result.php in our Child theme’s directory to display how posts appear in a search results page, while still allowing archive pages to pull from content-archive.php already existing in the Parent theme.

As a quick starting point to do this after we’ve applied our filter above, maybe we could copy content-archive.php to the Child theme, change its name to content-search_result.php, and continue editing it.

Example #2: Create a different file for how posts are displayed in all types of archives

Now let’s expand on the previous example. It was easy to add a new file for search result pages because that already had a template part ID, but what about other archives? There is only one template part ID for all archives. This means that all archive pages (i.e. Tag archives, Category Archives, Date archives, Author archives, etc.) will all use the same file: content-archive.php

To do this, we can utilize standard WordPress conditionals within our filter function. So, below is how we’d do this in combination with out previous example of incorporating a file for search results.

function my_template_parts( $parts ) {
	
	// Search results
	$parts['search_results'] = 'search_result';
	
	// Different archives
	if( is_category() ) {
		$parts['archive'] = 'category';
	} else if( is_tag() ) {
		$parts['archive'] = 'tag';
	} else if( is_date() ) {
		$parts['archive'] = 'date';
	} else if( is_author() ) {
		$parts['archive'] = 'author';
	}

	return $parts;
}
add_filter( 'themeblvd_template_parts', 'my_template_parts' );

And so now we can create the following files within our Child theme’s directory.

• Search Results – content-search_result.php
• Category Archives – content-category.php
• Tag Archives – content-tag.php
• Date Archives – content-date.php
• Author Archives – content-author.php

Example #3: Use the same content file for posts whether they’re in an archive, post list or in single view for a more typical “blog” theme setup

In a more simplistic “blog” type WordPress theme, often there is one file used to display posts in most scenarios, whether it’s the homepage, an archive, a search results page, or a single post. In this example, we’ll set it up so all of these kinds of content pull from a single file named content-loop.php.

You’d do the following within the Child theme’s functions.php.

function my_template_parts( $parts ) {
	$parts['archive'] = 'loop';
	$parts['index'] = 'loop';
	$parts['list'] = 'loop';
	$parts['search_results'] = 'loop';
	$parts['single'] = 'loop';
	return $parts;
}
add_filter( 'themeblvd_template_parts', 'my_template_parts' );

Now we can just create one file in our Child theme’s directory called content-loop.php.