One of the first and most powerful lessons I learned while teaching myself to code a decade ago was to read/listen/watch widely. I believe it is one of the most powerful choices you can make in learning to code (or in almost any endeavor). Because broader minds (ones which have been exposed to more things) are often *way* better problem-solvers than narrower ones. Because the solution space they can conceive is just so much bigger. But that’s enough “David’s Life Philosophy” for now.

The reason I’m going on about that because it was precisely this same lessons I saw when reading this nice little essay from Justin Tadlock over at the Tavern. I think the specifics of Justin’s story are both useful and interesting too. But it was his close that meant I had to share it with you:

Another benefit of working with other platforms from time to time is that you learn ideas that you can bring back into the WordPress ecosystem. For example, it is interesting to see how the Sage starter theme implements Laravel Blade’s templating engine. These ideas can help shape WordPress’ future.

Some ideas can be pushed into core WordPress. Others can improve team workflows within agencies.

Continuing education benefits the WordPress community as a whole. Don’t limit that education to WordPress-specific ideas. Learn from the outside and bring it back.

The first WordCamp Asia, scheduled in Bangkok from February 21 through February 23, has been canceled due to COVID-19 fears.

It’s an unfortunate start to what will be an amazing WordCamp Asia tradition, but there’ve been a lot of silver linings, including WordFence, Yoast, GoDaddy, and ServMask each chipping in $10,000 to help with airline and hotel change fees.

In general, from my distant vantage point (and drawing mostly on coverage in the always excellent Post Status newsletter), the logistics and decision making around the cancellation seem to speak highly of WordPress as a global community, idiosyncratically organized but quite functional and tight-knit.

Can’t wait to see everybody in 2021!

Our friend Carl Alexander wrote a (possibly) inflammatory but true argument for Delicious Brains this week. It reflects a lot of thoughts I’ve had as I’ve spent the last few years as one of the small minority of people trying to span the roles of  “WordPress” and “modern PHP” developer. In short, he’s said all I’ve thought in a fair, even handed, and useful way. While action is hardly guaranteed, helping to reach a public consensus about the state of WordPress PHP is the first step in evolving toward making it a modern PHP project (if that’s ever desired by enough of the right people, of course).

Here’s maybe the most important (to me) of Carl’s many good points:

Part of the reason for that is WordPress is a legacy application. The WordPress project itself is more than 15 years old, but it’s also a fork of another project called b2/cafelog. This was an open source project that had already existed for a few years before Matt and Mike decided to fork it. So all things considered WordPress is a lot closer to 20 years old.

Working with software that old brings unique challenges. Case in point: Your development practices tilt towards not keeping up with what others may be doing in the industry. This is especially true with WordPress. That’s because the PHP ecosystem wasn’t at all like it is now when the WordPress project started.

I’ve got a client with a custom nav menu link pointing to a third-party service. He wanted that custom link to open in a new tab, and I realized I didn’t know how to do it.

Fortunately, opening a menu link in a new tab is easy, and it’s available in WordPress core—no plugins or custom code required. The linked article gives a perfect visual guide to it.

The solution is interesting for a couple of reasons:

1. It’s another of many examples where something perfectly easy is hidden thanks to the “Screen Options” interface.
2. It’s an example where something useful is available through the backend Menu interface, but not the Customizer menu interface.

As a last thought: in my understanding, hardcoding “open this link in a new tab” is not great for UI/UX generally, since you’re making a decision for the user—proliferate tabs—that she should either be able to make herself (if she knows her browser), or that she may not want made. It’s a gray area, but just saying, don’t go crazy.

In 2020, Fred and I are prioritizing featuring writing from people other than ourselves on WPShout. If you’ve got an urge to write clear, useful, and interesting technical tutorials for the WPShout audience, this is the perfect opportunity for you. We’re still locking in all the details, but in short it’d likely be at most an article assignment per month, where you’ll write about 1500 words (ideally with some code snippets 🤓) about your favorite things in WordPress adjacent code.

Especially qualified candidates will help us write great tutorials on many different things, but we’re especially looking to get more great content about how to build your own Gutenberg blocks and how to make it into the page-builder of your clients dreams.

A few quick details to clarify here: this is *paid* writing work. And we’ll follow up with qualified candidates within a few weeks. We look forward to hearing from you!

Lazy-loading images is one well-known win for site speed, and at present if you want to implement it in WordPress you have to choose among one of many subtly different plugin options.

It now looks like WordPress 5.4, due out in March, may include default lazy-loading for all images.

I think bringing lazy loading into WordPress core as a “by-default” behavior for images is a really cool idea. To tell the truth, I couldn’t name the most recent changes to WordPress since 5.0, but default lazy loading seems like a really great and sensible win for site speed. Lots more detail in the linked article.

