As an AMP hater, I was gratified to see this headline from Sarah Gooding over on the Tavern.

Here’s the core his very frank and pretty interesting resignation post:

I can’t in good faith continue to advise on the AMP project for the OpenJS Foundation when it has become clear to me that AMP remains a Google product, with only a subset of pieces that could even be considered open source.

If I were to remain on the advisory committee, my feelings of resentment about this situation would inevitably affect my behaviour. So it’s best for everyone if I step away now instead of descending into outright sabotage. It’s not you, it’s me.

I’m linking (with the “main” link below) to Sarah’s story (rather than Keith’s post) because she puts this all in some context I wasn’t aware of. I loved her closing sentences:

In the end, this may not be enough to convince critics that AMP is not simply a Google product with a fancy affiliation designed to make it more appealing to detractors. So far, the project’s new home at the OpenJS Foundation has done little to bolster public opinion in the face of allegations that identify AMP as having an important role in Google’s anti-competitive practices.

Sarah Gooding

This is an interesting little tidbit for “the web industry” generally, and where it interfaces with real people with non-internet-focused lives and careers. The Wirecutter—the de facto site for time-starved yuppies to quickly find an acceptable-to-great version of a product category (aka, how I buy almost everything)—recommends Wix for those looking to make a website.

Now, if you’re reading this site (WPShout) you probably know of another tool or service: WordPress. They did look at WordPress.com. They did not look at “a WordPress site on (your favorite host) with Elementor/Beaver Builder/etc.” And nor do they seem to have been particularly worried about “ease of porting your site” or “ease of augmenting the site with nerdy features.” And you won’t find the term “open source” or “license” anywhere on the page.

For those not following me, the last paragraph is some of the reasons us WordPress folks tend to like to use it. But neither Melanie Pinola (the page’s author) nor its primary audience is thinking about those things. And that’s fine. Good even!

And as “a WordPress professional” you benefit from always keeping that gap in mind. The arguments and benefits that lead Wix (and after that, Square—the payments people) to be the best for Wirecutter readers are places and spaces that WordPress (or whatever other nerdy CMS you’re into) can and should go to stay vital and relevant in the industry. I think the Gutenberg project is continuing to play out as a long-bet for the future of WordPress, and I remain bullish on it. But clearly winning all the battles for the home for “people needing a website” is something that WordPress has not beat the whole world at. (Yet.)

(Hat tip to the Post Status Newsletter for this link)

There’s been some worthwhile discussion of the WordPress learning curve lately. My “main link” here is the article from Courtney Robertson. Though I’d also point to the one of the topic from Justin Tadlock at WP Tavern. I thought Courtney’s summary rang true:

While the block editor experience has improved the content creation and even website assembly side of this process, it can be said that the learning curve for developing with code for WordPress via plugins or themes has become more complex. This is especially true when planning training materials, and retraining developers who began without these extra layers of complexity.

I feel like the amount of JavaScript, not to mention the need to be kind of good at both React/JS & PHP has changed the dynamics of WordPress deveopment from when I started learning around 2007. And though I’m not sure much could be done to avoid it, I don’t envy those starting out today. But I do think its possible. Mostly it just requires two things: more people sharing what they’re learning, and being patient while you’re learning.

One of the more consequential features of WordPress 5.8 I didn’t pay much attention to before it was released was theme.json. Which is “just another file in your WordPress theme” but also a whole lot more. I’ll just quote Jeff Ong from over on WordPress.org:

Conceptually, [theme.json is] a major shift in how themes can be developed. Theme authors now have a centralized mechanism to tailor the WordPress experience for site authors and visitors. Theme.json provides theme authors fine-grained control over global styles, block styles, and the block editor settings.

By providing these settings and controls in a single file, theme.json provides a powerful framework that brings together many aspects of theme design and development. And as the block editor matures and adds more features, theme.json will shine as the backbone for themes and the editor to work together. 

Definitely something to play with, even if you just make simple themes like me. I think it’s mostly clearly vital today as something for commercial themes (much like the “editor styling” from ~10 years about). But I love how centralized (a part, at least) of WordPress theme’s future will be. I’m expecting the importance of this file will only grow 🌱

