Category: Computers & Technology - Page 6

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

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.

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:

The “house of cards” approach to development is a “fatal error” in itself

This morning my work of putting out a fire for one client was interrupted by the need to put out a blazing inferno for another client. Specifically, they’re running a big sale on their WooCommerce store, and the site was returning a fatal error.

Turning on debugging, I saw this message:

PHP Fatal error: Declaration of Dhii\\Container\\ProxyContainer::has($key) must be compatible with Psr\\Container\\ContainerInterface::has(string $id): bool

Ugh.

There is so much about this that I hate. Mainly, what is any of it for? I have to question whether any of the developers of PayPal Zettle POS for WooCommerce, the affected plugin, really know either. This plugin suffers from what I call the “house of cards” approach to development. Why write your own code if you can just slap together dozens of packages that already do the things you want? On the surface, that’s great. But the problem is, then you don’t really know what your own software does.

I recognize that this is a necessity in many cases. It’s just not practical to reinvent every wheel. But when your application is structured like this, you may have 6 different kinds of wheels, or wheels made out of other wheels, or wheels that also contain a kitchen sink. As usual, xkcd nails it:

Fortunately, WP_DEBUG let me see exactly where the errors were occurring, and although my 20 years of idiosyncratic PHP development experience didn’t help me to understand what the error meant, this StackExchange post did. I just had to change this:

public function has($key)

…to this:

public function has($key): bool

And then I had to do that about a dozen more times in various other files deeply nested in the plugin’s vendor folder, until the PHP fatal errors stopped appearing.

In the WordPress support forums, I discovered near the top of the list a post from someone else experiencing this same error, and the devs suggested it was probably a plugin conflict. They didn’t seem interested in pursuing the possibility that their own code was broken.

But, then again, it really isn’t their code. And that’s the problem.

I’m not above reproach here. I’m a WordPress developer. I use other people’s code all the time! I even sell a product that is substantially constructed out of other people’s code. But I am very judicious about what does or does not get placed in my vendor folder. And I realize that if something goes wrong with it, it’s up to me to fix it, even if it’s not my code.

Speaking of which… I have some updates to make. Gotta go!

Some perspective on Gutenberg

Today I had to do some work on a client’s site that I didn’t build but have ended up maintaining, which is built from an amalgam of multiple “page builder” plugins, but most prominently, WP Bakery.

I was just explaining to my wife (who is not a developer but who uses WordPress, both Classic Editor and Gutenberg/Block Editor, extensively) what it’s like to use WP Bakery:

“Imagine the most annoying aspects of Gutenberg that you find the most annoying*, then imagine something ten times clunkier, a hundred times uglier, and a thousand times less intuitive. That’s WP Bakery.”
—Me

*Yes I really did, deliberately, say it that redundantly.