Child Themes Became the Visual Memory of Each Site

June 24, 2026 Lubinik Journal

Child themes have a very specific job in Lubinik: they should make a site feel like itself.

The parent theme provides the reusable site foundation. The core plugin provides plugin-side infrastructure. Addons provide domain models. Child themes should carry the visual language, site-specific templates, contextual assets, and the final decisions that make one site different from another.

That sounds clean now, but it was not clean at the beginning.

The first BnB child theme had to do too much. It copied internals, replaced shortcodes, patched scripts, adjusted plugin behavior, and carried the design all at once. It was useful, but it showed why future child themes needed better conventions.

The metadata-driven child theme

JT Child was the bridge to the cleaner model. It introduced the pattern that later child themes kept using: template packages with metadata.

A template package can declare its context, assets, removals, overrides, partials, and layout files. Instead of globally hacking the child theme, a page or entity context can say exactly what it needs.

Musi Sereni, Passione Gatti, Comics, and Showcase all belong to that newer line. They still have strong visual identities, but the structure is more predictable. The child theme becomes a design and presentation layer instead of a second hidden addon.

That matters because visual systems change. Clients change their minds. Personal projects evolve. A child theme should be able to absorb that without forcing the parent theme or addon to become site-specific again.