Those of you who are newer to the WordPress space, just let me tell you that Justin Tadlock is a real WordPress OG (in my ~15 years experience #OfficiallyOld), so I take his opinions pretty seriously. So I thought his whole take on the “state of WordPress theming” is surely a good place to ground your attention and energy if you care about this topic.

WordPress themes are likely to change in the next year in ways they’ve never changed in their history. That’s both pretty exciting, but it’s also a little nerve-wracking. Will they be able to thread that needle. I sure hope so. And what I’ve seen over the years makes me think they will, eventually.

Here’s one good paragraph, to hopefully hook you:

The thing about blocks is that they put this veil over a lot of the messy legacy stuff, creating a new standard where anyone who wants to build a theme does not have to worry about a lot of the history that got us from Point A to Point B. That is a Good Thing. Standardization of the system was long overdue, but we are still in the process of making that final leap forward. It is a tough time to be a developer. It can also be an exciting new adventure if we stop thinking about themes from a traditional mindset.

I’m not an accessibility expert, but I am a big emoji fan (as frequent readers may be aware 🤪). So I took a pretty keen interest in a story from Ryan Kan purporting to make me better at accessibility with specific regard to emojis.

A lot of this advice just feels right—emoji-only button labels are harder to make sense of. But some things I’d really never thought through, like the idea that you should always put words BEFORE emojis on things like buttons. Having heard it, I get it. But I have to admit I’ve likely done that backwards at least once in the past. Live and learn 😅

I was talking with the current students in the Up and Running Bootcamp last week about the new Query Block in WordPress 5.8. I had to admit I’d not really played with it much myself. For that reason, I was quite excited that when I sat down to look for posts to share this morning with you all, I found this great little guide to it that Justin Tadlock put together over on the WP Tavern a few weeks ago.

For those who aren’t yet comfortable with the name of this block, here’s Justin’s great summary:

The term “Query” is simpler than you might think. It merely means to “query” or “ask” for posts from the database according to a defined set of options. For example, one might attempt to get the last 10 blog posts.

“Loop” is an even easier concept to grasp. It means to “loop” or “cycle” through each queried post and output it. Technically, a developer could do things other than displaying the posts during this process, but we are only concerned with what gets printed on the screen.

The two things combined become the Query Loop block. It allows users to ask for a set of posts and display each one.

I loved reading this write-up from Rich Tabor about the what and why of Block Plugins. For those new to this whole thing, I’ll pull his opening summary:

What are Block Plugins? 

If you’ve built blocks before, you may be asking what’s the big deal about block plugins. For the most part, you can think of block plugins as one block, registered and compiled completely in JavaScript, that serves a singular function. These plugins exist solely to distribute a block — and nothing more… and these plugins are meant to be included within the Block Directory.

He goes in to way more besides that—how to make them, what they look like, and how make sure yours works—so be sure to give the whole thing a look.

PHP 8.1 is very much in progress, and is slated to come out in November. While WordPress developers often (and reasonably) don’t use many of the features of PHP 7, nevermind PHP-8-only features, some of these things are at least worst knowing about. Seeing where the language is going (even if you can’t write code that way yet) is always worthwhile.

In the article, Brent kicks off with enums, a whole new data-type for PHP. I’ve heard many mixed things about enums in a variety of domains (I think people hate them as a type for a database columns… 🤓) but from his little example I’m immediately excited to start using them. And no doubt (as one must with most programming paradigms) eventually figuring out their disadvantages 🤪

Anyway, if you’re more than passingly-aware of PHP, probably worth giving this article a quick scan. And if you’re regularly writing PHP, I think a read is wiser.

Another version of WordPress, 5.8 is about to drop. Like literally it is scheduled to come out tomorrow. You’ve probably seen at least a few headlines about it if you follow WordPress news. And it’s a big one!

What particular caught my eyes was this big (and maybe overwhelming) summary of the whole thing over at Kinsta by Carlo Daniele. Unlike the usual “Field Guide” on WordPress.org (this time done very well by Milana Cap), he included lots and lots of screenshots. Which I think is really helpful, because all the recent changes to widgets (make them actually block areas) and the first time we’ll have “Full-Site Editing” features in WordPress core requires a great deal of visual summary.

While it’s hardly as consequential as Full-Site Editing for most non-technical people’s real attention, I’m also pretty into the fact that WebP is coming to WordPress. Anyway, give it a look and you’ll be less surprised when you upgrade 😎

Like many, I’m still very much getting my sea legs when it comes to doing web-development tasks that affect aspects of the (Gutenberg) Block Editor. While its no longer new, it’s never really overlapped very clearly with work either I (or a client) have needed to do, so I’m very much in learning mode with this article from Dmitry Mayorov over at CSS-Tricks. All that is to say: if you click over and this entire article just goes over your head, have no fear (you likely won’t need to do this stuff anytime soon) and I get you.

For those of you who aren’t lost when terms like ES6, JSX, and React come up, I really do think this article is great intro to a topic I’m sure I’ll need to use… sometime. His adding of the size attribute to the button element is actually rather similar to a task I failed and gave up on a few months ago. Happy hacking!

I can’t be the only one who sometimes has dozens of tab open, all from my own WordPress site. And then I lose track of which I was seeing the public side of my site, vs the admin side where I writing a post, tweaking settings, etc.

It’s because of the (admittedly minor, but nonetheless real) headache of this that this little article from Thomas Park over at CSS-Tricks caught my eye. In it he explains how he uses a different color of SVG to allow him to distinguish (for example) these back-end tabs from the front-end ones. But what’s cool is that he even goes a step further, making different pages on the public side of his site have different (colored) favicons.

I admit the tab-finding problem is small and rare enough to me that I’m not adding implementing this to my to-do list anytime soon. But it sure is good to know that there’s a solution next time it really starts to frustrate me. 🙂

I really enjoyed watching this little interview with between Mark & Keith from Highrise Digital and Matt Mullenweg and Josepha Haden Chomposy (who are probably the two most influential people shaping WordPress today). Nothing that anyone said was really a surprise or revelation to me, but it was all helpful and “orienting” to hear again what their thought process is, what’s been happening lately, etc.

For myself, I actually left the interview thinking that “the future or WordPress themes” is even to these important and influential people still an open question. Which I think is both appropriate and a bit annoying. I seems clear that “full-site editing” is reshaping themes in important ways, but not knowing where we’re going leaves one a little unsure what to do. But it also means there’s time to jump in and influence the direction, if that’s something you’ve got interest and time for 🤓

Longtime readers may have caught on to the fact that I’m a big sucker for cool CSS techniques I would have never come up with or figured out. And this is one more example on that.

Over at CSS-Tricks, Silvia O’Dwyer offers a guide to making some really compelling “neon light” effects with CSS. Honestly the visuals of the effect were enough to convince me this was cool enough to share. But she takes it a step further and covers both adding a “pulsating” effect, and even reminds us to turn it off for motion-sensitive visitors. It’s just an all around great little tutorial. Give it a look 🙂

Next week(!) is WordSesh. For those who aren’t familiar, WordSesh is a free online-first (has been doing it since before it became how all events are ;p) WordPress conference. It is totally free for live (and nearly-live attendance). (If you’re a more-than-24-hours-after-conference-end slow poke on a talk, you’ll just have to become a WPSessions member to see talk recordings.)

Our friend Brian Richards (most known for WPSessions) has been running the conference for the last few years, and this years lineup looks set to be great as ever. I’m probably not going to prioritize attending in real-time but that the recordings will be available for free for the whole-event-duration after certainly has my attention.

I doubt I’m alone in feeling a little “behind and overwhelmed” as we swing into the second year of COVID-19-infected reality. So attending WordSesh may be just the thing to get me “back on the horse.” (And if not, that’s OK too ❤️)

Interesting little article over at CSS Tricks from Alex Riviere. In it, he explains that it’s possible to label “if” (and other “block type”) statements in JavaScript. I’ve never heard (or thought about) such a feature.

As Alex says, it’s also a feature that I feel like I won’t use much, because it’s something most people neither know to be possible or will necessarily understand. (I’m always in favor of “broad comprehensibility” above “cleverness.”) But he makes the good point that for specific contexts where many-loops or ifs are not avoidable, it makes sense that these labels would make it a lot easier to track what’s happening.

This example (copied directly from his article) makes the point of their value pretty clearly to me:

let x = 0;
outerLoop:
while (x < 10) {
  x++;
  for (let y = 0; y < x; y++) {
    // This will jump back to the top of outerLoop
    if (y === 5) continue outerLoop;
    console.log(x,y);
  }
  console.log('----'); // This will only happen if x < 6
}

Obviously, real code won’t have these types of “toy conditions.” But the number of times I’ve wondered if a break or continue statement was terminating the thing I meant it to is definitely dozens, and maybe hundreds. So good to know that JavaScript offers a solution to it 🤓

Helen Hou-Sandí is certainly one of the most important people making (core) WordPress better, and she’s been doing it for years. So I take a pretty keen interest in what she’s working on. So when this post about updating a “legacy” WordPress post-meta post so that it was compatible, I knew I had to read it.

And a few months later, I finally did. 🤪

I really appreciated both the article’s style and comprehensiveness. So please give it a read if “modernizing an old plugin for Gutenberg” is somewhere on your to-do list. The article tackles a number of things I’d meant to understand better for years in an approachable way: writing compatible JavaScript and using wp-scripts are the two that leap to mind.

At a recent (virtual) Fort Collins WordPress meetup, someone shared this little site which I’ve never encountered before: Accessible-Colors.com. As you might guess from the name, it’s a simple little site/tool to tell you if the contrast between two colors you’re using in a design is in line with the WCAG 2.0 standard for contrast.

If you color’s don’t quite work, it’ll give you a way to make them work by modifying one or the other of them. In that way, it’s just flexible enough. It doesn’t do more than two colors, and it doesn’t give more than two recommendations. But that’s really all I think it needs to.

I’m sure there are lots of other ways to tell if colors conform to WCAG standards, but I love how simple and quick this one is. Definitely worth a bookmark 🤓