WordPress development in the Gutenberg era: Threading the needle of Block Theme development

As described in several of my recent posts here, I have been working for the past month or so on building my first “all-in” Block Theme for WordPress.

After nearly 4 years of adamantly resisting “Gutenberg” and the new Block Editor revolution — not because I disliked the block concept, but because I disagreed philosophically with the core team’s approach (to what constitutes a block, which types of blocks are important, and which technologies are used to manage the UI of the editing screen) — I am finally accepting that if I am to continue making a living primarily as a WordPress developer, I need to give up on my Classic Editor, Advanced Custom Fields “Flexible Content” approach, and embrace that the Block Editor is now The Way.

One of numerous challenges I’ve faced in this process (on top of the learning curve of a completely unfamiliar method of constructing themes, the dearth of adequate and up-to-date documentation, and the core team’s willingness to allow very unfinished versions of functionality to roll out in public WordPress releases) is figuring out the best way to approach some of the more complex design structures I am used to dealing with via ACF’s Flexible Content fields.

My biggest hurdle is recognizing that what I think of as a “block” is not what the WordPress core team thinks of as a “block”

Here I will admit this is a shortcoming of my own approach. I have been “opinionated” in my development approach (well, about everything, really), and created large-scale and complex “blocks” that, in Gutenberg/Block Editor terms, would really be “groups” or “block patterns,” not blocks. Gutenberg blocks are more granular.

Gutenberg blocks are also static, in that they generally do not interact with database content, or if they do, it is in very limited “bloggy” ways that don’t align with my use of WordPress as a general-purpose CMS.

So I’ve found myself falling back on ACF. I like its server-side approach. I’m more accustomed to dealing with PHP and MySQL. I use JavaScript (mainly jQuery) a fair bit for front-end interactive elements, but I don’t build complex functionality in JavaScript and I avoid AJAX if I can help it.

You can see I’m destined for a strained relationship with the Block Editor.

A concrete example: “Tiles”

One of the most idiosyncratic elements of my old ACF approach is the block I call “Tiles.” It’s a way of creating a set of small blurbs to link to other pages/posts. There are numerous options for appearance: number of tiles per row, relationship between the image and text in a tile, etc. And there are also numerous options for the content source: a specific page or post (with the title, featured image and excerpt automatically pulled in), a dynamic feed from the blog or a specific category (likewise with the info pulled in automatically, except this one auto-updates when there’s a new post), or a completely custom-built tile, where you manually select the image and enter the text and link.

Here are screenshots of the ACF-based editing tools for my Tiles block.

I tried recreating this entire setup as a new ACF-based Block field group. It worked, to be sure, but the complex ACF editing layout really did not feel right in the new Block Editor interface, either in the sidebar (eek) or in the main content area. It felt like a cop-out.

Then I considered creating a block pattern. I knew this would lack some of the benefits of my ACF-based Tiles block, but one in particular: the option to dynamically pull in the details of another page/post, rather than manually entering the text. But as a starting point, I decided to recreate the “custom” tile type.

That, also, worked. But it was finicky and didn’t apply well in a lot of different places. So I realized that instead of creating a Tiles block pattern, I needed to create a Tile block pattern. Just one tile. Instead of a monolithic block that was really a group, users would insert each individual tile into whatever larger structure they want (e.g. columns).

The end result was a block pattern that looked like this (screenshot instead of live code because, well, you really don’t want to use this):

I was really proud of myself for using the new “lock” feature to force the elements to stay in a particular order, but to allow the user to remove elements they don’t need, such as the image, lead-in text, or CTA button.

Still… I didn’t like it. And it didn’t allow for dynamic sources.

Along the way I also finally came to grasp another fundamental limitation of the Block Editor and Block Patterns. Since all of the parameters of the blocks are stored as HTML comments right in the post content, you (the theme developer) can’t update the design of a block pattern once it’s inserted into a page/post. The Block Editor isn’t dynamically inserting content into a template when the page is rendered. It’s making a one-off copy of the template and storing it right along with the content at the point when the content is inserted into the page/post.

This seems, to me, to be a fundamental flaw in the entire Gutenberg/Block Editor approach. It’s bad enough that if I were building it myself, I’d have stopped right there and taken a completely different direction. Maybe there’s a long-term plan to address this limitation, but for now it appears to be here to stay. Which led me back to ACF.

Threading the needle

And that was when I had my insight into the true nature of the problem. It was the fact that what I think of as a “block” is larger-scale than what the Block Editor treats as a block.

So I went back to my Tiles ACF field group, stripped out the repeater functionality and created a Tile ACF field group. Now you’re building one tile at a time, it has all of the previous benefits of ACF’s dynamic integration of content with template functionality, it seems to correctly fit the definition of a “block” in the WordPress sense, and you can still have a flexible presentation of multiple tiles in a group… just using Block Editor “groups” to achieve that.

I still have more to learn and questions to answer (followed by more questions to ask and then answer), but I feel like this was a major step forward in finding a way to merge the benefits of ACF with the… inevitability, I guess, of the Block Editor.

Getting out of my comfort zone… on bass and in the world

After two years of mostly not performing (or even interacting) with other people, suddenly I find myself thrust deeply into both.

