Tom McFarlin

Software Engineering in WordPress, PHP, and Backend Development

Page 94 of 428

What’s the Difference in CodeKit and Composer?

Since I’ve written about CodeKit and Composer (more about the latter in recent posts, really), I’ll occasionally get emails asking which do I really prefer using whenever it comes to working on projects for others.

And the short answer is that they aren’t mutually exclusive. If anything, they can complement each other. They aren’t substitutes for each other.

As I’ve moved from less and less frontend-oriented projects, the less I use CodeKit. And the more I’ve moved more towards backend-oriented development, the more I use Composer.

Furthermore, front-end development is different than back-end development, right? So, again, why would we ask:

Should I use CodeKit or Composer?

That’s where the longer answer comes into play.

Continue reading

Scheduled Post Shortcut 1.4.1 Now Available

Scheduled Post Shortcut is arguably my least popular plugins. That is, has an extremely low number of downloads based on what few number of analytics I have.

Scheduled Post Shortcut 1.4.1

Regardless, it’s one that I use (I mean, I technically wrote it for myself) and there are those who use the plugin if they write with any sort of regularity – whatever that may be for them.

However, it’s been brought to my attention by a number of people who joined up as members that they saw an error message in their dashboard whenever they logged into the site.

No good, right?

So as I head into the holidays, I wanted to get a quick fix for this out as a “thank you” to those who use it and for those who reported the error and who have signed up to join the site.

Continue reading

Musings on a Decade of WordPress: Themes, Plugins, News, Hosting, and More

I’ve been sitting on the idea of this post for some time because I’ve not been sure how to best articulate it. Some of us are better with words than others and all that.

But I thought since it’s been a while since I’ve written anything beyond a technical post, that maybe I’d use this time (you know, during the whole upcoming holiday season and all that), to share some thoughts, opinions, and observations on all things WordPress.

For those who live and die by hit pieces or the “…you’ll never believe what happens next” stuff we’re used to seeing on so many social media outlets, this is not that post.

Instead, this is one person who has been working with WordPress in a professional capacity for close to a decade in a technical way who’s simply sharing observations.

There’s a lyric I like:

Opinions are immunity from being told you’re wrong.

Maybe that works here, maybe not. I don’t know. But I’m going to open comments on this post, and although I may not respond to them, I’m genuinely interested in other people’s take on their experience with WordPress.

Continue reading

5 Ideas for an Enhanced GitHub Workflow

Depending on your history with working source control, the way in which you go about working with a codebase, making commits, etc., varies.

Further, depending on if you’re using Git, Subversion, Mercurial, and so on also dictate how you manage your code.

But if you’re someone who’s working with Git (which I know many people in WordPress are starting to use more and more almost on a daily basis), there are some small things that I recommend doing to help make managing changes espcially with a team more manageable.

Continue reading

Object-Oriented Programming in WordPress: Understanding Customer Expectations

As we continue to move forward discussion object-oriented programming in WordPress, it’s important that we make sure we’re not jumping ahead of ourselves when it comes to building a product for someone else.

So often, it’s easy to:

  1. hear what a customer says,
  2. build something out based on what we’ve heard,
  3. turn it over to said customer.

But there is so much more to it than that. I’ve danced around it a bit in previous posts in this series; however, I want to start drilling down into what it means to hear:

  1. What a customer says,
  2. Develop a set of requirements,
  3. And then create feedback loops around that.

Ultimately, we want to make sure the people for whom we’re working the and solutions that we’re building truly are solutions and not hindrances or hurdles over which they have to jump.

Furthermore, I don’t think it’s enough that a customer simply enjoys the experience of their final product, but with working with the one (or the ones) building the solution, as well.

With that said, let’s take a look at what it means to listen what they say and go from there.

Continue reading

« Older posts Newer posts »

© 2026 Tom McFarlin

Theme by Anders NorenUp ↑