Category: Articles (Page 27 of 258)

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

The Must-Haves of Our Skillset

July 13, 2020 / Tom

When I decided that I was going to commit the journey of my career to building solutions on WordPress, I was – at the time – all in. That is to say that HTML, CSS, JavaScript, PHP, and MySQL were at a place where I could stay involved with all of them and work competently down the stack as needed for whatever it is I was building.

But as both my family [and I] have grown and as WordPress has changed over the past half-decade (let alone decade), that entire perspective has changed.

Not just that, though.

I’ll Share My Code With Images

May 28, 2020 / Tom

For as long as I’ve been writing on this site, I’ve used a combination of syntax highlighting, GitHub gists, or code or pre tags to help share code relevant to a given post.

But the more technical articles I read and the more that I see we, as an entire industry, start to rely versus utilize tools of Stack Overflow and other sites, the more I wonder how much we really understand what we’re writing (or even care) so long as the end results just works.

This isn’t a commentary on how quickly we should ship something. Instead, it’s about how we solve a given problem while also truly learning what it is that we’re incorporating into our codebase.

De-coupling Domain Logic in WordPress

May 5, 2020 / Tom

Remember that WordPress uses the event-driven design pattern and although we often refer to actions and filters, the concept comes down to hooks. The flow of control through the program goes something like this:

Execute the program,
Whenever the program comes upon a hook (in WordPress, we’ll see do_action or apply_filters), iterate through all of the registered hooks,
Return control back to the program,
Execute until the end.

This isn’t completely different from the Publisher/Subscriber Pattern (or PubSub, for short) but there’s a key difference: The Event-Driven Pattern simply signals that something has happened and if there are hooks, they will fire. The PubSub Pattern will tell a registered subscriber to do something.

Anyway, back to hooks in WordPress. Keeping the two concepts of hooks that we have may be most easily done by thinking of them like this:

Actions are for doing something,
Filters are for processing data.

If you’re looking to approach WordPress development in an object-oriented fashion, tightly coupling your code to WordPress core by registering your classes via hooks to the core application is not a good idea.

In other words, don’t register your business logic with WordPress. Keep them separate. Here’s a litmus test for if your work is tightly coupled with WordPress: If you can’t run a unit test against your class without loading WordPress, it’s tightly coupled.

So what’s the solution? Delegation.

On Functions and Must-Use Plugins

April 28, 2020 / Tom

I’ve been working on a small project, more of a web application than a site, that’s required the development of both a custom-theme and tightly coupled, but very specific functionality.

This is a very narrowly focused project (about which I’ll likely talk about at some point in the future) but in working on it, it’s forced me to get back into the theme development aspect of WordPress development a little bit.

No, I’m not doing any design – thankfully – but I am having to work on theme customizations from a functional perspective. In doing this, though, it’s had me revisit the required functions.php and some considerations I’ve never had before.

Furthermore, it’s caused me to look more deeply at the use of mu-plugins and ask when they are necessary and why I haven’t used them more in the past (or even when one would truly need to use them).

So I’m going to wax poetic about that a bit.

TL;DR
Functionality tied directly to the theme and WordPress core goes into functions.php. Domain-logic that required by the entire solution to work goes in a must-use plugin.

Don’t Develop Development Tunnel Vision

April 23, 2020 / Tom

In previous posts, I’ve talked about the idea of focusing on an area and going deep rather than wide. This is personal preference, of course, but it’s mine, nonetheless.

Over the last year, though, one of the byproducts that I’ve found is the longer you stay in a given industry, the more common certain problems become. (This shouldn’t come as a surprise as this is precisely why we have design patterns.)

But the thing about doing this is that you develop a sort of tunnel vision for ways to solve problems.

Case in point: Recently, I was tasked with needing to develop some functionality that was going to parse markup and convert it into a slightly different format.