Templates
The template hierarchy Highend uses, and precisely which files a child theme can and can't override.
Highend uses WordPress's standard template hierarchy, plus a large set of template-parts/*.php partials for reusable regions (header, footer, loop entries, single content, and more). Which of these you can override from a child theme depends on how the parent theme loads them, not just where the file lives.
The short version
get_template_part()(WordPress core): checks the child theme first, then the parent. Overridable. This is how Highend loads every file undertemplate-parts/.- Standard template hierarchy / page templates (
header.php,single.php,page-templates/*.php, and so on): WordPress itself checks the child theme first. Overridable, the normal WordPress way. - A hard-coded
include/requirebuilt fromget_template_directory()or a constant likeHBTHEMES_ROOT/HIGHEND_THEME_PATH: those constants always resolve to the parent theme's folder (see Overview), so a file loaded this way ignores the child theme entirely. Highend doesn't use this pattern for any of its template output (everything renders throughget_template_part()or the normal hierarchy), but it's worth knowing the rule, since it's how some other themes and plugins load partials.
Root-level templates
These are all in the theme's root folder and follow WordPress's normal template hierarchy. A child theme overrides any of them by placing a file with the same name at its own root:
| File | Purpose |
|---|---|
header.php / footer.php | Site chrome: wraps every page. |
index.php | Fallback template (also renders the default blog listing). |
page.php | Default page template. |
single.php | Default single post template. |
single-portfolio.php | Single portfolio item. |
single-team.php | Single team member. |
archive.php | Category/tag/date/custom taxonomy archives. |
search.php | Search results. |
404.php | Not found page. |
comments.php | Comment list and form, pulled in via comments_template(). |
searchform.php | The search form markup, pulled in via get_search_form(). |
Page templates
page-templates/*.php are selectable templates with a Template Name: header, assigned per-page from the block/classic editor's Page Attributes panel:
blog.php, blog-grid.php, blog-grid-fullwidth.php, blog-minimal.php, contact.php, gallery-standard.php, gallery-fullwidth.php, portfolio-standard.php, portfolio-simple.php, presentation-fullwidth.php, login.php, maintenance.php, blank.php.
These follow WordPress's normal page template system. A child theme can override one by placing a file with the same relative path (page-templates/contact.php, for example) in its own folder, or add wholly new page templates of its own; WordPress scans both the parent and child theme folders when building the template picker.
template-parts/ (all loaded with get_template_part())
Every file under template-parts/ is loaded through Highend's own wrapper functions in functions/template-parts.php, and every one of those wrappers calls WordPress's get_template_part(). A few examples:
function highend_single_content() {
get_template_part( 'template-parts/single/single', get_post_type() );
}
function highend_footer_widgets() {
get_template_part( 'template-parts/footer/widgets' );
}
function highend_blog_loop( $template = '' ) {
get_template_part( 'template-parts/entry/entry', $template );
}Because get_template_part() checks the child theme's folder before falling back to the parent's, every file under template-parts/ is overridable from a child theme. Copy the file to the same relative path in your child theme (for example wp-content/themes/highend-child/template-parts/footer/widgets.php) and edit it there. This covers all of template-parts/misc/, footer/, entry/ (including entry/format/), content/, single/, top-bar/, and header/ (including header/layouts/).
Some calls use the two-argument form, like get_template_part( 'template-parts/entry/entry', $template ), which tries template-parts/entry/entry-{$template}.php first and falls back to template-parts/entry/entry.php. When you're overriding one of these, override the specific variant file (e.g. entry-blog-grid.php), not just the base one.
WooCommerce templates
The woocommerce/ folder contains Highend's copies of WooCommerce's own template files (cart, checkout, single product, product loop, and so on), following WooCommerce's documented override structure. Each file carries WooCommerce's own header comment confirming this:
/**
* This template can be overridden by copying it to yourtheme/woocommerce/content-product.php.
* ...
* @see https://woocommerce.com/document/template-structure/
*/WooCommerce's own template loader checks a child theme's woocommerce/ folder before the parent's, so these are overridable the standard WooCommerce way. See WooCommerce's template structure guide for version-tracking details (WooCommerce occasionally updates its template files and expects theme copies to catch up).
bbPress templates
The bbpress/ folder is Highend's copy of bbPress's default theme-compatibility templates (forums, topics, replies, user profiles, and login/registration forms). bbPress locates templates the same way WordPress does (child theme first, then parent), so overriding one of these works the same way as overriding a root template: copy it to bbpress/{file}.php in your child theme.
WPBakery element templates (vc_templates/)
vc_templates/ contains theme-level overrides for how a handful of WPBakery core elements render: vc_row.php, vc_column.php, vc_tabs.php, vc_tab.php, vc_accordion.php, vc_accordion_tab.php, vc_toggle.php, vc_custom_heading.php. This is WPBakery Page Builder's own theme-override convention (the js_composer plugin looks for a matching file in the active theme before using its bundled default). It isn't something Highend's own code wires up, so we can't verify the exact child-theme override behavior from the theme's source alone. In practice it follows the same active-theme-first pattern as the rest of WordPress's template loading; if you need to change how one of these elements renders, copying the file into your child theme's own vc_templates/ folder is the standard approach documented by WPBakery.