Software Engineering in WordPress, PHP, and Backend Development

Category: Articles (Page 105 of 258)

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

Setting Up MailCatcher for MAMP and WordPress

Though it’s been around longer than Local (or previously Pressmatic), MailCatcher was brought to the attention of many WordPress developers.

MailCatcher, MAMP, and WordPress: MailCatcher

In short, it makes it easy to start monitoring local development emails sent from WordPress. And if you’re someone dealing with templates, email customization, and more then you know how tiring it can be to tweak, send, tweak, send, and repeat.

If you’re not using Local, it’s still possible – and easy – to set up MailCatcher. And if you do a lot of work with anything that deals with WordPress emails (especially in eCommerce), then I think it’s worth setting up.
Continue reading

Reasons For Not Writing Unit Tests

When I had my first internship, I was tasked with maintaining a legacy ASP application. This included everything on the front-end, through the application layer, using Visual Basic and VBScript, as well as the database that was primarily used as a datastore for XML.

What are interns for, though, right?

I’m kidding: I actually like the idea of having junior programmers work on maintenance tasks or bugs at first to get a feel for where things are (or were) before jumping into where they are headed.

At the same time, I was also learning and reading a good bit about unit testing. It was past the time when it was “the hot new thing,” but it had hit a point where a lot of people were talking about it.

It was finding its way into day-to-day conversations. It was becoming part of the curriculum of any software engineering course or material that any software engineer should know. It was coming up in interviews, conversations, blog posts, books, and so on.

In short:

It was becoming impossible to escape.

Either you knew how to unit test, you knew TDD, or you didn’t.

  • if you didn’t, then you might get an SMH from a potential employer,
  • you might get a condescending comment from a peer,
  • or you might get roped into a conversation covered in sheer excitement from that guy over in the cube over who’s been aiming for 100% code coverage since the company rolled out the testing infrastructure.

I’m not bashing testing (because I think it has its place and I think we need to know how to write them) and I’m not downplaying having a significant level of code coverage in a given application (because it is important).

But the amount of testing can be done is also related to a handful of others things that programmers don’t often seem to discuss: time, budget, and [optionally] pragmatism.

This post is already getting longer than what some of us like to read (are you reading this sentence, even?), so I don’t wax poetic about this for too long but if you have the time, entertain me.

If not:

The point that I’m ultimately working towards is that I don’t think it’s always as simple as basically “just write the damn unit tests.”

There are other things at work beyond just that each of which influences what we’re doing.

Continue reading

Using Namespacing and Autoloading in WordPress

It’s not hard to find criticism about namespacing and autoloading in WordPress, and lack thereof. As much as I’d like to see it, I think it’s important to take a practical look at the software as a whole, the requirements, and realize that implementing such organization would require a lot.

Specifically, it would require applying object-oriented programming throughout the entire codebase (which would last longer than a release cycle in and of itself).

It would also require that all hosts who support WordPress on any level (yes, even those supporting legacy versions) can handle the new features.

In short, it’s not an easy task and it’s important to recognize the practical challenges that come with doing so in 13 year old software powering approximately 25% of the web.

It’s not that it can’t be done, that it won’t be done, that people don’t want it done. But it’s requires exceptional planning, execution, testing, and support from a wide array of situations that I don’t know if I can even fully grasp.

With all of that said, though, this doesn’t mean that we can’t use namespaces and autoloading in our WordPress projects.

Continue reading

WordCamp US 2016, Post Status Publish, and Instagram

This post is going to be weird:

It’s a deviation from my normal content, it’s going to cover WordCamp US 2016, an event prior to that, and social media.

I said it was weird. But hang with me.

I’m not an avid user of Instagram in that I don’t really, you know, post pictures or anything like that. At least not right now.

I have, however, been using the story feature a little bit (much like Snapchat but without the absolutely terrible UI and pathetic stories shared by “news” outlets).

It’s also fun to follow along with those who do share photos and stories. I just don’t have that much to share given that I work out of my house, live in my house, and generally hang around my house during the week.

Continue reading

Buffering WordPress Content with PHP

I know: If you’ve been working with WordPress for any amount of time creating themes or plugins, then you’re probably familiar with filters. Even if you’re not really sure how they work, you’ve likely worked with something like the_content.

And by that, you’ve likely written a line of code that looks like this:

It’s enough to work with, too. Usually, this is used whenever you want to modify the content before sending it to the browser to render.

But I recently had to work with it in a somewhat unusual way that required the usual of this filter, a template file, and PHP’s output buffer such that I was buffering WordPress content.

Continue reading

« Older posts Newer posts »

© 2026 Tom McFarlin

Theme by Anders NorenUp ↑