As development on my Wyvern theme framework for WordPress continued, I found myself at a crossroads. The goal of the project was simple: create a reusable jumping-off point for future Impossibly Creative projects. Where I was stuck was deciding how those projects would be maintained in the long run. Since I also do maintenance for my clients, I knew I had to make this decision sooner than later. Ultimately, I went with building a parent-child framework instead of using a base scaffold. This is why.
Two Roads Diverged
Two roads presented themselves, and I couldn’t travel both unless I wanted to drive myself crazy. I could follow the _s path and have every project start from a similar base, but ultimately conform to the client’s needs or I could follow what I call the Genesis path where a child theme would inherit most of the functionality of a shared base. Each has its merits, and there wasn’t really a wrong choice. What I had to do was find the right choice for me.
The _s Path
The idea behind the _s path is that you develop a barebones base theme and copy it every time you start a new project. From there, custom functionality is built and you move on to the next project. Maybe some of the new stuff gets dropped back into the base, maybe it doesn’t. It all depends on what gets built. In the end, while each project contains the same DNA, they are their own entities.
The issue I saw was I’d end up maintaining an increasingly diverse codebase. Diversity in tech is important, but not in this instance. The speed at which I could familiarize myself with a codebase I wrote 3 months ago could be reduced dramatically if I could limit the variations as much as possible.
The Genesis Path
The strength of the Genesis path is a shared codebase. Every new project starts the same. The bones are the same. The muscles are the same, the overall structure doesn’t change. Customizations get constrained to individual projects, but every project benefits from updates to the base.
With Gutenberg increasingly becoming the standard for all things WordPress, having a repeatable structure seemed vital. As new standard blocks are introduced, clients could get updates without having to deal without having to worry about overwriting any customizations they may have made themselves (or had someone else make). Their site wouldn’t break just because something new came along.
For years, I built off of Genesis exclusively. As a WordPress developer, it is ingrained into my thinking. The more I thought about it, the Genesis path seemed the natural choice to me.
I’m building my first client project with it now, along with this site. Ironically, this site does not currently use the parent/child version of Wyvern because, frankly, I’ve been busy. I’ll be changing it over in a few days. Edge of the Galaxy is receiving an update too, eventually.
The trick now is setting up an update system. For all current and future projects to benefit from the shared codebase concept, they need to be connected to a base repository. When the repo gets updated, the shared projects need a way to receive those updates. Because I’m not (currently, at least) planning on releasing Wyvern’s base to the WordPress theme repository, I need to set up the infrastructure for those updates.
I have no idea how to do that. Yet. That’s part of the learning process, I guess. As I continue to develop this framework, I’ll continue to update the progress here. In the meantime, the theme will be public on GitHub. I’ve also created a starter child theme to make getting using the framework easier.
As I get closer to a full 1.0 release, I’ll create some kind of package system that lets you install both at the same time. I’m not there yet, but give it time. I’m also working on a plugin framework and will be talking about that in this space here soon.