The final (?) verdict: Gutenberg (a.k.a. the WordPress “Block Editor”) is fundamentally flawed and unsustainable

I’ve been trying. Really I have.

From its initial release as part of the WordPress core in version 5.0 in late 2018, up until early 2022, I adamantly refused to use Gutenberg. I felt its conceptual flaws and practical limitations were so profound and so obvious that I really could not believe this was going to be “the future of WordPress.” And now here we are.

In the spring of 2022 I finally relented, as at least the initial impression of the user interface had improved to a point where I felt I just needed to embrace it or move on. And so I created a new base “Block Theme” for future WordPress projects, and began building new client sites with it.

The past year and a half of dealing with Gutenberg more directly has been a painful rollercoaster of emotions, as I’ve tried repeated to convince myself it’s good, only to have it, once again, prove itself a hot mess of ill-conceived and barely-documented hacks.

Many times in the past 18 or so months I have contemplated abandoning WordPress for good, checking out ClassicPress and some other CMS options before falling back on giving Gutenberg another chance.

I’ve even considered writing my own Content Management System (CMS) [again; it’s something I specialized in before 2014]; switching to Drupal, for God’s sake (until I read that they’re porting Gutenberg for Drupal too… why why why?!); scrapping CMSes altogether in favor of just building sites with Bootstrap (and giving clients some rudimentary editing tools for the very few elements of their sites most of them actually modify post-launch); and even quitting the field entirely.

Frankly I don’t have the time or energy to make an extensive, coherent case for why Gutenberg is so fundamentally flawed; suffice to say it’s a combination of four main issues:

  1. frustrations over its excessive reliance on React (the Flash of the 2020s) for so much of its functionality,
  2. irritation at its embrace of the “make the interface seem simple by just hiding everything until the user hovers over the right magic spot” approach to UI/UX design,
  3. trying to get a handle on how the damn thing works, due to its combination of woefully inadequate and outdated documentation, and the fact that it is constantly changing, in ways that break my code (which was written based on earlier assumptions about how things worked, because that was all I had to go on), and
  4. its absolute, unforgivable abandonment of the core web design principle of separation of content and presentation.

The last one is really the killer, and it is only getting worse, because not only does the code — that fragile, convoluted, redundant code, stored in the database — become increasingly unmanageable the more you build your site, but WordPress is constantly pushing more of its structure into this disastrous framework (if you can call it a framework). The Site Editor is a true abomination that can’t possibly be useful to anyone… except possibly “no code” website builders. But honestly, if you can’t write code, you should just be using Squarespace instead of WordPress. You’ll be much happier, and so will your clients.

All of these issues probably stem from one even more basic to the whole discussion though: the creators of WordPress (especially imperious leader Matt Mullenweg) do not consider WordPress to be for what most of us “WordPress professionals” actually use it for. To them, it is blogging software. Period. But very few people who make a living in the WordPress ecosystem are using it to build blogs. Instead we are using it as a general-purpose CMS.

Gutenberg is adequate for a basic blog — in fact, I’m using it for this one, and I do prefer editing my posts in Gutenberg vs. Classic Editor. Its severe flaws and limitations don’t become readily apparent in the “basic blog” context.

There’s an argument to be made that Gutenberg really exists for WordPress.com to compete with the likes of Medium and Substack, and the industry of us web professionals who use the open source version are of no consequence to Matt’s vision for the platform.

Anyway, I have managed to launch about ten new client sites in the past year-plus using WordPress with Gutenberg, and every time I have had to face frustration and embarrassment as I acknowledge with clients the limitations of the tool, or sympathize with their frustrations in dealing with it as users.

My current project may be the last straw though. I’m two days away from launching the biggest site, by far, that I’ve built with Gutenberg. It’s over a year in the making, and now at the eleventh hour I am confronting the possibility of having to manually edit a huge number of posts in a CPT I created — and naively used the Block Editor to manage instead of just some ACF fields — because the client wants to change the default text sizes.

