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 🤓

I stumbled across this little plugin from Greg Sweet a few weeks ago. I’ve run it on a few sites, and I think it’s just a great little free upgrade to the “At a Glance” widget on the WordPress Dashboard. (Here I mean the thing that’s labelled Dashboard, not the general “back end administration area.”) It’s simplest to understand what it does by looking. Here is what it shows on the “Content” tab (here on WPShout):

I’m still unsure all this extra data is useful enough that I’ll make a point of installing this simple little plugin everywhere, but I sure like it enough to encourage you to give it a look.

I’m more than a little linking this story just because I hope it comes to pass, rather than because Dwayne Lefluer convinced me that he’s bringing real news that AMP’s end is nigh.

We’ve never really dealt with AMP here on WPShout, and there are a dozen reasons. But mostly it’s just because I think it’s a silly solution for an ad-driven problem. Google were trying to “monkey-patch” the problem of slow web pages in a way that casually also gave Google a big technical lead on getting *their* ads running on publisher’s site.

(I also do some client work where AMP is used, and the WordPress plugin just isn’t good enough for big old WordPress sites, like theirs is.)

I was just thinking the other day that I should send some love to some my favorite “not really WordPress” computer tools. And the first one I want to share is this missing-feature app I love on the Mac called “HazeOver.” In short, it blacks out (or any other color you want, but you want black 🤪) everything else on your Mac that isn’t the front-most app window. (If you’re a visual person, this post’s “feature image” on this post is what my screen looked like while writing this post, with HazeOver running.)

This is the classic idea of a “distraction free” mode, but it extends it beyond the “full browser” window level and into the entire rest of the system. So you can hide from view other windows from the same app, or windows from other apps, or your messy Desktop. All of them just disappear.

I will say that I really discovered and relish the power of HazeOver most with a big screen. On a 13″ laptop, I just mostly use apps full-screen or nearly so, so the usefulness of HazeOver is limited. But on my 27″ iMac, I’m running the app like 90+% of the time. Only when I’m actively doing something where two apps being visible simultaneously is useful (like doing manual data-importing), do I not have HazeOver on. So I must encourage you to try it.

If you’re not into the legal complexities of “open source software” you can safely skip this. 🤓

But if you’re also kind of interested in the legal complexities of choosing different open source licenses, your interest may also be piqued by this little story from Justin Tadlock over at the Tavern. The short version is that there’s a small *philosophical* change that requires this re-licensing, but it’s more of the *practical* side of the equation that’d push Gutenberg to dual-license under the Mozilla Public License v2.0 as well as the GPL (v2).

I have to admit I’m not fully briefed on all the complexities, so I’ll keep my observations minimal. I think I support this change, but it does seem a loss for those (diminishing number of people) who are excited to see the GPL “virally” push all software to be completely open-source. The ecosystem around this has changed so dramatically in the last 20 years—remember those bad old times where we worried that Microsoft would be able and eager to crush free (libre 👩🏼‍🏫) software?—that I think a less-viral approach makes sense.

Anyway, there’s a lot more in Justin’s story and the underlying posts. So dig in if you’re more opinionated than me. Especially if you disagree with the thoughts in the prior paragraph, now’s the time to get involved ✊

If there’s one post I *always* read about the latest/upcoming WordPress release, it’s these “field guide” posts on make.wordpress.org. They’re a concise summary of the major highlights to keep an eye on.

You should take a look yourself, because different thing may be more important for you than for me. These features jumped out at me though:

• Allowing Admin users to force-send a password-reset link to a user
• They made a “Robots API“—fun name, and likely to be useful for SEO changes
• Lazy-loading iframes (img already do this) out-of-the-box
• A host of developer-focused changes
• And more Gutenberg changes than I can list

Most everyone in the WordPress world knows the basic image formats: use JPEGs for photos, PNGs for screenshots, and maybe WebP if you’re a Google-loving-hipster. Or at least, that’s my summary of the situation. (Some other playful/controversial opinions: .bmp is for dinosaurs who love MS Paint, GIF is a weird name we fight about for what should really be silent video files.)

I didn’t know a lot of the technical details of all those image formats. Nor had I realized that people were (maybe obviously) working on newer image formats. All that in more is the topic of this post over at Cloudinary from Jon Sneyers. His writing is fun, his biases are clear, and you’ll probably learn something about an important detail of the internet 🤓

I’m quite confident a lot of WPShout readers are doing at least a little bit of “client work.” Whatever way you do that—even if you don’t do it using WordPress—problems can crop up. Which is why I really appreciate this little article from Jennifer Bourn.

She covers a number of the facets of how to deal with conflicts that come up, including this thing that some conflict-avoidant souls (like me) may find a little surprising:

The good news is that client conflict isn’t always a bad thing.

Managing client conflict the right way can turn a negative situation into a positive one. Your response can solidify your position as leader of the project, reinforce your expertise, and build greater trust with your client. Plus, by addressing potential conflict immediately, you can salvage client relationships worth saving and end those that are toxic before they devolve into a situation that could harm your brand.

She goes on to enumerate ways you can handle conflict poorly, as well as some of the ways that you can healthily cope in a difficult situation. Definitely give it a read.

As a perennial CSS newbie (who kind of had skills a decade ago) I appreciated this short article from Robin Rendle about when (translation: how little) you should use the float: left that was so common when I last really did CSS.

To summarize, you can (and should) keep using float for what it is originally designed for: embedding small things like images inside of text which flows naturally around them. But all the other layout used people put them to for years? Skip it and that annoying clearfix stuff we all had to do.

The most interesting thing from the article—which Robin also seemed surprised by—is that haven’t actually need to do that clearfix stuff for a while, all because of a little property on display called flow-root. To learn just how that works, you’ll have to click through 🤓