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.

One document that encapsulates the Block Editor core team’s detachment from the reality of how most professionals actually use WordPress

That would be this document.

Establish early what content you expect to require updates

At a high level, it’s important to recognize that not every piece of content can be updated across the entire site and that the method of creation greatly impacts what’s possible. As a result, it’s critical to spend time ahead of creation determining what you expect to need updates and to put that content in the appropriate format. This will make a huge difference in terms of future maintenance.

Embrace theme design at the block level

Block theme design requires a mindset shift from the previous approach of designing large sections of a theme and controlling them via updates. While a holistic view of a design is still important when creating a custom theme project, blocks require that themers approach design on a more atomic level. This means starting from the block itself, typically through theme.json customizations. The goal is that each individual “atom” (i.e., block) can be moved around, edited, deleted, and put back together without the entire design falling apart.

The more that you approach design at the block level, the less need there is to propagate updates to things like patterns and templates across the entire site. If the atomic pieces are in place, their layout should not matter.

Gee that’s rich. My particular issue right now is that I need to make some updates to a block pattern I created for my client’s site. Unfortunately, that block pattern was already in use on about 40 pages of their site, but it involves an unanticipated design issue. (As it happens, yes I probably should have thought it through a bit more before it got propagated so extensively, but the practical reality of building websites is that sometimes you don’t know what will or will not be effective at the outset — especially when you’re simultaneously dealing with end users learning how to wrangle Gutenberg — and one of the great features of the web from its inception to today is that things are easy to change later on. In fact, that has been a driving force behind template-oriented CMS platforms from the beginning. It’s the separation of functionality, design and content that has been at the heart of most well-structured website editing platforms, including WordPress, until now.

It’s easy, when you believe that what you are creating is a blogging platform, that people only use it to create blog posts that are content-heavy with mostly one-off layouts. And yes, that’s how WordPress started. But the entire team must collectively have its heads deeply inserted up Matt Mullenweg’s ass (sorry for being crass, but I’m also being honest) if they think that’s how WordPress is predominantly used, if that’s what made WordPress as big as it is. Because it’s not.

I’ve been doing “block-based” design with WordPress sites (using Advanced Custom Fields and its wonderful Flexible Content field) since well before the Gutenberg project existed. But I had a much different, less “atomic” concept of blocks. This atomic approach is great (I guess) in concept, but it is too fine-grained to be a useful tool for the average web content editor, and it makes design and development orders of magnitude more difficult and time-consuming.

I have now completed four site projects using my own custom block-based theme, and have three more underway. While there are some really “cool” features of the Block Editor (Gutenberg), these projects have also taken me much longer and been far more maddening to build, and have left my clients much less confident in their ability to easily edit their content, than anything I had done in the previous decade of working primarily with WordPress.

And this last set of three projects is in many ways a rolling back of features, because after too many months of frustration with the limitations of block themes, “version 3” of my custom theme actually reverts from using the new HTML-based page templates to using PHP-based templates. It’s a regression in a way, but I never had any intention of using the Site Editor anyway, because it’s not an easier way for me to build sites, and it grants access to elements that should be 100% hands off for the clients who’ve hired me.

And now, once again, I’ve been derailed from my work by the need to spend 45 minutes venting my frustrations over this predicament in a blog post.

By the way, I'm aware of the irony of using Gutenberg in order to decry it, so don't bother pointing that out.


So… how did I end up resolving the issue of updating the block patterns that already appear in my content? Do you really want to know? I fired up phpMyAdmin, wrote a SQL query to find all of the affected instances, and manually copy-pasted the update into them. (Yes, I could’ve written a SQL statement that would just do the replacements; I tried that first, but the replacement text was really long and was generating a MySQL error that I couldn’t quickly pin down, so it was faster to just manually edit the 40 records.)

Jesus wept.

Today’s Apple press release.

(Full disclosure: I am an Apple shareholder. I’m glad their stock is up. But I think this is stupid.)

Update (the next morning): I just have to specifically call out this shot from the promotional materials. Seriously. Think carefully about what we’re seeing here. The woman wearing the “Vision Pro” is interacting with other people over FaceTime. None of them are wearing a big contraption on their faces. And they’re definitely real video, not avatars. She cannot possibly look to them the way they look to her. And, critically, they are definitely not using the product being promoted here.

Combine this bizarre demo with a very far-out launch date (I may be wrong, but I think this is the first time Apple has ever announced a product with a “next year” launch), and the whole thing reeks of the kind of vaporware desperation Apple’s competitors are frequently guilty of but Apple itself almost never succumbs to. “Real artists ship” is the phrase Apple has lived by. I’m not sure they believe it anymore.

Update to the update (that afternoon): So, Brian X. Chen of the New York Times got to try the unit, and it sounds like maybe these actually are digital avatars — or at least the woman wearing the ski googles Vision Pro here would be represented that way to the others. Still. Reading the rest of his first impressions, I am just affirmed in my extreme skepticism of this product. Maybe it’s time to cash out my Apple stock before it’s too late.

Update³ (even later that day): One last thing I want to talk about, since I’m mentioning Apple’s stock so much. Yesterday morning, just prior to the announcement, Apple’s stock was at an all-time high. Immediately as the keynote was beginning (1 PM EDT), the stock began to drop. It’s still very high as of the moment when I took this screenshot, but it’s lost about $5 per share from yesterday’s moments-before-the-keynote peak. Hmm.

Chick Corea on the 8’s

After 30+ years, I’m trying to give this album another chance. (It’s not on Apple Music so I had to find it on YouTube.) I bought this album in high school after I joined jazz band and wanted to learn more about the genre. But I really did NOT like it, so I sold the CD, and haven’t heard it since.

I remember liking Chick Corea’s playing and John Patitucci’s bass, but I thought the synth tones were cheesy, the snare drum was mixed way too loud (I still think that), and I didn’t really care for either Frank Gambale’s guitar or Eric Marienthal’s sax.

Listening now… well, I think it’s much better than I remember it being, even if some of it does sound like it should be playing on the Weather Channel’s “Local on the 8’s.”

A simple way to add responsive (breakpoint-specific) blocks in Gutenberg

The new WordPress Block Editor (a.k.a. Gutenberg) has improved immensely over the years, to the point where I am now willingly (although occasionally grudgingly) using it as my main development platform for client sites.

One area where it really falls down though is in smartly handling responsive breakpoints. There is some effort to make it responsive-friendly (though it’s definitely not “mobile first”), but there are really weird holes, like the fact that there’s no built-in way to apply consistent left and right margins on text content at smaller screen sizes; once you’re below the defined content width, if you don’t manually configure your theme to add padding/margins to headings, paragraphs, etc., and they don’t have a defined background color, the text will bump right up against the edges of the screen.

That’s not the problem I’m here to solve at the moment, however. Instead, I want to focus on a handy little tool I’ve been using in my WordPress development for over a decade: specialized CSS classes to designate blocks of content as only appearing on phones, or not appearing on phones.

By “phone” here I just mean the smallest standard breakpoint. I’m using the WordPress convention (at least it used to be the WordPress convention; I don’t feel like I can trust anything anymore) of setting that at the slightly odd (although even) value of 782 pixels.

What can you do with this? Once you have CSS classes that designate a block as only appearing on phones or not appearing on phones, then you can easily tailor your output to certain screens. Obviously (at least, I hope it’s obvious) this is not the ideal solution; it means you’re delivering HTML content — potentially redundant HTML content — that will not be seen by some users. But nothing in web development is perfect, and this can be a convenient way to get out of a pinch when, for example, you have a very complex desktop layout element that simply cannot be adapted in a usable way on phones. You can just hide that element on the phone breakpoint and, if desired, present the same content in a more simplified way to only phones. (Again… only if you can’t achieve a usable phone experience on the same HTML block via media query-specific CSS.)

OK, let’s get down to it. The first thing you need to do is register a couple of block styles. I am only making these styles applicable to the Group block, because that seems like a logical way to rein it in. Any block can easily be wrapped in a group, so if you need this feature, just do it.

register_block_style('core/group', array(
  'name' => 'no-phone',
  'label' => 'No phone'
));

register_block_style('core/group', array(
  'name' => 'phone-only',
  'label' => 'Phone only'
));

That should go into your functions.php file or wherever in your theme you are defining block characteristics. Ideally it should be in a function that is executed on the init action. Next, you need to make sure you’ve got a custom block style .css file enqueued for the Group block. You can place this wherever is appropriate within your theme; I happen to have a nested assets/css/blocks folder where I put mine. Here’s that bit of code, also for your function that runs on init.

wp_enqueue_block_style('core/group', array(
  'handle' => 'my-theme-core-group',
  'path' => get_theme_file_path('assets/css/blocks/core-group.css'),
  'src' => get_theme_file_uri('assets/css/blocks/core-group.css'),
));

And then in the referenced core-group.css file, you’ll need this:

@media screen and (max-width: 782px) {	
  .wp-block-group.is-style-no-phone {
    display: none !important;
  }
}

@media screen and (min-width: 783px) {
  .wp-block-group.is-style-phone-only {
    display: none !important;
  }
}

Now in the Block Editor, when you switch to the Styles tab when focused on a Group block, you’ll see your new style options: