I’m building a pair of new WordPress sites for a client, using a base block theme I created. My plan going in was to create two child themes, one for each site. But after I finished the first site, I realized that the differences between the two were entirely cosmetic, so I thought I would use the new global style variations feature to just create one child theme for both sites to use, letting the sites have their own separate theme.json files via the styles folder in the child theme. (Let’s call them site1.json and site2.json.)
The problem is, I have a few site-specific code customizations beyond what can be handled in the theme.json file. And, more importantly, I want to hardcode which style variation each site uses. No need to muck around with the Site Editor (a.k.a. “Full Site Editing”). I do not want the client to have any access to that feature whatsoever.
So, I figured… OK, I’ll create a constant based on the domain, to tell me which site we’re on. I can use that for all of my “old school” PHP-based site-specific stuff. Now I just need to find the function WordPress uses to tell which style variation the site is configured to use.
Except… uh… I really can’t seem to do that. I googled it. I used the dreadful search tool in the WordPress Developer Reference. I checked a few of the tutorial sites. Nothing.
I even poked around the WordPress source code. Still nothing.
Finally, I rationalized… well, it has to be storing that setting in the database, so I’ll just temporarily turn on the Site Editor, set my style variation, and then search the wp_options table of the database to see where it turned up, and then maybe I can reverse engineer from that.
Nope.
There’s nothing in the wp_options table.
Oh no, I thought. They aren’t putting this into the wp_posts table, are they?
Yes, and no.
Yes they are, but no, it’s not what I thought. It’s much, much worse. They’re copying the entire contents of the style variation’s JSON file into the table.
Ugh. I mean, I kind of get why they’re doing that… because you can make additional customizations directly in the Site Editor, and that “post” (eye roll emoji — yes I have the stupid built-in WordPress emoji functionality disabled via my No Nonsense plugin) is where those changes get stored. But, uh, wouldn’t it also make sense to store the name of the base style variation itself, in case the user wants to reset it? Maybe they do — somewhere — but I’m once again too demoralized by the seeming absurdity of this whole enterprise to try to track it down.
The big problem is, this means I can’t just hardcode a way for the two sites to load a style variation’s JSON instead of the base theme.json file. And since that file is &#%^!#ing JSON instead of PHP, I can’t put conditional logic directly in it.
I’m leaving this post here, with the situation unresolved at the moment, but my next avenue will be to see if I can find a place where I can shunt WordPress over to using my variation JSON files.
Yes, I am Doing It Wrong™. But if you ask me, the entire thing is doing it wrong.
And don’t call me Shirley.
Update: OK, like, ten seconds after I published this, I decided that the correct course of action is simply to, alas, scrap my idea of using global style variations, and go back to building two separate child themes, even though it will mean a lot of redundancy. Global style variations are a good idea, but they’re just not implemented in a way that is practical for me to use. (Which makes me wonder if the way they’re implemented is really practical for anyone to use, but once again I am clearly not the core team’s target audience.) Thank goodness I hadn’t yet emptied the trash on my Mac.