It’s possible this situation could be remedied by the merger of Block Patterns and Reusable Blocks that happened in WordPress 6.3, but guess what… we had already created all of this before that functionality was an option. I still haven’t had time to even figure out exactly what the implications of these 6.3 changes are, because I’ve been too busy just trying to build the site.

That’s where WordPress is really dying for me as a viable platform to work on. It’s supposed to be the foundation for what I do, but now the ground is constantly shifting beneath my feet. Gutenberg is making web development much harder and more frustrating, projects are taking longer, and it’s making me look incompetent and unprofessional to my clients. I’ve been a professional web developer since 1996; I’ve been using WordPress for projects since 2008, and almost exclusively since 2014. But now I don’t trust it anymore.

I’m in a position where I may (fingers crossed) be able to back off taking on any new freelance projects for the remainder of the year, once this site has launched. I am really hoping that’s the case, because it’s time for me to make a serious re-evaluation of whether or not I want to build any more WordPress sites in the future, and if not, I need to take that time to learn — or build — a new platform.

The great irony, of course, is that my business has increasingly been made up of selling and supporting my commercial WordPress plugin, ICS Calendar Pro. Fortunately, my work on that plugin has very little to do with, nor is significantly impacted by, the Gutenberg/Block Editor project, although that may change as WordPress continues to (d)evolve.

(Don’t even get me started on how bad Gutenberg is for responsive design.)

Stupid jQuery and CSS tricks: Move a hidden element to the end of the parent

I just came up with a solution so simple, yet so stupid, that I had to share it.

The scenario is this: my client has some third-party JavaScript to inject a form into a page. I’ve been writing some of my own CSS to style the forms, including some crafty use of :nth-of-type(2n) and :nth-of-type(2n-1) to apply styles conditionally to adjacent fields in a two-up layout. (These are just sequential <div> tags, and I have to work with what I’ve got.) Specifically, I’m adding some right margin on the “left” element, and no right margin on the “right” element.

I noticed an instance where my margins were flipped for two fields, and when inspecting the code, I discovered why: the client has set up their form with a hidden field tucked in there before the “left” element. That’s throwing off the value for 2n in my CSS. I was going to contact them and ask them to update their form to put the hidden element at the end, but I realized this is a problem that is likely to recur, so I should just write in a workaround. (Yeah, yeah. But it’s the lesser of two evils.)

Fortunately, the site is already using jQuery, so a fix was super simple. I’m leaving the CSS class names here as they are in the actual site, but you may need to change them to suit your particular form.

jQuery('.form_container .form_page .form_question.hidden').each(function() {
    jQuery(this).appendTo(jQuery(this).parent());
});

Since the hidden field has the .hidden CSS class, it’s really easy to use the jQuery .appendTo() method to just take all of the hidden fields and shove them to the end of the container element. I used the parent and ancestor CSS classes in my jQuery selector just to be sure I’m isolating this action to these particular forms. Then of course I have to tell the page when to execute this functionality, which is ideally on the load event:

jQuery(window).on('load', function() { /* Code goes here */ });

It works!

Using your Mac with your iPhone hotspot? Be sure to turn on low data mode!

In the summer, I like to take my MacBook Pro with me and work outdoors. Doing that is entirely dependent upon my T-Mobile hotspot on my iPhone. I had my account maxed out at 16 GB of hotspot data per month, so imagine my surprise today when — one day into a new cycle — I got a notification text that my data had been used up!

I’m still not sure what exactly my Mac was doing, presumably some kind of background iCloud Drive backup, but I managed to use up an entire month’s allotment of bandwidth in extremely short order. I worked with T-Mobile support to get my account bumped up to the absolute maximum 20 GB, but there’s no certain explanation of what it was that used all of that data.

But along the way I discovered the Mac does let you configure “low data mode” specific to each network you connect to. If you find yourself needing to use a hotspot regularly, I would strongly recommend turning on low data mode for that network. To do that with the new Ventura System Settings app, go to WiFi, then under Known Networks click the icon for your hotspot, and chose Network Settings…

Now here’s where it gets interesting. I turned on the Low data mode toggle about five times and it kept, after a couple of seconds, shutting itself back off. Finally it “stuck.” Now we’ll see over the coming days if it actually makes a difference!

