Back in 2007, when I was just coming to terms with WordPress, Justin Tadlock was out at the forefront of what I understood WordPress to be. In the (gosh!) 12 years since, Justin’s stayed busy in the WordPress space, but also done some other things like share on his blog about his small farm.

On the whole, Justin is in my mind one of those people that belongs on a Rushmore of WordPress. He’s just always loomed large, has taught me a lot of what I know, and has always seemed humble and generous while doing it.

All of this is just to explain why I thought it interested and notable enough to share the fact that Justin has stepped into the shoes left behind by Jeff Chandler at WP Tavern. If you don’t follow it, the Tavern has been a prominent voice in WordPress for a long time. It has been bankrolled by Matt Mullenweg for the last (memory fails me, I looked it up) 6 years, and I’m really excited to see what comes next form Sarah Gooding and Justin over there.

Digital Ocean, a popular VPS hosting provider, recently announced a hosted-MySQL platform. The reasons you may want to do use this (vs putting the MySQL instance on the same server as your WordPress wed server) are a little more subtle than I want to get into here, but suffice it to say you’d get better scalability but a possibly more complex setup. For that reason, I’m linking to this tutorial on the topic from Mark Drake.

I’ve got an interest in using this for some syncing of my various development environments. But enough about me.

This tutorial does a few great things, but the most interesting one is that setting up of the database. In many ways, the rest is a fairly common WordPress install guide. The use of Apache (vs Nginx) is one of the aspects of that stuff we could have long debates about, but again I’ll defer that discussion to other venues and opportunities.

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: