Why We Built Our Own WordPress Theme
Our parent theme keeps shared structure in one place; a child theme carries the site’s identity. Here is what that division earns—and what it costs.
- Audience
- builder
- Level
- intermediate
- Basis
- Documented guidance
We wanted the same decisions to stay the same.
Across several websites, a typography fix or navigation improvement should not require rediscovering how each site works. We built a small parent theme to hold shared structure, then put the site’s visual identity in a child theme.
The local EKG Marketing source inspected for this article contains a parent named ekg-base and a child named ekg-marketing. The parent describes itself as a thin foundation. The child carries the warm paper, navy, typography and brand treatment you see here.
Give each layer one responsibility.
| Layer | Belongs here | Keep elsewhere |
|---|---|---|
| Parent theme | Shared setting names, spacing structure and common presentation behavior. | A particular site’s business rules and brand story. |
| Child theme | Site palette, typography, templates and visual adjustments. | Data definitions that must survive changing themes. |
| Focused plugin | Content registration or functionality independent of appearance. | General page styling. |
| Content records | The actual articles, product explanations and editorial relationships. | Repeated site-wide header markup. |
WordPress supports parent and child themes as separate layers. The theme.json file provides a common place for settings and styles. WordPress child themes; Introduction to theme.json.
Owning the foundation creates update work.
The theme is not automatically simple because it is ours. Every shared change needs review against the sites that inherit it. A menu improvement for one site may create a layout problem on another. A child that overrides most of its parent may be more difficult to maintain than a standalone theme.
The benefit depends on keeping the shared layer small. We ask whether a rule is true across the sites before promoting it into that layer. Otherwise it belongs with the site that needs it.
A version label is only part of the evidence.
Local records show different theme snapshots across sites and corrections to documentation that had fallen behind deployment behavior. That makes “use our theme” an inadequate handoff. A successor needs to know which copy, which release and which site.
We now treat the delivered artifact, the change record and the installed state as separate things to compare. A filename that looks familiar is not proof of equivalence.
Keep the editor’s view in the test.
A theme that makes an editor afraid to change a sentence has shifted work onto the wrong person. Test with the person who maintains the content: can they change a heading, reorder a section and preview the result without opening source files?
WordPress user customizations can also override theme files. When a file change does not appear, check the customization layer before assuming the deployment failed. The child-theme documentation describes this ordering.
Read Lab 001 for the source inventory. The workshop resources explain the current reference-theme release status.
Sources and further reading
Primary documentation checked September 14, 2026. Product behavior and terms can change; follow the source for current details.
KEEP EXPLORING