On the Supreme Court, the First Amendment, websites and wedding cakes

From the perspective of someone who supports LGBTQ+ rights, I am not exactly a fan of this recent SCOTUS decision. Simultaneously, as a web designer/developer, I think it is extremely important to recognize the difference between this type of work and a more commodity-oriented business.

Web design and development is creative work, requiring a personal input of time and energy, thought and consideration. It’s not a public storefront, selling premade goods. It’s not even a construction or contractor type job, where you may have disagreements with the client’s worldview, but the work itself is (generally) philosophically and politically neutral.

As a web designer/developer, I absolutely choose which types of projects I do or don’t want to work on, and I insist on maintaining the right to refuse to take on a project whose mission or purpose does not align with my values.

To put a finer point on it: I think it’s worth distinguishing between a web designer who is actively collaborating with their client to build something custom for them, vs. a DIY-type system where the client is provided with tools to build a site for themselves. In other words, for the type of work I do in client services, I should have the right to refuse to participate in a project whose purpose I disagree with. But if I were, for instance, Squarespace, selling access to a service I built, which lets users create their own sites, then I should not have the right to decide who can or can’t use the service. (As long as what they’re doing with it is legal.)

I can get even more specific to my own situation here. In addition to my client services, I also sell a product: a WordPress plugin for integrating calendars (e.g. Google Calendar, Office 365, etc.) into your website. I do not, and I strongly believe should not, decide which types of sites are allowed to use my plugin. I know there are customers of the plugin whose businesses/organizations do things I do not particularly agree with. But there I am selling a finished product — a commodity. Anyone who wants to buy it (again, as long as they’re not doing something illegal — although I won’t even know that, unless I specifically take the time to investigate them, post-sale) is welcome to do so. But if those same people approached me in my client services role to help them build their website itself, I would/should have the right to turn down the project if I didn’t want to do it.

Of course, there’s another layer to this: Why did this even become a court case? As I understand it, the designer here is the plaintiff, and doesn’t actually run a wedding website business yet. She is clearly doing this to make a political statement. I’m not sure how much the Colorado law was really pushed on her, or if it even technically applies to her (hypothetical) business. For me, and I think a lot of other people in my shoes, it’s a simple enough practical matter to turn down projects you don’t want to work on — regardless of why you don’t want to work on them. As a creative worker, you are essentially selling your time, not a commodity, and you have a limited supply. It’s a simple matter of being “too busy” to take on the project. There may be laws saying a business can’t discriminate, but surely there cannot be any laws that say a business has to work more hours than humanly possible.

So, what’s the upshot here? Well, it kind of seems like this case isn’t really about the First Amendment rights of business owners like me at all, because I’m skeptical that those were ever really under any threat. But it definitely opens the floodgates for business of all types — including those that truly are “open to the public” and selling commodity goods — to discriminate against potential LGBTQ+ customers. And that’s why I’m opposed to the current SCOTUS super-majority: their aggressive efforts at rolling back civil rights. That’s what this case is really about.

How to restart an iPhone without using the touch screen

Well, that was weird.

I suddenly found that my iPhone 13 mini’s touch screen was only partially responding. In particular, the upper left quadrant seemed entirely unresponsive to touch. Well, time to restart!

Except.

The only restart process I know is to hold down the Volume Up and Power buttons until the emergency call screen appears, then swipe the “Swipe to power off”… uh… swiper… thing.

No good! That was in the “dead zone” so swiping it did nothing.

Fortunately, Apple has another way. It’s pretty simple and it worked perfectly for me:

  1. Quickly press and release the Volume Up button.
  2. Quickly press and release the Volume Down button.
  3. Hold down the Power button until the iPhone shuts off.
  4. Hold down the Power button again until you see the Apple logo.

Maybe 3 and 4 can be the same motion. I just let go of the button when I could see the iPhone had shut itself off, then after a few seconds, I pressed it again to power on as usual. And I’m pleased to say, the screen seems to be working fine now.