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.

Gutenberg: How is this better?

Every time I run into another weird, seemingly illogical quirk of the process of building a WordPress theme with Block Editor (a.k.a. “Gutenberg”) support, I ask myself the same question: How is this better?

As time goes by, the answer is starting to come into focus. Unfortunately, it’s not entirely satisfying.

Here’s what I’ve learned so far.

How is this better than what came before?

Well… what came before? You can’t ask the former without first answering the latter.

Over the years, WordPress has become many, many different things to different people. So you can’t expect the Block Editor/Gutenberg to be universally better (or worse) than what it’s replacing, because it’s replacing so many different things.

Is it better than the various “page builder” plugins out there? I’m looking at you, Elementor, Divi, Beaver Builder, and WPBakery, among others.

Honestly, I loathe every last one of these page builder plugins. Partly that’s because before I worked primarily with WordPress, I rolled my own CMSes for years, dating back to the pre-.NET Microsoft era of ASP talking to a SQL Server 7.0 database. Then I moved to MySQL and PHP, first building a completely custom system before any MVC frameworks existed, followed by several years of development on a fairly robust custom CMS based on the CakePHP framework. I was very proud of that work, but by 2014 it was clear WordPress (which I had used for my own blog and occasional client projects since 2006) was picking up enough steam as a general-purpose CMS that my own couldn’t keep up, and I took the WP plunge.

Almost immediately, I wholeheartedly embraced Advanced Custom Fields as my solution to extend WordPress. And, in particular, I used its Flexible Content fields to create my own Block Editor-style interface, years before Gutenberg existed.

It’s way better than page builders.

But it’s also not entirely “the WordPress way.” It’s way more “the way” than Elementor and its ilk, but still… it led to a situation where all page content on my sites is stored in the wp_postmeta table, which is not ideal, for many reasons.

What’s good about the Block Editor?

I absolutely, 100% prefer the Block Editor/Gutenberg over the popular page builder plugins. It’s a much cleaner, faster, more intuitive user experience, and it renders front-end pages quickly. It’s built in which is a benefit in and of itself. But honestly, it only feels built in because WordPress is changing itself to be more like Gutenberg, rather than Gutenberg being built to feel like the WordPress we know and love.

Aesthetically, I like the Block Editor. For usability… well, where do I begin? I’m an old fart who still expects all of the available options to be visible on-screen, not just “discoverable” if I happen to hover my mouse in the right spot. And I’m a lot more savvy to this new type of interface than most of my clients, so I struggle to understand how the WordPress core team thinks this is an optimal approach. (OK, so maybe this paragraph belongs in the “bad” section below.)

But that leads me to the best thing about the Block Editor, which is not inherently great. It is what it is. I don’t mean that as the empty cliché we hear a thousand times in every business meeting or reality show interview. I mean it literally: The Block Editor is WordPress now. There’s no going back. So while that may mean some growing pains and struggles, it also does mean that it will (probably) continue to get better over time, and unless it is an absolute failure, WordPress will continue to grow, which means it will always continue to receive support.

What’s bad about the Block Editor?

This is another one that really depends on your perspective: where you’re coming from, what you’re used to, what role you play in the creation of a website.

If you’re a content editor who is a capable system user but not a developer/UI designer, and you’re used to the “vanilla,” TinyMCE-based WordPress classic editor, there’s a very high probability that you will be confused, overwhelmed, and/or frustrated by the Block Editor, because the concept of “blocks” does not reveal itself in the most optimal way as you are discovering it. (I’m not sure what the most optimal way is, but I’m confident this isn’t it.) I will say, however, that the glitchy, wonky, invasive behavior of earlier iterations of Gutenberg has almost entirely been smoothed out.

On the other hand, if you’re that same content editor, but you’ve been forced in the past to work with Elementor, Divi, Beaver Builder, WPBakery, or something similar (and, if you have, I’m almost certain you hate it, based on anecdotal observations), then I think there’s a good chance you will love the Block Editor, at least if you’re given the opportunity to experience it in its pure form, not something that’s been bastardized the way those aforementioned plugins destroyed the classic editor.

But me? I’m a developer. Although I obviously spend a fair bit of time using the editor to test my work and also to assist in initial content loading on new sites, I mainly work behind the scenes, in code. And this is where I struggle mightily to understand just what the hell were they thinking??? with some of the decisions that went into how the Block Editor functions at a code level.

What’s it like to code for the Block Editor?

There are two main ways in which building Block Themes and/or coding for the Block Editor differ greatly from the “classic” way WordPress has functioned up to this point.

First, at a more surface level — in fact, it’s a level you can even stumble upon in the Block Editor itself if you click the right (wrong?) button — there’s the block markup, and how it gets stored in the database.

There is something that is absolute genius about this. In fact, conceptually it’s probably the biggest Eureka! moment of the entire Gutenberg project. All of the meta data about each block is just HTML comments. That means that all of the actual content of a page/post built with the Block Editor is stored where it should be in the database: in the post_content field of the wp_posts table.

