Tom McFarlin | Practical WordPress Development

Installing Xdebug, Part 2: The IDE

August 16, 2018

Now that Xdebug is installed with your local installation of PHP, it’s time to wire it up to the IDE. This provides us with all of the advantages that Xdebug has to offer.

Installing Xdebug

That is, it allows us to:

set breakpoints,
step through our code,
and watch variables

All the while the program is executing. This means that while is a page is rendering, we’re able to set points in our codebase where we can see what the server is doing with our code.

So, sure, even though it’s called debugging to remove bugs, it can also give insight on how a WordPress-based application, theme, or plugin is executing and can help us gain a better understanding of WordPress core.

Organizing WordPress Types, Views, and Subscribers

August 15, 2018

One of the things that I find myself trying to do on a regular basis is to streamline how I’m building WordPress-focused functionality. I’ve recently talked about this but thought I’d expand on it a little bit more.

That is, I thought I’d lay out the approach I take when building things such as custom post types, taxonomies, meta boxes, and so on.

Generally, think of this as a strategy that I follow for building out aspects of a project that interfaces directly with WordPress but may require a few components such as:

classes that register themselves with WordPress through various hooks,
classes that require calls to certain WordPress APIs
and classes that require a custom view.

Sure, not every thing that interfaces with WordPress will need all of the above (for example, does a custom post type need a view? No. But a meta box does.)

On Writing Readable WordPress Functions

August 14, 2018

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

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

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.