Software Engineering in WordPress, PHP, and Backend Development

Category: Articles (Page 127 of 258)

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

Beginner Resources for JavaScript and jQuery

This month, I published two articles on Envato about resources for JavaScript and jQuery.

For those who get involved in a form of development – be it back-end, front-end, or some other type of developer – we end up forgetting what it was like not to know how to do so something. It’s kind of like riding a bike or swimming, right?

We may remember when we learned, but how much do we remember about losing our balance or not knowing how to keep our head above water?

And that’s what I think it’s like to be on the outside of a programming language, how it interacts with third-party components (like the browser or the filesystem), and how the language is structured.

Because of that, I think it’s important to publish resources periodically on topics like this for those who are looking to get started.

Continue reading

Side-Stepping the WordPress API

When first getting into programming or when first getting involved with a particular language, one of the most common questions new developers ask is:

What’s something I can build?

And it’s a good question, isn’t it? I mean, anyone who is involved in programming has been in that position before: We’ve learned enough of a language to be dangerous, we’ve worked through all of the provided examples, but we’ve got no idea what else to build.

There are some things we can reference for other developers to try and create:

  • Take a look at one of your favorite programs and try to recreate it.
  • Attempt to create one of your favorite features of a given program.
  • Study some open source code from one language and try to recreate it in your language.
  • And so on.

All of these examples are fine, but what happens when you’re a little more experience with both a language, a framework or foundation, and you have to work to make something happen, and you’re not quite sure how to do it in code?

That is, you can explain it at a high-level and perhaps even diagram it out on a piece of paper using a data structure or something similar, but you aren’t familiar enough with the core foundation or framework for how to do something.

What do you do then?

Continue reading

The Tension of Refactoring Legacy Code, Part 3

The last two posts have talked specifically about what it’s like to work specifically on refactoring legacy code whether it be something that we’ve previously worked on or something that we’ve inherited from someone else.

  • In the first post, I talked about the idea of “leaving the campground cleaner than you found it” which is the Boy Scout rule applied to programming.
  • In the second post, I talked about getting a bit reflective about the choices we’ve made as it relates to some of the code we encounter in our work and how it can affect our self-confidence or our ability.

And though I think there’s more than can be said as it relates to this topic (I mean, it has the potential to be a very long discussion, doesn’t it?). I want to shift gears a little bit and talk about what it’s like to try to more modern code on top of what’s essentially a legacy application.

Specifically, I want to share a few thoughts on what it means to write code (that will likely need refactoring at some point) on top of WordPress.

Note: This post ended up being much longer than I anticipated, but I hope you read it in its entirety, enjoy it, and feel free to comment on it, as well.

Continue reading

The Tension of Refactoring Legacy Code, Part 2

In the previous post on refactoring legacy code, I talked a bit about the challenges that we face not only as WordPress developers but as programmers in general as it relates to working with legacy code.

The short of it is that I believe we want to make sure the codebase is as optimized, clean, and well-organized as possible. But the reality of a project prevents us from doing this.

Deadlines can prevent us from refactoring legacy code.

Perhaps it comes in the form of the team we’re on; perhaps it comes from deadlines that are looming, or perhaps it comes from something else.

Whatever the case, we’ve established that a tension exists. And though I’ve talked about some general ideas as to how to deal with it, I haven’t really talked about my own experience in doing so.

Continue reading

The Tension of Refactoring Legacy Code, Part 1

In a post last week, I talked about various problem spaces that exist in WordPress, but I also briefly touched on the idea of practical applications as it relates to writing WordPress-specific solutions.

Specifically, I made the comment (more or less in passing):

When I was in school, I had to take a class in Computational Theory. For the most part, I’m more of a fan of practical application, but I know that much of said practical applications are the concrete implementations of proven theories.

And then I went on to talk about more theoretical topics as it relates to solving problems in a given computing space (for us, that’d be WordPress).

Computational Theory

Since I spoke about the previous topic at this particular level, I thought it might be fun talk about a more accurate or more practical approach to writing WordPress-specific software.

Recently, I’ve been working on a codebase that’s a few years old. The desire to want to refactor the whole codebase is strong (and I know I’m not alone in feeling this way when it comes to working with previous projects).

But this is not pragmatic, and it’s not so for some different reasons. So over the next three posts, I thought I’d share a little bit about the state of the project, managing the tension that exists, and how to do what we can when we’re faced with this type of situation.

Continue reading

« Older posts Newer posts »

© 2025 Tom McFarlin

Theme by Anders NorenUp ↑