This is much better than the way Advanced Custom Fields works. It’s fewer database queries, so it’s faster, and it’s where the content “belongs” so it’s automatically handled correctly by plugins — anything from Relevanssi for custom site search tools, to Yoast SEO for search engine optimization. (OK, those are both search-related, but in very different ways.) And the use of HTML comments for the meta data means it’s even backwards compatible: if the content gets loaded in a theme that doesn’t support the Block Editor, it may not look exactly right, but your content will at least still be on the page, in its entirety.

The problem is, the code itself is kind of a mess. I like the idea of using HTML comments to store the block meta data, and I like the use of JSON as the format for the properties.

But it often ends up being a lot of code, which is messy if you ever need to look “under the hood.”

And it’s fairly brittle, so if you edit any of it directly, you’re probably going to break it, and at this point the Block Editor only has middling success at recovering “broken” blocks.

And the documentation so far is woefully lacking. I know only too well how hard it is to make the time to write proper documentation, but when you’re forcing a change this radical on a user base this large, you need to prioritize it.

And worst of all, all of that JSON code is really only to get the editor to “remember” the settings for the block when you go to edit it. Most of the details also have to be repeated in the class attribute for the container HTML element in order to actually render anything stylistically in the page. (Once again, I don’t really know the optimal solution, but this isn’t it.)

And. And. And. And. And. (Sorry, wrong software, but since it’s timely I thought I’d throw it in there to amuse myself when I re-read this post in a few years.)

OK, all of that was only the first way the Block Editor differs greatly from the classic WordPress developer experience. The other way is the template structures that go into a theme.

I’m pretty flexible about how code files should be organized, as long as they are organized. Each project is unique, and as long as it has a consistent internal structure, it doesn’t have to be the same as every other one. I know this attitude is somewhat heretical in certain circles, and honestly the fact that WordPress has heretofore been just as flexible has created a lot of headaches for people trying to understand how themes, plugins and the WordPress core interact. It can also make it exceedingly difficult to jump into a custom theme someone else built and figure out where the hell everything is.

I get it. And I appreciate the core team’s efforts to impose a new, consistent structure that reinvents the way WordPress themes are built, and that aligns with how the Block Editor works.

I also get that it was not just an arbitrary decision to build the Block Editor on React. The Block Editor needs to be dynamic in a way the classic editor is not, so a purely PHP-based interface would not work. Not even something using the already-present jQuery would do the trick.

But building the Block Editor on React requires developers to know or learn React. I’m all for people learning new skills and adapting with the times (even though I haven’t bothered to learn React yet), but it’s a tall order to force an entire development ecosystem to radically shift gears.

That’s not even my biggest criticism though. What really bothers me about the new Block Theme template structure is the move away from PHP in areas where server-side scripting clearly offers some major benefits, with only the most nebulous justifications for the change. It usually comes down to “PHP is too intimidating to users,” but I find that really hard to accept, because PHP is much easier to learn, especially to a “dabbler” level, than React, and it’s way more forgiving than JSON.

So far my work on a new Block Theme hasn’t even touched React (partly thanks to my good old friend, Advanced Custom Fields). I’m coming around to the theme.json file, the more I work with it. I still want to be able to use PHP to dynamically set site properties, but I’m learning, little by little, how to accomplish my goals without it. (Or, perhaps, I’m changing those goals to suit the new platform.) I’m also slowly coming to understand that theme.json is mostly just for generating the inline CSS Gutenberg outputs in the <head> (and some ancillary functionality in the editor itself), and not a comprehensive spot for all manner of site parameters.

What I really do not understand, and may never accept, however, is the decision to make the files in the templates folder plain HTML files instead of PHP. In fact, my struggles with this very issue are what prompted this entire rant.

How do I use translation functions on hardcoded text in the templates, without PHP?

How do I selectively display post meta data — like author, publish date, and taxonomies — for posts in the search results template, but not for pages, without PHP?

I don’t have answers to these questions. Yet. But they beg the larger question of why the templates aren’t written in PHP in the first place. Is it a performance thing? That might be justifiable. But the whole “ease of use” argument makes no sense. A person isn’t going to be creating a theme in the first place if they don’t know some PHP.

No, I think it probably all comes down to being a decision that’s part of the development roadmap for Full Site Editing. So the decision is more about what the core team wants than what I want. Fair enough.

Who is this really for?

This is another grand question. Who is the Block Editor really for? Who is WordPress really for? I had never really asked that question, rhetorically or literally, until the Gutenberg project.

WordPress started out as blogging software. But it has since become much more than that. It famously powers somewhere around 40% of the web. Are 40% of websites blogs? In terms of sheer number of sites, maybe. In terms of amount of traffic, definitely not.

WordPress powers everything from the most obscure blog no one but its owner reads (don’t look at me) to massively popular sites that have thousands of simultaneous users. And it’s not just blogs. WordPress may not have been designed to be a general-purpose CMS, nor, in many ways, is it ideally suited to that purpose, but historically it has had the right mix of flexibility, extensibility, ease of use, and low barriers of entry, that it has come to be used for just about any purpose one might imagine a website serving.

But who is it really for?

