The Lubinik scaffolder did not start as a grand generator for everything.
At first, it had one very practical job: help me create new addons without copying an old addon by hand and hoping I renamed every file, function, text domain, slug, shortcode, CSS handle, template folder, and helper correctly.
That already changed the way I worked. Addons stopped feeling like big blank starts. They became something I could generate from a known structure, then adapt where the project actually needed thought.
But once the addon side became clearer, another pattern started becoming obvious: child themes were evolving too.
The child theme became a real layer
In the early Lubinik projects, child themes were messier. They were useful, but they still carried the feeling of “this is where the current site happens”. That is normal for a first version. A child theme begins as a place to put the site-specific design, the templates, the CSS, and the little decisions that do not belong in the parent theme.
Over time, that layer became much more structured.
The newer child themes have clearer page templates, entity-page metadata, CSS loading rules, helper files, API configuration, SEO configuration, structured-data configuration, and now design packs. A child theme is no longer just a folder full of overrides. It is the visual and site-specific memory of a Lubinik project.
And when a structure becomes stable enough, Lubinik usually asks the same question:
Should I keep rebuilding this by hand, or should it become configuration?
The same idea, but for child themes
The new child-theme scaffolding is deliberately separate from the addon scaffolding. The addon generator still does what it already did. The child generator has its own script, its own config, and its own structure file.
That matters because the two things are related, but not identical. An addon describes a business model or a content model: custom post types, taxonomies, shortcode sections, templates, admin fields, and domain logic. A child theme describes how a site presents itself: design packs, page templates, components, assets, metadata, and site-level configuration.
So the scaffolder now has a child-theme path too. It can take a stable source child theme, copy the right files and folders, rename what needs to be renamed, and generate a new child theme foundation without dragging the old identity everywhere.
The important part is not that it saves a few minutes. The important part is that it saves attention.
Why this felt like the right next step
After the Showcase child theme evolved into a multi-design child theme, it became a better base for future projects. It had the newer design-pack logic, cleaner metadata, and a more realistic example of how a Lubinik child theme should behave now.
That made it a good candidate for a source template.
The scaffolder can now use the same kind of thinking it already uses for addons: a config file for replacement pairs, a structure file for what should be copied, optional flags for files that may not belong to every child theme, and rename rules for paths or content that should change with the new project.
It is not magic. It is just a way of making the boring parts explicit.
That is very Lubinik, actually.
What this changes
Before this, starting a new child theme meant copying an existing one and manually cleaning up all the old project references. That works once or twice, but it is fragile. Old names stay hidden in helpers. CSS handles point to the wrong design. Template folders keep the wrong domain language. Configuration files are easy to forget.
Now, the first pass can be generated.
- The child theme slug can be renamed consistently.
- The text domain can follow the new child theme.
- Function prefixes can move away from the source project.
- Design-pack folders can be renamed with the new project identity.
- Site-level config folders can travel with the child theme instead of being rebuilt from memory.
There will still be real work after generation. There should be. A new site deserves its own design, content, and decisions. But the scaffolder can handle the mechanical foundation so I can spend more time on the parts that actually define the project.
A small but important shift
This also changes how I think about future migrations.
If an older site needs to come back into Lubinik, I do not want to start from an empty child theme. I want a stable modern base, then a controlled migration of the old design and content into that base. The child scaffolder makes that starting point less chaotic.
It also keeps the parent theme clean. I do not need to make the parent theme know about every visual experiment or every project-specific template. The child theme carries that. The scaffolder just helps create the child theme in a way that respects the current architecture.
That is the quiet evolution here: Lubinik is not only generating business addons anymore. It is starting to generate the site layer too.
And that feels like the right direction. Not because everything should be automated, but because the repeatable parts should stop stealing energy from the meaningful parts.
