Home » Parent / Child Themes

Parent / Child Themes

Boilerplate is designed as a WordPress parent theme. Project-specific work should live in a child theme whenever possible, keeping the parent theme stable, reusable, and safe to update.

In WordPress, a child theme inherits the parent theme and can override selected files or add project-specific behavior without directly editing the parent theme. See the official WordPress Child Themes documentation for the underlying parent/child theme model.

Parent Theme Responsibilities

The parent theme owns the reusable baseline: core templates, layout partials, PHP helpers, menu support, widget support, comments, breadcrumbs, smart excerpts, build output expectations, SASS defaults, JavaScript behavior, and Bootstrap integration.

Primary files: style.css, functions.php, config.php, partials/, templates/, assets/

Use this for: reusable theme systems that should benefit every Boilerplate-based project.

Child Theme Responsibilities

The child theme owns project-specific customization: branding, configuration changes, template overrides, SASS variable overrides, custom styles, custom scripts, project templates, and client-specific behavior.

Primary files: child theme style.css, child theme functions.php, child theme config.php, child theme templates/partials/assets

Use this for: changes that belong to one project, one brand, or one client implementation.

Child Theme style.css

A child theme must declare its parent with the WordPress Template header in style.css.

/*
Theme Name: Example Child Theme
Template: boilerplate
*/

File: child theme style.css

Template Override Strategy

Override templates only when the project needs different markup or different template behavior. Keep shared structure in the parent theme whenever possible.

Parent locations: root templates, partials/, templates/
Child locations: matching paths in the child theme

Use this for: project-specific page structure, custom post output, altered layout regions, and markup changes that cannot be handled through hooks/configuration.

Layout Partials

Boilerplate templates rely on shared layout partials so repeated structure is not duplicated across every template.

Primary files: partials/layout/top.php, partials/layout/bottom.php, partials/layout/navbar.php, sidebar.php

Use this for: shared page chrome, layout wrappers, navbar/sidebar placement, and site-wide template structure.

Function Override Strategy

Parent theme functions that are intended to be replaceable should be wrapped in function_exists(). Child themes can define the function first, allowing the parent fallback to be skipped.

if( ! function_exists( 'bp_example_function' ) ) :
function bp_example_function() {
    // Parent fallback.
}
endif;

Use this for: intentional PHP override points where a child theme may need to replace parent behavior cleanly.

Hook-Based Extension Strategy

Prefer action hooks when a child theme only needs to add content before, inside, or after an existing parent theme region.

Common pattern: do_action( 'bp_*' )

Use this for: adding project-specific output without copying an entire parent template.

Configuration Override Strategy

Use child theme configuration for project-specific feature flags and defaults. The child theme configuration should define the project baseline before the parent theme falls back to its default configuration.

Parent file: config.php
Child file: child theme config.php

Use this for: project feature flags, layout defaults, theme identity, build/version constants, comments/search/sidebar behavior, and other PHP-side settings.

SASS Override Strategy

Parent SASS variables use !default, allowing child theme variables to override parent defaults before the parent SASS stack is compiled.

Parent files: assets/sass/parent_theme/variables.scss, assets/sass/parent_theme/bootstrap/variables.scss

Use this for: branding, colors, typography, spacing, borders, layout widths, Bootstrap defaults, and design-system tokens.

Asset Override Expectations

Parent theme compiled assets should remain stable. Child themes should add or override project-specific assets through child theme files and child theme enqueue logic instead of editing parent dist/ files directly.

Parent output: dist/css/, dist/js/, dist/font/

Use this for: preserving parent update safety while allowing project-specific CSS, JavaScript, images, and fonts in the child theme.

Rule of Thumb

If the behavior should apply to every Boilerplate project, it belongs in the parent theme. If the behavior is project-specific, client-specific, or brand-specific, it belongs in the child theme. Prefer configuration and hooks first, function overrides second, and full template overrides only when the markup really needs to change.

© 2026 Boilerplate