I’m reminded of the story (recounted by John Gruber on a recent episode of The Talk Show) that Steve Jobs apparently pushed for the creation of the iPhone because he wanted a way to check his email on the toilet. The iPhone is, in the most generous sense, for everyone. But in a particular way that was critical to its actually coming into existence, it was for Steve Jobs and his bathroom correspondence habits.

So again, who is WordPress really for? Who’s making the decisions that ultimately determine what goes into it, that define what it is? That of course would be the core team, and probably more than anyone, the leader of the core team, Matt Mullenweg. I don’t know much about Matt, other than that he spearheaded the initial WordPress project (at least once it was forked from b2), that he now runs the semi-eponymous Automattic, and that we most likely have very different senses of humor. (Consider this: I’ve written a plugin that partly exists to remove humor/”folksiness” baked into WordPress that I am pretty sure is attributable to Matt.)

Matt still leads the core team, and has final say on certain decisions about its direction. Ultimately, if he thinks something matters for WordPress, it makes it in. And he clearly believes WordPress is still primarily, if not entirely, for blogging.

Again, maybe in terms of number of sites, “most” WordPress sites are straight-up personal blogs. But in terms of an active ecosystem, a development community of people who are able to make a living building WordPress sites, who comprise a thriving professional industry, in my experience, at least, blogging is peripheral or absent entirely from most professional applications of WordPress. It’s a general-purpose CMS, first and foremost, even if that’s not what it was originally intended to be. And, sadly, even if that’s still not what its core development team prioritizes.

I don’t know. I’m just me. A solo, somewhat iconoclastic developer who likes to do things their own way. I’ll probably never embrace putting spaces inside the parentheses in my PHP code, and I definitely won’t use if: endif; constructs.

I have strong opinions, but I’m not an idealist.

I just want PHP in my damn templates. Is that too much to ask?

Ironic side note: This site is one of the few cases where I have built a WordPress site that absolutely is a blog, full stop. And it’s not using Gutenberg, because I set up the Classic Editor plugin on it ages ago. But as I write and edit this post, I’m actually finding myself wishing I had the site running Gutenberg instead of switching between the back end and the front end. Of course, that’s because I always write my posts in plain HTML rather than the visual editor. I said I’m an old fart.

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.

Writers, learn to write

I have decided that my new ultimate pet peeve in writing is people using “formally” when they mean “formerly.” It takes the place of the equally annoying use of “of” in place of “have” (as in, “should of”).

Both of these errors seem to indicate a purely aural (as opposed to vocabulary/grammatical) way of understanding language. Which is OK for an average person; I’m not trying to be an obnoxious pedant. I don’t care so much when I see these errors in informal writing, but when you’re paid to write for a reputable (?) publication, you should know better.

Then again, this issue maybe only happens online, where these supposedly reputable publications a) don’t pay their writers enough to spend time polishing their work before submitting it, and b) don’t bother running these posts past editors before publishing.

Fun with recycled IP addresses

OK, well that title kind of gives away the end of the story, but it’s still a good one.

So…

Earlier this week I launched a new site for a client. As part of the usual process, I submitted their sitemap.xml file to Google Search Console and Bing Webmaster Tools. Usually that’s all it takes for a new site to get indexed within 1-3 days.

But it seemed to be taking longer than usual for this client, and I decided to investigate the situation.

I should note that we did a private “soft launch” of the site about a week prior to the official launch. During that time I had a robots “noindex” directive turned on so it wouldn’t start showing up in search engines prematurely.

I went into Google Search Console to request a re-crawl. And that’s when I noticed this…

Excluded due to 'noindex'

Well, that’s… weird. Not so much that it had read a “noindex” directive when it, unfortunately, had crawled the URL just a day before we launched — although it was a bit weird that it had crawled it at all — but that the Referring page was a totally different site that should have had no business linking to us, yet.

So then I did what anyone (?) would naturally do, I visited that URL. And much to my surprise, it redirected to our site. What??

Next I used mxtoolbox to do a DNS lookup, and suddenly it all made sense.

We’re hosting the site at Linode. And as it happens, the DNS entry for the referring site is set to the same IP address as our site. This is a virtual private server, so we’re the only people now using this IP address.

But there are a finite number of possible IP addresses, especially IPv4 addresses (about 4 billion). So they naturally get reused. This particular site was for a limited-use product that was only relevant in 2015, so it’s not too surprising that the owners of the domain took down their Linode server and relinquished the IP address. It’s unfortunate though that they didn’t think to remove the DNS entry from their zone file.

At this point, we could (a) contact them and ask them to update their DNS, but that could be convoluted and time-consuming, for no real benefit to us, (b) set up a rewrite in our server that shunts traffic that’s trying to access their product site back over to their main site, which would take less time but also wouldn’t really benefit us in any way, or (c) leave it as-is, and let the few randos who are still looking for a product that was last relevant during the Obama administration wonder why they’re instead seeing our site.

I’m going with (c).

I’m also going with submitting re-crawl requests to both Google and Bing so we can get in the priority queue, and hopefully by this time tomorrow the site will be showing up in search results.