Tag Archives: WordPress

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.

A slow-motion apocalypse

I could be talking about any number of current events with a title like that, but in this case I’m referring to last September’s “SSL Apocalypse” that came due to the expiration of an X3 root certificate used by Let’s Encrypt when connecting to really old client OSes. (Not that users think their computers/devices are really old, but in Internet terms, they are.)

Now, over six months later, I am still sporadically dealing with this issue. I was responding this morning to a client about the issue, and I wanted to email her a link to the blog post I remembered writing on the day it happened. But, maddeningly, I could not find it anywhere here.

That’s when I remembered, I actually have two blogs.

So, in a simultaneous act of self-promotion and, uh, self-reminding, here’s a link to that post on my other blog, on the site for my WordPress plugin ICS Calendar:

Unexpected Side Effects of the Let’s Encrypt Apocalypse

There we go. Now you know about ICS Calendar, and I won’t think I’m losing my mind when I come back here in another six months and can’t figure out where the heck this blog post went!

How to make the WooCommerce main shop page show featured products only in 2022

Sorry for the click-bait-y title (especially the “in 2022” part), but I searched fruitlessly for way too long and found too many woefully outdated answers to this. Ultimately what I found still wasn’t quite the complete answer, so I modified it a bit myself to arrive at the following.

The goal here is, as the title suggests, to get the WooCommerce main shop page to only show your featured products. Why this isn’t just a checkbox option in WooCommerce is beyond me. But then a lot of the decisions made by the WooCommerce dev team are beyond me. (Excuse me, Professor Brainiac, but I’ve built e-commerce platforms from scratch and, uh, I think I know how a proton accelerator… oh wait, never mind.)

Anyway, this is it:

add_action('woocommerce_product_query', function($query) {
    if (is_shop()) {
        $query->set('tax_query', array(array(
            'taxonomy' => 'product_visibility',
            'field' => 'name',
            'terms' => 'featured',
            'operator' => 'IN',
        )));
    }
});

What exactly is happening here? Well, as noted by the most helpful resource I found, since WooCommerce 3 (currently on 6.1.1), the “featured” status has been handled by the product_visibility taxonomy, and not by the _featured post meta field. So this needs a tax_query and not a meta_query.

Beyond that, we’re making an extra check that we’re on the shop main page — so this doesn’t affect category archive pages. And we’re using the woocommerce_product_query hook, not pre_get_posts as some other examples suggest, so it only runs on WooCommerce queries and we can skip adding extra conditionals for pre_get_posts to run on, you know, every single post query on every page of the site, including admin.

That’s all there is to it. Now your main WooCommerce shop page will only display featured products, and nothing else changes.

Please think twice before leaving a flippant negative review

Last week I launched a new WordPress plugin, No Nonsense, and much to my surprise, it started to pick up steam after just a couple of days. It turns out, it got featured with a nice review on WP Tavern, and people took notice.

Unfortunately, almost immediately, it got a couple of really negative reviews, both of which were clearly dashed off with very little thought, or apparently even the slightest bit of effort on the part of the reviewers to try to determine the cause of their issues before leaving a negative review — rather than submitting a support ticket, which would be the correct channel for addressing a problem… if they actually wanted to solve it.

I take pride in the quality of my work, and I try hard to make sure it performs flawlessly. I respond quickly to any issues — even for a free plugin like this — because I want to make things right. So it is really painful to have the product of my efforts permanently stained with a negative review by someone who can’t be bothered to take the time to write a single cohesive sentence detailing the issues they had with it.

I understand the temptation to rip on something you think is garbage, and I’ve left a few one-star plugin reviews myself. But I feel it’s important to at least explain in detailed and objective terms why I think something is bad. And maybe if it’s clearly something brand new, I’d wait a while to see if the creators take the time to work out the kinks first.

So, no matter what you do, no matter where you are, if you are in a position to criticize someone else’s work, I implore you to take a second and think about the impact you might be having on that person and on what they’re trying to accomplish, and whether or not your criticism is truly valid and warranted. Perhaps it is not, in which case, I would respectfully suggest you stay quiet. But maybe it is. In that case, think about whether a terse and flippant negative review is really the best way you can contribute to improving the situation, or if there’s a more effective, more constructive way to share your input.

New WordPress plugin: Remove Broken Images

If you have a WordPress blog dating back many, many years, and you’ve just completed a massive cleanup of images from your Media Library, or if you just have any other reason why there might be a bunch of <img> tags in your blog posts that no longer go anywhere, you may be wondering if there’s an easy way to just, you know, have those annoying broken image icons not show up all over your pages.

Now there’s a way!

OK, actually there already were a few different ways, via free plugins, but as is so often the case with a lot of these types of small, single-purpose plugins, I find they’re almost always either really clumsily written, overloaded with unnecessary features, or both.

So I wrote my own.

This plugin couldn’t be simpler. It assumes that you just don’t want to display broken images — whether that’s the ugly little “missing image” icon some browsers display, the large outlined box containing an ugly little icon and the missing image’s “alt” text, or just a big blank white space. It doesn’t have an option for showing a different, placeholder image. Because, let’s be honest, that doesn’t look good… especially if you have more than a few of these to deal with. Having the same placeholder appear all over your site looks as bad as having broken image icons everywhere.

The plugin relies on the JavaScript error event, and uses some very compact jQuery code to remove any <img> tags that trigger the error, and their containing link and caption element, if present.

The end result is a clean looking blog with no indications whatsoever that anything is missing. Unless the text of your blog post describes the image in excruciating detail. In that case… you’ll just have to wait for version 2.

You can download Remove Broken Images right now from the WordPress Plugin Directory.