Page 75 of 428

On Writing Readable WordPress Functions

August 14, 2018 / Tom

One of the things that I find consistently interesting (both from a programming standpoint and from a WordPress standpoint), is this:

I like keeping code separated such that code responsible for interacting with WordPress is relegated to its namespace while the rest of our code is namespaced appropriately elsewhere.

I think this is obvious, though.

When it comes to writing code, though, this doesn’t mean it has to be left simply to the how we write our classes and then organize them. What about things at a slightly more granular level?

That is, what if we were to look at methods as part of the larger whole and make sure they’re doing their job well, too? Sure, people like Bob Martin have been writing about this kind of stuff for the majority of their career and preaching it to people like us.

But these concepts are something that you simply start doing and then apply them for good. Paradigms shift, we’re better today than we were yesterday, and there may be multiple ways to achieve the same kind of thing.

So when it comes it comes to creating readable WordPress functions for a specific domain, what might that look like?

A Simple Guide for Organizing WordPress-centric Classes

August 9, 2018 / Tom

One of the things that I’ve been making a much more concerted effort, likely more so than I’ve ever done before, is managing separation of concerns between the classes responsible for interfacing with WordPress and those responsible for working with the problem domain.

For instance, let’s say that you’re working on a plugin and it’s going to communicate with a third-party API. Additionally, this plugin will also offer menus, post types, taxonomies, and so on within the WordPress administration area.

There are two areas of responsibility here:

the area responsible for generally solving the problem,
the area responsible for interfacing with WordPress.

You can make the case that it’s important to unit test areas that communicate with WordPress, but I also know these are tried and true APIs that have their own set of tests.

Instead, we should be focusing on unit testing and separating our business logic away from WordPress.

But that’s not the point of this post. Instead, it’s more about a way to potentially lay out a project when a portion of it will be interfacing with WordPress.

Installing Xdebug, Part 1: The Xdebug Module

August 8, 2018 / Tom

By now, we’ve covered a lot of ground as it relates to working with WordPress and debugging. And this is especially true as it relates to working with tools and plugins available within WordPress. If you’re just joining this particular series, please make sure you’re caught up with the following posts:

In the previous post, recall that I said the following:

But if you’re looking to get into the world of professional, practical debugging from within your IDE, then it’s important to understand the what, how, and why.

And we’re finally ready to look at what this requires. To get started, however, means that we need to understand a few things about Xdebug, the terminology, and to have an IDE that’s consistent for everyone reading this particular series.

Installing Xdebug

So this is going to be broken into two parts.

First, we’re going to look at the terminology required for debugging and make sure that we have a proper IDE setup in our development environment,
Next, we’re going to look at how to ensure we’ve properly installed Xdebug and then wiring it up to our development environment so we can put it to work.

If you’ve read a variety of content throughout this blog over the past few years, some of this may seem familiar. If not, no big deal. Remember the goal is make sure we’re all on the same level as we proceed forward with the work mentioned above and throughout the rest of the series.

With that said, let’s get started.

Project Size and “Keeping It Simple”

August 7, 2018 / Tom

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).

Basic Debugging Within WordPress

August 2, 2018 / Tom

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.

Tom McFarlin

On Writing Readable WordPress Functions

A Simple Guide for Organizing WordPress-centric Classes

Installing Xdebug, Part 1: The Xdebug Module

Project Size and “Keeping It Simple”

Basic Debugging Within WordPress