I’m currently rehearsing on bass with the Minneapolis South High Community Jazz Band for a concert in the park on June 3, and I’ll also be playing bass in the pit orchestra (which is neither an orchestra, nor will it be in the “pit” for this show, but on stage!) for Summerset Theatre‘s production of the Queen jukebox musical We Will Rock You in Austin, Minnesota at the end of June.

Going into this, I figured the jarring proximity of other people in the post- (or, ongoing-) covid era would be the hardest thing for me to handle about the experience, but sight-reading sheet music for bass is reminding me of a much more enduring challenge.

I formally studied clarinet from 5th grade through my senior year of college, and I played saxophone in school jazz bands throughout high school and college as well. I was a music major, to boot. But I am entirely self-taught on bass (including reading bass clef), having mostly just played it in rock bands since first picking it up as a sophomore in high school so I could emulate Geddy Lee and Chris Squire.

I would label my bass skills as “intermediate” in general, maybe “intermediate-plus” if I’m feeling generous to myself. But I have three major weaknesses: occasional struggles to coordinate my left and right hands, less-than-instant recognition of notes above the staff in bass clef, and most significantly, a fear of the 6th to 11th frets.

It’s amazing how far you can get playing rock music and rarely venturing above the 5th fret (or outside of the 12th to 17th frets, which are easy to mentally map to the first 5). I have an immediate, instinctive recognition of where the notes on a piece of sheet music in bass clef are on the bass neck, if I’m thinking about the first 5 frets.

The problem is, jazz and musical theater expect a bit more out of a bassist. The past few years of playing in the jazz band (and having played in the pit for Summerset’s production of The Little Mermaid in 2019), along with numerous gigs as a part of 32nd Street Jazz, have forced me to finally learn the middle of the neck. But I still don’t have that immediate instinctive recognition of where the notes are.

And the weird thing about guitar and bass, compared to woodwinds, is that there are multiple places to play just about every note. So when you’re playing, say, a second line B-flat, you need to consider, “Am I going to play this on the 1st fret of the A string, or the 6th fret of the E string?” That consideration depends a lot on what comes next. If the line suddenly soars up to, say, a D above the staff, you really need to be on that 6th fret.

So far so good. If there are just a few sporadic notes, or a repetitive pattern, that sits best in the middle of the neck, I can get that down. But when there’s a fast run with a bunch of accidentals, I’m still just not tracking fast enough to pull it off. Until I have a part down cold, I often find myself in rehearsal panicking in the middle of a measure and quickly dropping back to the first 5 frets, where I immediately know a top-line A-flat is the 1st fret on the G string, for instance. Never mind the fact that in 2 beats I’m going to need to be up at the 9th fret. Eek!

It’s easy to get stuck for a long time as an “intermediate” bassist, especially if you’re in your 40s and not making a living as a musician, because there’s a big bump in the learning curve to get to that advanced level.

But maybe I’m just being too hard on myself. After all, other people are letting me play bass in these situations, so I must be doing it adequately. Right?

As always…

jwz:

As always, please note:

  • These are two extremely specific questions.
  • Your guesses are not helpful.
  • Your opinion that I should not want this, likewise.

Words to live by.

New synthwave-y album: Cyan & Magenta

I’m not sure why I’ve gotten out of the habit of promoting my new music here on the blog, but anyway… in addition to a bunch of crazy videos I’ve been posting on YouTube since the pandemic started, I also just finished up this new synthwave-y album called Cyan & Magenta, out now on Bandcamp!

Why does my iPad display constantly freeze when using Sidecar with my MacBook Pro?

I’m still asking this question and not finding any answers.

Someone said to disable Touch ID on the iPad. That didn’t help.

Someone said to be sure you’re using a USB connection, not a wireless connection. That didn’t help either.

Here’s my current theory, which I am still testing, and I’ll update this if I get anywhere closer to confirming it.

I think it may be because I was supplementing my WiFi Internet connection with a wired Ethernet connection, via an Ethernet-to-USB-C adapter. Most of the time when I’m sitting at my desk — which is also almost the only time I’m ever using Sidecar — I have the Ethernet plugged in. I have “gigabit” (in theory) fiber Internet, so the wired connection makes the difference between averaging about 150 Mbps over WiFi alone vs. about 600 Mbps over WiFi + Ethernet.

I’m not exactly sure how the Mac handles having both WiFi and Ethernet connected simultaneously… I’m from the old school where you had one or the other. But it seems to work. However, I think it may also be contributing to Sidecar crapping out randomly and often (usually it won’t work for more than about 5-10 minutes before the iPad screen freezes).

So far in about a half hour of testing deliberately having the Ethernet unplugged and paying attention to it, Sidecar has managed not to stop working, but it’s too soon yet to know for sure if this is the fix.

I’d rather keep my fast Ethernet connection, of course, but my WiFi connection is plenty fast for everything besides massive file transfers, which I don’t really do that often. So if this is the tradeoff I need to make in order to keep Sidecar working, I’ll do it.


Update (June 7, 2022): Nope, this seems to be a moving target. The solution I outlined above worked for a while, but now, still running the latest OS updates (macOS 12.4 and iPadOS 15.5 respectively), I am still once again seeing Sidecar freeze every 5-10 minutes, even though I am doing everything I can possibly think of to fix the issue: the devices are connected over USB, I have Touch ID disabled, auto-lock is set to “never,” my Mac is unplugged from Ethernet. None of it matters… Sidecar just keeps freezing. I don’t understand why Apple can’t seem to fix (or even acknowledge) this problem.