Inside Our WordPress Stack

The problem: repeatable sites without interchangeable assumptions.

We want shared improvements to carry across our sites while preserving each site’s identity and editing needs. The temptation is to call the theme “the standard” and assume every installed copy is the same. Our records show why that is insufficient.

This Lab examines the local EKG Marketing source on September 14, 2026. It is an inventory and documentary review. It does not report a fresh test of a live WordPress or PHP environment.

Requirements and constraints.

• Shared appearance rules should have an identifiable home.
• A site’s brand should not require editing every shared file.
• Content functionality should be separable from theme presentation.
• A deployment should have an explicit scope and destination.
• The next editor should understand which changes belong in content and which belong in code.

What is actually in the checkout.

The two version numbers above were read from local theme headers. They describe the inspected files, not a current compatibility certification or a public release package.

Why the layers are separated.

The parent’s own description calls for a thin foundation. The child’s description assigns branding to the site. WordPress’s child-theme mechanism supports this separation, while user customizations can add another layer of precedence. WordPress child themes.

The same principle applies below the theme: content registration belongs with the functionality that owns it. A redesign should not be the event that makes an application record disappear from the editor.

The options and the cost of our choice.

A single theme for every site would make some updates easy but would pressure unrelated sites into the same presentation. A separate theme for every site would allow freedom while repeating maintenance work. Parent and child themes give us a shared base with local differences.

That choice earns its place only if the shared layer stays small and updates are checked against the sites using it. Ownership does not remove maintenance; it makes the responsibility ours.

What went wrong: the README described two plugins.

The local README said the repository deployed two plugins. The directory and deployment allowlist contained four. The September 12 work log also recorded updates to the additional SEO and reference plugins. The implementation had changed faster than the overview.

This is a concrete operational problem. Someone trusting the README could underestimate what a deployment would overwrite. The corrected lesson is to compare the deployment allowlist with the actual files before describing the scope of a release.

What was checked, and what still needs a runtime test.

AI assisted this inventory and the article draft. Human editorial approval and a runtime compatibility test are separate checks; neither is implied by the source inspection.

Adapt this pattern.

A school could keep shared accessibility and spacing decisions in its base while departments own their presentation. A nonprofit could separate common service functionality from campaign-specific styling. In either case, record the actual version at each destination.

The practical deliverable is a short inventory plus a release checklist. Download the workshop worksheets and adapt them to your own system.

What we learned.

The architecture was more useful than the old overview made it appear, and the overview was less reliable than its confident wording suggested. Documentation has to be checked against the artifact it describes. Naming a standard once does not keep it true.

Sources and further reading

Primary documentation checked September 14, 2026. Product behavior and terms can change; follow the source for current details.

• WordPress child themes
• Introduction to theme.json