So, Chome 76 (or later. But what version of Chrome am I running anyway?) is getting a feature that would have saved me at least a little work on a few client projects. That is, it’s making lazy-loading of images and iframes as easy as:

<img src="image.png" loading="lazy" alt="…" width="200" height="200">
<iframe src="https://example.com" loading="lazy"></iframe>

What’s lazy loading? As you might have guessed from the name alone, it’s when a browser that’s not currently showing an image (in the “viewport”, or part of a page it’s showing) doesn’t actually download that image. This means that if you’re on a slow connection, you’ll load each image as you need to see it, rather than it just seeming to take forever to load the page initially. It’s generally regarded as a best practice, but it’s never been easy.

Previously, to add lazy loading of images to a page you’d have to go through and change out the page markup and then load in the img attributes later with some JavaScript. If (or when) this Chrome behavior becomes a standard used on all major browsers, then you’ll just have to add this loading="lazy" line to each image (or iframe) you want lazy loaded.

The “if” I said above it my one source of hesitation here. I don’t know a lot about what the standards bodies internal functioning is, or if this is the standard way that a web standard eventually gets approved. But my (unfounded) nervousness about Google making the HTML that supports them (vs the open web) is the only reason this is anything but unalloyed *great* news to me.

I was recently working on a client project where I was faced with the question: should we have one WordPress multisite installation, or many “stand alone” WordPress sites? I gave the correct and scapegoat-y answer: “It depends.” And I was right, but if (like me) you weren’t really aware of the intricacies of that trade-off, I recommend reading this little article from Andy over at Beaver Builder.

In short, a lot of people fear WordPress multisite, and with reason. It’s a different way of using WordPress. But it’s a good one for specific scenarios. For example, Multisite is great if you don’t want to update plugins across dozens of sites. But, you also make it much harder for one site owner to choose to use a different plugin for some common functionality.

Anyway, enough of my yammering. Read more from this article. Here’s my favorite bit, on making the choice:

A WordPress Multisite network is a great solution for managing closely-related sites. But let’s be honest – very few of your projects are going to meet that criteria.

You’re probably dealing with multiple WordPress installations spread across at least a handful of different hosting providers. These sites might be running similar themes and plugins, but aside from that, they’re distinct – owned and operated by clients who aren’t associated with each other.

The upside to keeping these sites separated is that it lowers your risk as a site developer and administrator. You can tailor the setup of each site to suit the needs of the client and the needs of whatever hosting provider they’re using. If something goes wrong on one site, it won’t affect the performance of another site.

The downside is that this adds more overhead to your routines. Software updates, troubleshooting, user management, client reporting – these are all administrative duties that take time away from you working on bigger, more valuable tasks.

The weirdest piece of email I’ve gotten all month was courtesy of Brian Krogsgard and the Post Status newsletter: Automattic (owner of WordPress.com, Jetpack, Akismet, WooCommerce…) has just bought blogging giant Tumblr.

Tumblr is a site that normal people have heard of, in a way they haven’t heard of WordPress.com, Jetpack, or maybe even WordPress itself. It’s the site whose oddly difficult-to-follow threading format you’ll instantly recognize if you like internet memes. Most visibly, it’s also the site that banned adult content last year, a decision that was covered widely in the news media and has led to, for example, YouTube videos parodying its executives’ decision making that have garnered millions of views.

It turns out Tumblr was owned by Verizon, following a more than $1 billion 2013 acquisition by Yahoo! (now also owned by Verizon). Whether or not the decision on adult content was a mistake, Verizon certainly seems on board that it’s been horribly mismanaging the property, because its top priority is clearly just to get out of the business: it appears to have sold Tumblr to Automattic for $3 million. That’s an absolutely mind-bogglingly low number. $3 million is almost in the range of what a small business could scrape together. That’s Verizon’s asking price. To buy Tumblr.

I don’t know what likely happens from here, and how it changes WordPress’s future. One possible answer is, simply, “it may not change much.” Tumblr itself may be fatally wounded at this point, and as savvy as Matt and Automattic are in some ways, we don’t know if reversing the fortunes of a declining blogging platform is in their wheelhouse. Nor do I think that WordPress itself necessarily becomes massively better or more connected now that Tumblr is owned by the folks who own Jetpack. As with the WordPress Rest API a few years ago: the news feels big—but, big how?

I am also curious what adding Tumblr’s staff of 200 people will do to Automattic’s priorities. There’s a world in which the Tumblr acquisition becomes a costly distraction in terms of WordPress’s progress forward as a software project—not because Automattic runs WordPress, which it doesn’t, but because Matt’s priorities tend to still get done in the absence of a better-functioning governance model for the project.

More than anything, this does seem like a confirmation that we are in some sort of End Times event, at least in the blogging world. But for much higher-quality analysis than that, you should read Brian’s article.

I like the direction that Josepha Haden is pushing WordPress. She’s making strides to put the whole project on an even better trajectory. Toward better collaboration, better effectiveness, more inclusive. It’s not the case that I (as a random person far from the core of most of the projects) know a lot about how it feels to people more involved, but I hope and see signs that those more-involved agree.

