There are lots of people who can help you understand Git. Some of them are quite exhaustive, like Dan Gitcodeschooldude (who I covered here). His free video tutorials are great. But they’re also unequivocally not a cheat sheet. They’re essentially in-depth tutorials that will give you incredibly deeper understanding but require sustained focus.

Oh Shit Git (whose punctuation is unclear to me, and ultimately doesn’t matter) is the opposite. It’s a single-page guide to some of the most common and frustrating problems that a Git user is likely to face on a day-to-day week-to-week basis.

And it’s just really well named. Once you know that Oh Shit Git exists, you’ll always remember it. And when you need what it does, you’ll think to pull it up. Just like I always do with wphierarchy.com.

Great reporting and case studies from the Tavern.

This is a great good-news Gutenberg piece, and some great reporting from Sarah at WP Tavern: Sarah looks at some of the newest Gutenberg innovations, and how they’re coming from theme shops who, having typically diversified into plugins in recent years, are perfectly placed to mix design and functionality with new Gutenberg blocks.

We will see a really dominant go-to “extra Gutenberg block plugin” in the near future, and it’s exciting to see all the various offerings come about as various groups try various things. Watch this space!

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

Toni Morrison on doing your best creative work

I really enjoyed this short interview with author Toni Morrison on her daily routine. None of this is overcomplicated, as is often the fashion; instead, it’s what allows her to do her best work:

“I tell my students one of the most important things they need to know is when they are at their best, creatively. They need to ask themselves, What does the ideal room look like? Is there music? Is there silence? Is there chaos outside or is there serenity outside? What do I need in order to release my imagination?”

This link was shamelessly borrowed from Jocelyn K. Glei’s beautiful newsletter. 

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

Great little guide from Mike at WP Bullet about how to figure out, using WP-CLI and grep the options that are related to a specific WordPress plugin. There’s nothing here that surprised me. And I’ll not that you can do effectively the same thing using any interface to the database data, including something like phpMyAdmin.

That said, this tutorial does a good job summarizing the basics of using two different tools you might not be completely familiar with for the sake of making progress on a specific goal: finding all the database value that came from a specific plugin. Because of the brevity of the tutorial, you’ll want to have a passing familiarity with the Unix command line before diving in, but with that you’ll be set to quickly understand and use the information. 🙂

I first wrote up Relevanssi back in 2015, when it saved my bacon on a client project. Last week it did the same thing again, and I remembered why I’d found it so cool in the first place.

Relevanssi is true to its subtitle: “A Better Search.” It overrides WordPress’s default search to also search custom post types, custom fields, and lots more, in a manner you specify and can easily change.

And here’s where Relevanssi came in clutch last week: It’s got a lot of great extensions, one of which, Autocomplete for Relevanssi, adds great out-of-the-box autocompletion to the WordPress search form.

Relevanssi and Autocomplete for Relevanssi are a plugin and an extension done with a lot of care and intelligence. Kudos.

Obsessively tracking detail

I enjoyed the almost obsessive attention to detail in this post, from an engineer who’s been tracking a set of data on day-to-day happiness. The analysis is interesting for its self-introspection, and willingness to ask mildly uncomfortable questions around working, not working, and finances etc. Certainly a good read for getting some ideas.

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

I really appreciated this article from Carl Alexander about getting better at developing WordPress plugins. When most people (myself included) first hear about unit tests, you want to go set all old code on fire. But you can’t do that, so Carl offers some practical advice about how to incorporate testing practices into places where you’ve not historically been doing it. For most of us in WordPress, that’s everywhere.

Here’s a clip:

Start by unit testing bugs

One way is to create unit tests for every bug that you fix. This is a common recommendation by a lot of developers that promote unit testing. They see it as a great way to get into unit testing for two reasons.

I really loved this talk from Lara Schenck. Part of that’s because I love to have abstract technical conversations about things like “What is a programming language?” and “What even is life?” Part of that is just because she does a great job covering a complex topic with a fun touch on a touchy topic.

People get very upset about questions like “Is CSS a programming language?” I’ll leave my opinions about why *cough*ego protection via out-grouping*cough* aside, and just say that it clearly is and Lara makes the case concisely and clearly.

But you shouldn’t really watch the talk for that answer. You should watch it because if you’ve never taken a computer science class (that’s me!) you’ll certainly learn something and have some fun doing it. I recommend highly that you give it a watch.

The three of us (Alex, David, and Fred) had the pleasure of being on last week’s WP Tavern podcast. We discussed what we’ve learned about teaching and learning WordPress development, and why we believe the WPShout Pro Community solves learning challenges that nothing else quite addresses.

Jeff and John were a delight, as always, and we really enjoyed seeing how their minds worked with the idea. If you want to know why we’re so passionate about the Pro Community, this is the podcast for you!

Notes on working deeply in a remote team

Long-time readers will remember in 2016 I had a post, Deep Work in practice, hit the front page of Hacker News and enjoy fifty thousand or so visitors. That post discussed the idea of “Deep Work” and how to actually do it in practice (something the otherwise very good book of the same name is light on).

This post touches on similar themes, looking at how we do Deep Work in practice on the Ellipsis team, which has gone from just me to a team of three! We look at the what, the why, and the how. All three boil down to creating a remote work culture that’s really nice to work in, and project management system that supports you doing your best work rather than gettings in the way.

This is a fantastic philosophy of how to work effectively in the modern knowledge (WordPress) economy, so whether you’re looking at your own workflow or you happen to run a remote team, I’d definitely give this a read.

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

In one of the least-relevant-to-WordPress articles I published there, I recently covered the difference between an active record ORM system vs one using the data matter pattern. ORMs are essentially systems by which PHP (or any language) objects are stored-to and retrieved-from the database.

Why this isn’t particularly relevant to WordPress, is that WordPress has no ORM. It has a global database object, $wpdb and a host of functions that read and write values to the database. But that’s about it as far as ORMs go. (There’s more about $wpdb in this article, if you’re looking. 🤓)

So why share it? One, self-promotion. (Also, I just did an economic analysis of my coffee habit. 😝) But, two, I think one of the long-standing deficiencies of the WordPress ecosystems especially with respect to development practices is a sort of insularity with respect to learning and talking about concepts above-and-beyond WordPress. Understanding what ORMs are and how they work makes one a better developer. Full stop.

I don’t think WordPress needs an ORM. I don’t think that you should write your own ORM for your plugin (although that’s a reasonable idea at a big-enough plugin-scope). But I do think you should know about and be conversant in this (and other) common application pattern if you’re going to be the best possible WordPress developer.