Project Size and “Keeping It Simple”

For whatever reason, there is a consistent tension that exists (at least as far as I’m concerned) between the utility of building something for someone and the amount of time it takes to build the said thing.

By that, I mean that when it comes to WordPress, it’s relatively easy to build small, simple plugins and utilities for others that aren’t necessarily following whatever the modern best practices are.

And, as for this post, I’d say that the modern best practices are something like:

  • a server-side package manager,
  • a client-side package manager,
  • proper unit testing,
  • well-designed classes,
  • documented code,
  • and so on.

And all of that is great and arguably necessary for larger projects (especially because maintenance and consistent development are going to play such a significant role).

Read More

Basic Debugging Within WordPress

As we continue to head towards working with direct debugging with Xdebug, we have a few tools at our disposal that allow us to work within WordPress itself. These aren’t meant to be replacements for any other debugging tool, but compliments to them.

I began by discussing this in the previous part of the last series. Specifically, I wrote:

Now though, we need to turn our attention to the plugins that were discussed a few posts ago. After that, we’ll eventually be working our way up to Xdebug.

But next, we’ll look at the tools available to us from within WordPress itself.

Ultimately, the goal is to look at what’s available for us to use to find problems, test code snippets, and profile our work. And several plugins make this incredibly easy (and are quite powerful) as it relates to doing just that.

Read More

When CloverCoverage Fails And Passes Simultaneously

I’ve talked about the advantages of using GrumPHP in previous posts. One of the tools that we’ve used in projects for the last year or more is Clover.

Photo by Quentin REY on Unsplash

Some time between when we started using it and this week, it would always fail to execute every time on my local machine but not on the machine to which we were deploying our code.

And no, it wasn’t because there were incorrect directives or comments in the unit tests and it wasn’t because PHPUnit was misconfigured (it was executing all of the tests and reporting them as expected).

So what gives?

Read More

The Basics of Action Hooks in WordPress

Anytime sometime starts to get into more advanced programming – be it in WordPress or any other framework, library, foundation, or programming language – there are times in which new concepts can often be more difficult to understand than others.

I generally have found this to be true whenever a person has learned the basics of, say, object-oriented programming but hasn’t been exposed to the nuances of certain things such as design patterns.

Case in point: I’ve written about the event-driven design pattern (or the publish-subscribe or Pub/Sub as some like to refer to it) in other posts.

Yes, there are some differences to each, but the general idea is that something happens and an event is raised and anything listening for that event, or subscribed to that event, will respond.

Action Hooks in WordPress: Pub/Sub

Photo by Claus Grünstäudl on Unsplash

This is the primary pattern that WordPress employs that allows us to quite literally hook into certain points of execution. We can generally conceptualize these as action hooks in WordPress.

Anyway, the application makes certain points available for us to add our own functionality. Once that functionality is registered, WordPress will leave its codebase, so to speak, hop into ours, then return back to ours.

It’s easy enough to understand, but what if you want to expose areas in your code that allow others to hook into your code?

Read More

Developer Fitness in 2018: Quarter 2

Apparently, with the exception of my previous post, this is turning out to be my week to share things related to the second quarter of this year (the first being about taking some time off of social media).

Earlier this year, I talked a bit more about why I think it’s important for we, as developers who spend so much time at a desk, to focus on our health as well. Granted, this is has been compeltely focused on my own goals.

Specifically, I said:

The purpose of this post is to go a bit further into what my goals have been first the first quarter of the year, what I’m aiming to do in the second phase of the year, and some additional thoughts on the devices I’ve been using.

But this doesn’t mean it can’t translate into your own life in some capacity, right? I’m the last to say that “what works for me will work for you” because I think our body composition plays a massive role and we’re all different.

Anyway, if you’ve not read what I’ve written thus far, check out these posts first (if you have the time):

  1. Developer Fitness: Getting & Staying in Shape
  2. Developer Fitness: More Progress, My Devices, Apps, and What’s Next
  3. Developer Fitness in 2018: Quarter 1

Even though I’m a bit later than planning for writing my second quarter retrospective, here it is, nonetheless.

Read More