WordPress Themes as Artifacts

There’s a convention in WordPress development that features belong in plugins, not themes. The idea being that if you switch themes, you don’t lose functionality. It makes sense in the abstract.

But I work in-house on a single news site. We have a custom theme and a handful of custom plugins. We’re not switching themes. Nobody else is running our plugins. The assumptions behind the convention don’t apply.

I’ve been thinking about pulling our custom plugins into the theme itself — customisations, custom endpoints, the lot. Treating the theme as a small PHP application in its own right, with a proper data layer, clean separation between data and markup, and all the supporting code living inside one coherent structure.

The thing that’s been nagging at me is the plugin dependency problem. Right now, plugins expose functions and features that the theme and other things depend on. Deactivate the wrong one and something breaks somewhere else. The separation is supposed to give you independence but in practice it just gives you coupling without the benefits.

The framing I keep coming back to is the idea of an artifact. A single, deliberate bundle. PHP files on disk don’t feel like that. A fragmented theme-plus-plugins setup doesn’t either. But a theme that is the application - versioned, tested, and deployed as one thing - that does.

It’s just a thought. But the more I sit with it, the more the conventional approach feels like advice written for a different problem than the one I actually have.