It is because of this that I’m cheered by the idea she presents in this proposal of forming an advisory board for WordPress. I think it’s important to balance enthusiasm for a board with the idea that boards and committees are both great at doing things, and great at causing ineffectiveness. But I’m staying optimistic. Part of making sure there’s an attitude and reality of collaboration will be grounded in there being real discussions and formal cross-boundary problem-solving. And making places for that collaboration to happen is a real and important prerequisite to it happening.

If you’re at all interested in this idea, I really encourage you to chime in on the discussion on the post itself. It seems like a reasonably vigorous and quite intelligent discussion. But it’s too currently busy for your voice to register.

(Discovered via the WP Tavern write-up from Sarah Gooding, which is itself quite good.)

This is a solid little article from the folks over at SpinupWP about caching in WordPress. “Caching” is one of the most simply and complicated words, almost simultaneously. The heart of the issue, there there are so many different kinds. A few years back I tried to tease those types of caching apart, but but different takes on the same basic material work better for different people.

Ashley’s article is a lot prettier, more direct, and actionable than mine. I particularly like all the pretty diagrams they’ve included in the article. The core point of all caching, as I see it, is in this quote:

Before we dive into the various caching mechanisms, it’s essential to understand the benefits of caching. Caching plays two major roles:

1. It improves application performance. For WordPress sites, this means that your site loads faster.
2. It increases application throughput. Meaning, your site can handle more traffic.

What’s more, caching can increase both application performance and throughput without increasing hosting costs. This is because you need far less system resources (CPU & memory) to host a site that has been correctly cached. It really is a win-win strategy (when done correctly).

We were on the BoldLife podcast. It was a great time. We (well, especially Fred) talked a length about the complex reality of where generous human people meet the weird world of corporate policies. More than that, we talked about what that means when you’re shopping for the best WordPress hosting for  your own website. And why talking to the nicest person from one of the those companies is probably a less reliable way of finding good hosting than we are.

We also talked a little about WordCamp Denver, Up and Running, and how Fred, Jesse, and I all went to high school together. Thanks to Jesse and Mike for having us 🙂

Reviewing the SEO of small business websites.

End-to-end (e2e) testing is a methodology used to test whether the flow of an application is performing as designed from start to finish.

What’s actually happening on the hundreds of thousands of small business websites we hear about? This teardown looks at 150k of those sites, and the answer is it’s a bit of a wild west:

• ~2% of small business websites are marked noindex, which means search engines will not index the site! This rises to 4.4% of websites on Squarespace have the setting, and 2.1% for WordPress.com.
• 25% of all small business websites are missing an H1 tag, which tells search engines what the most important content on the page is. Shout out to Wix this time, with 40% of their sites missing it. WordPress.com still does fairly badly with 24% of sites missing the tag.
• Yelp and other directory sites dominate search for small business terms (such as “best plumber [town]”. Yelp appears in the top five search results for 92% of these searches.

The full report makes for interesting reading. It’s clear there’s still a very, very long way to go in order to reach the holy grail of easy-to-make small business websites, whether that’s on WordPress or somewhere else.

This post first appeared in MasterWP, a weekly newsletter for WordPress professionals.

Tom Scott is one of my favorite YouTubers. (I know a lot of nerdy YouTube channels these days.) He is clear, knowledgeable, and a bit like what I’d make on YouTube if I’d started eight years ago and was British.

And since I think that a lot of WordPress folks may either be app-dreamers, or dealing with app-dreamers as clients, I found a great excuse to link to a YouTube channel which is mostly about very-other topics.

The series is a great summary of interviews and conversations about the marketing and other realities of making an app that too rarely succeeds. I think the series is great. It’s not over-optimistic “you can do it!” cheer-leading, but nor is it fatalistic “all apps are garbage” time wasting. There’s a lot more to building an amazing app than a few hours of video (even from someone as concise and clear as Tom) can cover, but so far from my watching it’s a great start to previewing the reality of what a successful app would take. He covers a lot of things–prototyping, validation, technology choices, etc–in enough detail that you’re getting off to a good start.

Here’s the trailer for the (totally free) playlist:

This is a fun and short little post over at Dev.to from Ananya Neogi. It’s essentially a short-list of lesser known features for which you can just add some HTML markup and have cool features.

What I love about it most of all, I recently built out #1 on her list (quickly) and was a little annoyed by using the old JavaScript library I use for it. But I, for one, had no idea that HTML could do a searchable-dropdown nearly so easily as input list="myIdforDatalist". None!

Also cool things she features: dialog boxes, progress bars, and color pickers. None of which I knew about. I’m a little on the fence between embarassed and excited that these things existed and I didn’t know about them. But I’m choosing to certainly and clearly go with excited. You should too!

Matt on WordPress at WordCamp Europe.

Matt’s Summertime Update was definitely that: an update on what has been happening in WordPress in the last six months, with the focus more or less totally on Gutenberg.

We’ve heard about four phases of Gutenberg:

1. The new Block editor, added in WordPress 5.0. This is complete.
2. Taking the Block editor outside post and page editing. This is in progress now.
3. Better writing and editing collaboration. This is next.
4. Core support for multilingual sites. And this is after 3.

We’re currently in phase two, and the focus was squarely on what’s been happening with phase two. We heard about some interesting plugins, some innovative new concepts, and the progress in Core. Some highlights from the talk and subsequent Q&A:

• There’ll be a Block Library for installing blocks straight from the editor. If you want a slider but don’t have a slider block installed, you’ll be able to search “slider”, and then install and use a slider block plugin straight from the editor.
  • This will have a big impact on the block ecosystem: most solutions we’ve seen so far have been focused on adding block libraries (ie CoBlocks, Atomic Blocks) rather than individual blocks. I think everyone’s assumed users will want a single plugin which adds all the blocks they need; if this goes ahead this is a huge incentive to do single-purpose blocks instead. In the long run sounds like we’ll stop calling these “block plugins” and just “blocks”.
• Lots of exciting new blocks are being experimented with, including one which adds a grid where you can build a “snap to grid” layout. This kind of block can fulfil a key part of Gutenberg’s promise, which is to make it easy for anyone to make a nice website.
• A question about “when there will be” democracy in WordPress’ decision making process was answered more or less with Matt saying he had no plans to dramatically change WordPress’ governance.
• We don’t know what the future of themes will be, and it may be up to theme-makers to figure this out. On the current trajectory it seems themes will play a smaller role, so it’s up to theme-makers to do something different and keep them highly relevant.
• Trac might move to a Git-like infrastructure soon, just not this year.
• The REST API slowed Gutenberg down, and Matt didn’t like that.

There wasn’t a huge amount on Stages 3 and 4, which I found disappointing. At one point Matt mentioned he felt Gutenberg is 10% of the way there to achieving his vision – and that getting all the way there will be 15 to 20 years of work – and he’s surely the only person in WordPress who is thinking so far ahead. I think he’s best when outlining and then going after a grand vision for the future of the internet, and it was a pity there wasn’t more on this.

Matt pretty much solely decides WordPress’ direction, and with that comes a responsibility to let the community discuss that direction. I’ve said before we could have avoided some of the controversy around Gutenberg if the community had been more involved in a discussion about the vision and problems we were aiming to solve at the start. A couple of weeks ago when I spoke to Josh Koenig, co-founder of Pantheon, he described “a lot of the holes in the tapestry of WordPress”, and I feel part of the sticking point on that is uncertainty about what WordPress Core will do next. Will the problem you’re solving be added into Core? These twice-annual keynotes from Matt are one of the best opportunities we get to hear his vision, and we need to hear his vision for the future!

The audience at WordCamp Europe is always tougher than at WordCamp US, but Matt generally went over well. And indeed, this was called a “Summertime Update” and this was an update, so maybe I’m being too picky. For further coverage, I live tweeted the keynote with some commentary in this thread, WP Tavern has a write-up, and David Bisset did his usual superb job of live tweeting (you’ll need to scroll back through his tweets). The photo is from the WordCamp Europe Twitter (I think taken by Val Vesa).

This post first appeared in MasterWP, a weekly newsletter for WordPress professionals.

I realize this is local news, but we’re trying to make sure we sell out WordCamp Denver this year, which requires some exceptional effort. So if you’re near Denver, Colorado, and don’t have plans for Saturday July 29, you should come to WordCamp Denver.

For those unfamiliar, WordCamps are locally organized conferences put on by members of the WordPress community for the local WordPress community. I’m on the organizing team for WordCamp Denver this year. WordCamp is always very affordably–at $20, ours is slightly more expensive than you’d pay for the free lunch you get, ignoring all the people you’ll meet and talks you’ll see. If WordCamp Denver isn’t local enough for you, check out WordCamp Central, where all worldwide WordCamps can be found.

Anyway, if you’re going to be at WordCamp Denver, say hi. Either just approach me in the halls or rooms I’m sure to be in, or email me–david@wpshout.com if  you want to set-up something more formal.

Ever just wanted to be able to easily run a text search against literally every theme on plugin in the WordPress repository? Honestly, me neither. But isn’t it cool to know that you can?! WPdirectory is fun silly tool that I just like knowing exists. And like I said, it make if fairly easy for you to search every plugin and theme freely distributed on WordPress.org in a quick and effortless way.

Though I joked about it above, I can actually think of a few uses for it. But mostly that’s because Ben Gillbanks explained some actually useful and clever ones. (Emphasis added):

If there’s a functionality you want to use, but are not sure how, then you could search for that function name or library or  and see how other projects have added support for it.

It could also be used to search for security vulnerabilities, or coding patterns, naming conventions. All sorts! I’ve bookmarked it, I can see there being lots of potential uses.

All very good ideas. Let me know if you think of more 🙂

(Via Alex & Ben’s MasterWP newsletter)