One core theme. One core plugin. A growing collection of business addons. And a scaffolder that makes spinning up a new one feel like cheating.
Code structured clearly enough that an AI can jump in, understand the whole thing, and actually be useful without explaining the project from scratch every time.
Lubinik is my private WordPress framework. Not a product, not a public starter kit, not a shiny promise. More like a working notebook turned into code: the place where I keep the foundations I do not want to rebuild by hand every time.
It started from a pretty ordinary frustration. I did not like the way I was building WordPress sites. I wanted to understand WordPress properly, keep control of the code, and stop depending on visual builders for things I could make cleaner myself.
The first version was just a theme for a B&B site, with everything mixed together. Then the project grew, the files got too long, and the pattern became obvious: some parts belonged to every site, and some parts only belonged to that specific project.
So Lubinik became a parent theme, a core plugin, child themes, and small domain addons. Not because I planned a framework from day one, but because every real project forced one more separation, one more rule, one more reusable piece.
BnB, shelter, freelance portfolio, comics, showcase. Each addon came from an actual need. Each refactor is basically a note to future me: “next time, don’t rebuild this from scratch.”
Not for sale. Just the system I use to build my own sites.
Every addon started as a real project problem.
Messy history first, cleaner architecture later.
“I did not set out to build a framework. I just got tired of rebuilding the same WordPress foundations.”
— The boring little thought that became Lubinik
Lubinik did not start as a framework. I did not sit down one morning with a clean architecture diagram and a perfect plan for themes, plugins, addons, child themes, support plugins, generators, and design...
Read More about I Did Not Mean to Build a FrameworkFor a while, my relationship with WordPress was mostly avoidance with a side of resignation. I did not like Gutenberg. I did not like the feeling of fighting the editor to build something that,...
Read More about Making Peace With WordPress the Hard WayThe first Lubinik-shaped project was a BnB theme, and at the beginning it had everything inside it. That was not a mistake in the dramatic sense. It was simply the stage the project was...
Read More about The First BnB Theme Had Everything InsideThe first big refactor was not the final Lubinik architecture. It was more like opening a window in a room that had become too full. The BnB theme had reached the point where the...
Read More about The First Refactor: Theme, Plugin, Breathing RoomThe first BnB child theme was the first real child theme in the Lubinik story. It belonged to the early BnB phase, and it was useful in exactly the way first real projects tend...
Read More about The First BnB Child Theme Was Useful and MessyThe shortcode manager came from a small, stubborn annoyance. I wanted to build homepages with real templates, not with a visual builder. But I also did not want every section to be hardcoded directly...
Read More about The Shortcode Manager Was Born From a Very Specific AnnoyanceLubinik is split into layers because every project taught me the same lesson: the reusable parts, the domain parts, and the visual identity should not live in the same messy pile.
The shared site foundation. It handles the things a normal website almost always needs: headers, footers, menus, heroes, blog layouts, custom sections, testimonials, FAQs, breadcrumbs, tabs, maps, separators, and the theme-side shortcode manager.
The shared backend layer for addons. It keeps the reusable plugin-side tools in one place: shortcode registry, plugin shortcode manager, template resolver, asset conventions, gallery and calendar components, filters, pagination, tabs, CTA and share buttons.
Addons are where a project gets its real content model. A B&B does not need the same entities as a shelter, a portfolio, a comic archive, or this showcase site. So each addon brings only the CPTs, taxonomies, metaboxes, shortcodes, templates, and admin logic that belong to that domain.
The child theme is the site-specific layer. It owns the visual language, the design packs, template metadata, CSS choices, header and footer overrides, and the final composition of the site. It can reshape the presentation without forcing the parent theme or addon to become site-specific.
The scaffolder exists because copying an addon by hand is boring, fragile, and exactly the kind of work that should become rules once the pattern is stable. It can generate CPTs, taxonomies, meta files, shortcodes, CSS, JS, templates, and loader files from configuration.
lubinik-example-addon/
├── plugin.json ← addon metadata
├── lubinik-example-addon.php ← entry point
├── includes/
│ ├── custom-posts/
│ │ ├── post-types/ ← CPT definitions + meta
│ │ └── taxonomies/ ← project taxonomies
│ ├── shortcodes/ ← focused entity sections
│ ├── loader-shortcodes.php
│ └── helpers.php
├── templates/
│ └── lubinik-example/ ← selectable page/entity templates
├── assets/
│ ├── css/
│ └── js/
└── config/
├── translation/
├── seo/
└── structured-data/One framework, many verticals. Each addon was built for a real project, that's why they actually work.
Lubinik grew during the first years where coding with AI started to feel genuinely useful. I used it a lot, but the project also taught me where AI gets fragile: huge files, vague structure, repeated copy-paste work, and too many decisions hidden in one place.
So part of the architecture became a way to collaborate better with AI without letting it drive the whole system. Clear folders, repeated conventions, small focused files, explicit config, and generated scaffolding all make the codebase easier to explain, inspect, and change.
The goal is not to make AI replace the architecture. It is the opposite: the architecture gives the AI less chaos to improvise around.
If an addon always needs CPTs, taxonomies, meta files, shortcodes, assets, and loaders, that should become scaffolder config instead of a long prompt.
Once I understand one addon, the next one should not feel like a brand new codebase. That helps me, and it helps the AI stay oriented too.
AI is useful for exploring designs, debugging, writing focused code, and comparing options. But predictable setup work belongs in templates and generators.
AI was cheap and exciting when this started. I still wanted a system that would make sense later, even if prompts became expensive, slower, or less available.
Lubinik did not start as a framework. It started with me being annoyed at WordPress, wanting to understand it properly anyway, and building a first B&B theme while experimenting with AI coding tools.
The first version had everything inside it: templates, CPTs, galleries, calendars, admin fields, project logic, reusable logic. It worked, but it also became obvious that I was mixing too many responsibilities in one place.
So the project slowly split itself apart. The reusable site foundation became the parent theme. Shared plugin-side tools became the core plugin. Project-specific models became addons. Site-specific design stayed in child themes.
This site is here to document that evolution: the useful parts, the messy parts, the refactors, and the decisions that only made sense after building real sites with the system.
Lubinik is my personal WordPress framework: a parent theme, a core plugin, addons, child themes, support plugins, and a scaffolder that grew out of real projects.
It is not a commercial framework or a public starter kit. It is the system I built because I kept rebuilding the same WordPress foundations and wanted a cleaner way to separate what is reusable from what belongs to one specific site.
It is all three, in layers.
The parent theme handles generic site structure. The core plugin handles reusable plugin-side infrastructure. Addons bring project-specific content models. Child themes carry the visual identity and site-specific presentation.
That split did not exist at the beginning. It appeared through refactoring, after real sites made the boundaries impossible to ignore.
No. Lubinik is not a public product right now.
This site exists to document the project and the decisions behind it. It is more of a developer log than a sales page. I am showing the work, the evolution, and the architecture because the story itself is useful.
Because I wanted to understand WordPress properly instead of only working around it.
For a while, visual builders made WordPress tolerable. But I still wanted to code, understand the internals, and keep control over structure. Lubinik started from that tension: not loving WordPress, but wanting to make peace with it by building a system that felt understandable.
No. The first version was just a BnB theme with too much inside it.
It had templates, CPTs, galleries, calendars, admin fields, frontend styles, and project-specific logic all mixed together. That was fine for learning and building the first thing that worked, but it also made the next refactor inevitable.
The first turning point was realizing that the theme was carrying two different responsibilities: reusable website foundations and BnB-specific logic.
That led to the first split: a reusable parent theme on one side, and plugin-side content/behavior on the other. It was not the final architecture yet, but it was the first moment where Lubinik started becoming a system instead of a single project.
The parent theme keeps the reusable site foundation: headers, footers, menus, generic page mechanics, template shells, blog pieces, share buttons, breadcrumbs, and other common site elements.
Child themes keep the site-specific design. They can define their own template packages, CSS, JS, header/footer overrides, and metadata. That way, the visual identity of one site does not leak into the reusable foundation.
Only things that are generic enough to be useful across different sites.
If a feature is purely visual or tied to one site, it belongs in a child theme. If it is tied to a specific content model, it belongs in an addon. The parent theme should stay boring in the best way: stable, reusable, and not stuffed with one-off project decisions.
The core plugin is the shared plugin-side layer. It carries infrastructure that addons can reuse: shortcode manager logic, shortcode discovery, shared frontend components, gallery and calendar systems, list/filter foundations, settings patterns, and entity-page conventions.
It exists so addons do not have to copy the same base machinery every time.
Because I wanted configurable pages without building or depending on a visual builder.
The shortcode manager lets a coded template render selected sections in an admin-defined order. I can activate sections, reorder them, and configure basic attributes while keeping the actual structure in files.
Not really.
It does not try to replace Gutenberg, Oxygen, or a drag-and-drop builder. It is more constrained: code owns the templates and shortcodes, while the admin controls which prepared sections appear and in what order.
They solve the same kind of problem in different layers.
The theme shortcode manager assembles generic pages such as the homepage, journal page, or custom sections. The plugin shortcode manager assembles addon/entity pages, such as a case study page, an animal profile, or a project page.
Because hardcoding works until every small editorial change becomes a PHP change.
The shortcode manager keeps templates code-owned, but gives enough admin control to turn sections on/off, reorder them, and adjust their settings. It is a middle path between hardcoded pages and full visual editing.
Because creating a new addon involved too much predictable copy/rename work.
At first, AI could help with that. But I did not want every future addon to depend on a giant prompt, a large context window, or the assumption that AI would stay cheap. The scaffolder turns repeated structure into configuration and templates.
The scaffolder can generate addon structure, custom post types, taxonomies, meta files, shortcode files, template files, JS/CSS pieces, and loader wiring based on configuration and template mappings.
The goal is not to generate a finished project magically. The goal is to start from a consistent, predictable structure so the remaining work is the interesting project-specific part.
Lubinik was built with AI help, but not blindly.
AI was part of the workflow from early on, especially for exploration, refactoring, and repeated code generation. But the architecture came from real constraints, debugging, reading code, and making decisions about where responsibilities should live.
Yes, but in a practical way.
Shorter files, consistent addon structure, explicit metadata, generated skeletons, and clear separation of responsibilities all make it easier for an AI assistant to understand the project without getting lost. The point is not to let AI decide everything; it is to make collaboration less chaotic.
Because translation needed to work with the way Lubinik stores content: CPT fields, meta fields, options, shortcode manager labels, taxonomies, menus, sliders, forms, and SEO data.
The Translation plugin follows the same philosophy as the rest of Lubinik: the engine stays shared, while each theme, addon, or plugin can provide its own translation rules.
SEO Light exists because Lubinik needed code-owned SEO defaults, helper-based dynamic metadata, sitemap control, translation integration, and per-post overrides without turning SEO into a huge external dependency.
It is intentionally small. The idea is not to compete with major SEO plugins. It is to give Lubinik enough SEO structure for the kind of sites it builds.
It lets each layer contribute the schema it owns.
The parent theme can define generic site/page schema. The core plugin can define shared entity logic. Addons can define schema for their own CPTs. Child themes can add site-specific details. The plugin merges those fragments and renders JSON-LD.
The same rule appears in all three: engine here, rules there.
The plugin provides the engine. The parent theme, child theme, core plugin, and addons provide the rules that belong to their own layer. That keeps the support plugins reusable without forcing them to know every future content model in advance.
Because they came from the same instinct: if a small practical task keeps costing time or money, build a focused tool instead of depending on another subscription.
Tools like Make It Circle, QR Code Generator, Background Remover, Color Palette Extractor, and Resume Generator are not WordPress addons, but they belong near the project because they support the same working style.
Not as cleanly as it should yet.
The core already has some foundations, but proper multi-addon support would need a clearer addon registry, scoped shortcode metadata, entity-aware manager screens, collision detection, and more explicit ownership of templates, assets, and admin menus.
The architecture became clearer every time a real project made a boundary painful.
Lubinik did not start as a neat diagram. It became one refactor at a time: move generic things into the parent theme, shared plugin-side things into core, project-specific things into addons, visual identity into child themes, and repeated addon structure into the scaffolder.
Because the story is the point.
Lubinik is not being presented as a polished public framework. It is a record of how a private system grew from frustration, repetition, AI-assisted work, and real WordPress projects. The useful part is not only the code; it is the reasoning that shaped it.
Questions, ideas, feedback — or just want to talk WordPress and AI. Always happy to exchange.
Send a message →