Software, Development, and WordPress

Category: Articles (Page 1 of 243)

Personal opinions and how-to’s that I’ve written both here and as contributions to other blogs.

There’s More to WordPress Than FSE and Headless

I don’t know if this is just me, but at the time of this writing I think that those who work with WordPress for a living – usually those described as being part of the “WordPress Community” – can be grouped into primarily two camps:

  • those who are focused on React for the Block Editor and Full-Site Editing (or FSE),
  • those who are focused on Headless WordPress specifically with technology like Next.js

That’s good because we know that we’re going to eventually have the Block Editor and FSE working together and we know the Headless ability of WordPress allows for an array of solutions that can be built using alternative front-end technologies.

Based on newsletters, tweets, blog posts, podcasts, and all of the other way media is shared for the application, though, I think we’re also forgetting the fact that WordPress is far more malleable than FSE and Next.js or, more simply put, locked into having React be the primary thing on which we focus.

Continue reading

Using GrumPHP, Composer 2 and PHP 7.2

I’m very much a fan of GrumPHP which I’ve written extensively about in previously posts.

And as my last past alluded, I’ve been adapting a piece of software so it maximizes its availability across all platforms using PHP regardless of now new or how old the platform is (at least between PHP 7.2 and PHP 8).

Here’s the thing, though: If you’re working with an older version of PHP then you’re going to need an older version of GrumPHP and if you’re going to use an older version, you may need an older version of Composer.

Except maybe not!

Continue reading

Installing Old Versions of PHP With Homebrew

I love the speed at which PHP is moving these days and how fast the new versions are, too 🙂 but that doesn’t mean the software on which we’re going is going to consistently be able to keep up with the fast release cycles.

And that’s okay. It is part of software development and it has been since before most of us were writing our first lines of code (let alone before we were even alive). Obviously, this means that those of us who work with PHP are likely going to need to work with different versions.

Sometimes we’ll be working with the latest, sometimes we’ll working with a version or a few versions older, and sometimes we may need to work with something that’s deprecated.

And this is usually the part where certain engineers start saying we should upgrade all the things and stay with the newest version of languages and frameworks. But that’s not how it works.

What does this have to do with PHP, though?


Assume for a moment that you’re working on a project that was written with 8.0 but you start rolling it out to a suite of products. Some are running on a server with 7.4, some are running 7.3, and some are running 7.2.

Is it easier to handle all of the other software already running on their servers or refactoring your code?

A bit of a rhetorical question.

Continue reading

The Idea of Boxes for Multiple WordPress Projects in One Installation

When working with multiple WordPress installations – that is, having to manage an array of wp-content directories for whatever it is you’re working on, it seems that it’s more often not common to suggest creating a new WordPress installation for each project.

This isn’t something necessary assuming the nature of your work can operate off of a single database and the same version of WordPress. This may or may not work for multi-site projects; I don’t deal with them so don’t count on this as being applicable.

Continue reading

Keep a Journal of What It Takes to Get It Working

This is not new information and this is not a new idea that you’re about to read. This isn’t a novel idea. This isn’t something that no one has ever discussed. This is the furthest thing from a new idea.

Instead, this is me re-iterating something that people in our field talk about over and over and over. It bears repeating though because it still comes up again. And with good reason: It’s a good reminder that we should be doing this.

We should be keeping a journal of the work we do. Really.

UpNote is a good app for this.

I don’t mean a blog, as much as I think they’re important, and I don’t mean Twitter threads, I don’t mean comments on Hacker News, and I don’t mean Stack Overflow questions or answers.

I mean text files or markdown files or HTML files or whatever it is you want to use. Here’s why: The longer you work in software, specifically on the web, the more likely you’re going to encounter all sorts of other software required just to get The Thing™️ working. And the less likely your exact situation is identical to someone else’s.

Sure they – or you – can say “Have you tried [doing this]?” or they can recommend “Upgrade [this particular package]?” or “Bypass [this particular dependency] because it’s likely not needed.”

That still leaves a lot of unknowns. They are suggestions.

Continue reading
« Older posts

© 2022 Tom McFarlin

Theme by Anders NorenUp ↑