I Don’t Know if Social Media is Good

Though I try to keep the topics on this site strictly limited to development of all things WordPress (and related technologies) that doesn’t mean I don’t sometimes venture out into more personal things (such as taking time off of social media).

Usually, I find taking time off of these services helps me to focus on some different things, reflect on whether or not I like them, what they offer us as a whole, or simply take a break from the things social media brings with it.

But one of the things I’ve found myself thinking about over the last month – and not necessarily on purpose, but it’s something that’s emerged the longer I’ve spent offline – is the place social media holds in our society (I guess western society, as I’d categorize it for this post), and the role in plays in each of our lives.

This post is going to run down a list of thoughts I’ve had about it, though they don’t necessarily have a firm conclusion or even a place I’m trying to get everyone to agree on (which would be a fools’ errand, anyway).

Instead, this is my general thoughts, observations, and considerations on social media as it exists at the time of writing this post.

Maybe it resonates with you, maybe not.

Read More

Installing Xdebug, Part 2: The IDE

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.

Read More

Organizing WordPress Types, Views, and Subscribers

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

Read More

On Writing Readable WordPress Functions

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?

Read More

A Simple Guide for Organizing WordPress-centric Classes

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:

  1. the area responsible for generally solving the problem,
  2. 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.

Read More