If there’s one problem that developers have with the WordPress.org Plugin (and Theme) directories, it’s most likely to be that the process of deploying the Subversion repositories used by that site is annoying, complicated, and cumbersome. I’ve been looking for a solution for a while, and this (pre-Christmas 🙃) post from Helen Hou-Sandi has me really excited for 10up and Github’s new “Actions” feature.

What they’ve released (best I can tell) is a simple quick way that I can deploy a update to a WordPress plugin right from a Github repository. And without maintaining my own set of small shell scripts which is supposed to make it easier to do. I have to admit it’ll likely be a few more weeks before I try these out, but I’m really hopeful that they’ll be the WordPress.org deployment story of my dreams. ☺️

They found a security vulnerability in the Elementor plugin. It’s patched in the newest version of the plugin, so if you use Elementor, please update to the latest version as soon as you can. (And if you happen to be nervous about updating stuff, this week’s article is perfectly timed.)

This sort of security issue could probably happen to any plugin—and, anecdotally, it seems to be happening more and more often in the WordPress ecosystem—but if you’d like to be persuaded to switch to Beaver Builder, check out our comparison of the two plugins.

I’m really excited to know that Cory Miller — you may know from a year of running a company called iThemes — is joining Brian Krogsgard at Post Status. While you might not know, Brian is one of the quiet pillars of the WordPress community. While he hasn’t always had everyone’s ear, he’s always had the attention of some of the most important people in the WordPress community.

While they aren’t really announcing new plans (but they had a great conversation which is the bottom of that post), they’re clearly both excited to work together and work in the WordPress community. And the energy of two selfless, trustworthy people combining for the first time is truly very very exciting. To many more, Brian and Cory! 🥳

If you’re still hesitant to learn CSS’s Flexbox module, today’s the day. This Flexbox guide from CSS-Tricks is so beautifully clear and so visual that, in my experience, Flexbox almost learned itself—you just need to point your open eyes toward the screen.

What is Flexbox good for? I use it for all kinds of “multi-column” needs where I used to have to use float, inline-block, or other side-effect-ful solutions.

It’s 2020, and Flexbox is now well-supported by all browsers that aren’t The Villain, so give it 20 minutes and see what you pick up.

I really appreciated this list from Callie West of conferences for 2020 that may be of interest to WordPress developers. While I trust that her list isn’t exhaustive, it does cover all the big conferences that were on my mind for the year, and a few I’d never heard of. Which means her list is doing its job absolutely perfectly.

In summary you should check out this list if you’re interested in seeing the major conferences in these buckets:

• WordCamps
• JavaScript conferences
• Laravel and PHP conferences
• CSS confs
• UX, development in general, and more

If any of those interested you, please give the article some love. She also finishes with some advice for those of you who might have to convince a boss to help you pay for a conference trip 🙂

Among the most difficult challenges in WordPress development is finding out where a piece of code actually lives. Up to two themes and infinite plugins could be hooking into any part of WordPress and changing things, and if you want to track down a specific change it’s often the most time-consuming part of an otherwise easy job.

This week, I found out about a cool plugin that lets you do a string search of anything on your WordPress filesystem—one theme, one plugin, all themes, all plugins, the entirety of wp-content, and more. I tried it out and it works as advertised. It’s the WordPress filesystem equivalent to the visibility a plugin like Better Search Replace helps provide into the WordPress database.

I wouldn’t rely on either plugin as infallible (I’m not sure if Better Search Replace can find serialized data, for example), but they’re a much better place to start than poking aimlessly around themes and plugins and trying to read a previous developer’s mind.

I really enjoyed reviewing this post from Steve Burge over at PublishPress (whose plugin we recently published a Quick Guide about). What he covers is the dream of Google Docs-style collaboration in WordPress’s native post editor. As he highlights, this is something that Matt Mullenweg has kind of committed the WordPress project to, and a great feature for us all if/when it arrives.

But what I really value about Steve’s post is that he’s honest and clear about the likely timeline and reviews some of the complications and related projects. As an example, he doesn’t think this is likely to be done very quick…

In terms of timeframe, I don’t expect Phase 2 of Gutenberg (“Customization”) to be complete before the end of 2020.

So that means that Phase 3 of Gutenberg (“Collaboration”) won’t be the main focus until 2021. Given that schedule, and the steep technical challenges, it’s almost certain that collaborative editing will not arrive in WordPress until 2021 at the earliest.

While it may sound pessimistic, I share Steve’s vision of the most likely timeline. The feature will surely be worth the wait, but it’s probably best if we expect a wait. 🤓