Tag Archives: Full Site Editing

Surely you can’t be serious: Does Gutenberg REALLY do this???

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.

Trials and tribulations with WordPress Block Themes and Full Site Editing

Where do I begin? For years I have resisted and rejected everything stemming from the Gutenberg project. I felt it was the wrong direction for WordPress. I felt the WordPress core team doesn’t understand how people who make a living building WordPress sites really use it. I felt they were digging in their heels on the idea of WordPress as a blogging platform, as if that were as relevant today as it was 15 years ago, and that they were in absolute denial over the fact that the most dedicated users of WordPress are actually professional website designers and developers who use it not as a blogging platform, but as a general-purpose CMS.

Of course, my feelings on the matter are utterly irrelevant, because I am not an active member of the core team development community. The people who actually build WordPress are the ones who decide what it is. I am the one who is incorrect, even if I believe the decisions they are making are the wrong ones for the health of the platform.

Then again, I’m a pragmatist, not an idealist. As much as I disliked details about the implementation of Gutenberg, I certainly did not disagree with the idea of a block-based approach to web design. I’ve been calling it “Modular Design” and I’ve been a proponent of it since well before the Gutenberg project existed. And as flawed as I felt Gutenberg’s implementation was, even in its early beta form it was way better than the shit sandwich that is every other “page builder” type plugin. (Elementor, WP Bakery, Divi, Beaver Builder, etc.)

An unsolvable problem is that there is no way for a visual web page design interface to both be simple to use and extremely flexible for all possible design ideas. HTML/CSS offers nearly unlimited possibilities for the appearance of every element on a web page. But taking full advantage of that flexibility still relies on being able to write code.

Every visual tool that exists for web page design must balance design flexibility against interface usability. The more a tool offers flexible design options, the more overwhelmingly complicated the designer interface will be. An interface has to be “opinionated” (in the common parlance) in order to be usable. It has to limit the options presented to the user, and have certain decisions baked in.

Page builders are a disaster in this regard. Without exception they have leaned towards maximum flexibility, resulting in cumbersome, overwhelming interfaces that are often harder to learn than writing code. I have been lamenting for years that so many people are so desperately fearful of learning to code, for fear that they’ll “mess something up,” not realizing that a) the GUI tools they use are harder to understand than code is, and b) they’re even more fragile if you “mess something up.” Unlike with writing code, if you colossally hose up your design in a page builder, you almost certainly can’t just Command-Z your way back to how it was.

Now, where was I?

Ah yes, Gutenberg, the Block Editor, Block Themes and now the emerging Full Site Editing in WordPress 5.9 and beyond. At last, WordPress has a full visual editor for everything!

Uh… no.

For the past several years I have been building WordPress sites using my own custom-built base theme, which has relied extensively on Advanced Custom Fields, and in particular its Flexible Content fields. But some elements of this theme are getting a bit long in the tooth and need to be rewritten (especially the CSS for the header and footer), and I have been wanting to ditch the Flexible Content fields and embrace the Block Editor for page content.

So, why not go all the way and create a brand new Block Theme that fully embraces Full Site Editing? I know it’s technically still in “beta,” but it debuted in the WordPress core in 5.9, so it must be fairly close to “ready for prime time,” right?

Uh… no. (Again.)

It really doesn’t help that you can hardly find any discussion of Full Site Editing that doesn’t breathlessly proclaim its unequivocal greatness. FSE gaslighting is everywhere.

Full Site Editing is an intriguing idea, and there are parts of its interface that look quite nice and appealing. But it is so, so far from being complete that it is a) egregious that they’re calling it “beta” and b) absolutely inexcusable that it is not only rolling out in core, with an “Edit site” link showing up in the admin bar for any site admin to fuck with (and I use that blunt term because it’s the only way I can convey how reckless an addition I think it is at this point), but that it shuts off the Customizer by default unless your theme or plugins specifically enable it.

To say I am feeling let down by FSE is an understatement. But, fine. I don’t need it. Just tell me how I should build my block theme in the meantime, because, you know, I’m actually building sites right now and not just tinkering around while I wait for the core team to finish.

Good luck with that.

I have now been working for the better part of two weeks on building my new theme, and I have been constantly struggling with so, so many aspects of this. It’s not just an evolution of WordPress, it’s really a completely different system that is taking over what used to be WordPress, using entirely different tools. And the documentation I’ve found so far has been scattershot and utterly lacking. (Carolina Nymark’s excellent Full Site Editing website notwithstanding… that’s the only thing that has helped me get this off the ground at all.)

My biggest problem is that the things that I need and feel are important in a theme seem so far removed from the things the core team has focused its attention on. There’s so much seemingly unnecessary convolution in parts of the system that I never even use (author archives? really?), and so little of it aligns with any aspects of how I usually go about designing and building a site.

I found myself falling into a trap of creating a bunch of Advanced Custom Fields option pages, until I finally realized that I was not accomplishing my goal of embracing the Block Theme philosophy, and I was not really getting anywhere. Eventually I realized that some of it is my own bad habits, and I needed to take a step back.

Rather than building a colossal theme with tons of configuration tools (most of which will probably only ever be used by me), I need to use the knowledge I’ve gained over the past several years of working with clients on my existing theme.

Speaking of my existing theme, it consists of five main components, most of which rely heavily on ACF:

  1. Flexible Content fields for block-style page editing
  2. Options pages with site-wide configuration
  3. Special-purpose/reusable content blocks (banners, modal overlays)
  4. Customizer settings
  5. A “tweaks” plugin for site-specific design, functionality, CPTs, etc.

Reinventing my tools in a new block theme, I’m finally recognizing that I need to differentiate the aspects of the theme my clients actually use from the aspects that are really only for me in configuring the site. The clients only really touch #1 and #3 from that list. #2 and #4 are tools I created with an idealized view that clients would be able to customize their own sites, but over time it has become apparent that I’m the only person who ever uses them. And #5 really underscores the fallacies and flaws in this approach: it’s a catch-all of CSS that’s too complex for the Customizer, along with functionality that truly does belong in a plugin, but a lot of it should more properly be in a child theme, except I couldn’t use a child theme because I depend so much on files in the acf-json folder that won’t get loaded if there’s a child theme.

Moving away from ACF as a content editing tool (though I won’t do away with it entirely — it’s great for things like an options page where clients can plug in their phone number, hours of operation, etc., plus I plan to use it to create custom blocks without having to learn React) will eliminate some of the issues that came with building so much of the theme around it.

And, more importantly, recognizing that I was using a lot of ACF for settings that only I ever touch, I realized I do not need to make those settings, like color palettes, fonts, etc., editable in the admin interface. And as it happens, those are exactly the kinds of settings that go into the theme.json file of a block theme.

It’s taken me nearly two weeks of tinkering, following dead end paths, mulling things over, staring into space, waking up in the middle of the night, and moments of nearly jumping out of my skin with stress, to finally realize what maybe should have been obvious: that I just need to create a parent theme with my general configuration, and child themes with each client’s unique colors, fonts, etc., and put all of the stuff that only I ever touch into the code instead of the admin interface.

It can be hard to see the forest for the trees sometimes, and I’ve definitely been struggling against that over these past two weeks. But it doesn’t change the fact that FSE is not ready. What it does do though is answer the question, Who is Full Site Editing for? It is not for me, and probably never will be. But that doesn’t matter for my work, after all.