In WordPress, you can get lots of potential looks and (to some extent) behaviors just by installing a “WordPress Theme” and activating it within the admin panel of your WordPress instance. This site, PeakZebra, for instance, is running the Extra theme, made by ElegantThemes. It’s based on their Divi page-builder franchise, with page builders being a discussion for another day. There are endless WordPress themes, but there are not really static site generator themes–not in the same sense.

I’m running Extra on this site, but I could just as well have run Hestia or TwentyTwenty or GrilledFish as the theme for this site (OK, actually, I made up GrilledFish… But then I looked just to make sure there wasn’t one, and of course there was). There are, at least in theory, some 30,000+ themes (you’ll see much higher estimates, but this number comes from Scepter, which made a noble effort to weed out unmaintained and unused themes).

This is a smart setup. It makes it easy to go from something that has a bunch of “cards” on the front page to something that has more “flowing” dynamics. If you are a dentist and you want a site that “looks like a dentist site” (I have only a vague idea of what that look might be), you are quite certain to find a theme that has calm, serious fonts, a “safe-feeling” color scheme, and so on.

Themes Play By The Rules

This only works because the things that themes can change are (mostly) completely pre-defined. You’d think that’d make all WordPress sites look vaguely the same, but in fact there are lots of things that it’s completely kosher to change, so the range of possible designs is enormous.

In a slightly confusing (but practical) move, WordPress allows themes to use a “functions.php” file, which can contain absolutely whatever functions a theme designer wants to build in. Anything you can do in a plugin, you could at least in theory accomplish by leveraging the functions.php option.

One of the more confusing things to wrap one’s head around in the WordPress ecosystem is that—even as WordPress creator Matt Mullenweg keeps pushing the notion that open-source software is the best way to make software, and even though everything that swims in the WordPress ocean has to honor WordPress’s free software licensing, there’s a huge trade in “premium” themes, for which you’ll chunk out, typically, $50 to $75 for use on one web site.

Premium or not, each WordPress theme consists of a subdirectory in the “themes” folder, a “style.css” file, and a “functions.php” file. Generally, there are also a number of “template files” and a bunch of other optional stuff as well. The TwentyTwentyone theme (which comes as part of the base WordPress install these days) has a directory listing that looks like this:

If you download a theme, all these files come bundled up in a zip file that WordPress expands into a folder with the same name as the theme.

Meanwhile, In the SSG World…

If you’ve used React, particularly in the context of a static site framework like Gatsby for Next.js, you’ve dealt with components that render pages or parts of pages. That’s exactly what’s going on here, just in PHP rather than JavaScript.

It’s different, though, in this respect: You can’t download a new Gatsby theme and just turn it on (Gatsby has a “themes” concept, but it’s more for supporting particularly functionalities—like a blog that uses Contentful as its headless CMS). If you were going to do this with Gatsby, then you’d need to be using a common, agreed-upon manifestation of Gatsby that understands, for starters, that there might be more than one theme installed at this site, that themes are in a specific folder, that the active theme is, say, named in the Gatsby config file, that elements used in page and partial templates are named using conventions that theme designers can rely on and use, and so on.

The setup here would be different in another way: the style components would be incorporated when the site was rebuilt, not at run time. But that doesn’t really change anything.

What this presumes is a general-purpose set of rules for, say, Gatsby sites that are essentially blog sites (to take one obvious example) about what CSS files are in play and how blog listing versus single-entry page scenarios are built.

Particularly given that WordPress provides a model to work from (and one can imagine an improvement or two), this is doable. I even wonder if it could be sorted out in such a way that this sort of theming might work on more than one static site generator framework. This is one thing that I’m looking at as a PeakZebra project and I’ll keep you posted. If you’re laboring in the same fields, please be in touch.