Tom McFarlin

Software Engineering in WordPress, PHP, and Backend Development

Page 262 of 428

A WordPress Developer Salary Should Be…?

Earlier this week, Ryan Sullivan – a twitter-friend of mine – sent out the following note:

An interesting observation, isn’t it? Especially for those who work on WordPress full time, work with WordPress full time, and/or those who have come to WordPress from other backgrounds. Specifically those in software development backgrounds.

Straight up, I’ll say that I don’t know why a WordPress developer salary is less than any other [insert whatever type of] developer salary is here, but I have my thoughts and speculations (as I’m sure you do, as well). And as I – and many others – have been talking more and more about trying to force a shift in the WordPress economy, this seemed like a timely thing to share.

Continue reading

Making the Shift to Premium WordPress Plugins

When it comes to various business models that surround WordPress plugins, there are normally three types:

  1. Completely free
  2. Freemium
  3. Premium

How a developer opts to publish their plugin is their prerogative, and there are a lot of opinions as to why any one model is better than any of the other models. As with anything, each has its own set of advantages, and each person’s opinion is not necessarily any better than any other person’s opinion.

That said, as someone who has tried all three business models, I have to say that the longer I work in this particular economy, the more I lean towards the third option.

Though I’m not saying I dislike the other two, and though I’m not interested in discussing the advantages and disadvantages of the first two (at least in this post), I am interested in sharing my thoughts on the premium model (or the pay-for-it model or whatever you want to call it.

Continue reading

Pressware: Just Another WordPress Company

Since launching The Pressware Shop a few months ago, I’ve also been working to blog a few times a week about what’s going on with the projects that are in development and about some of the core philosophies that I’m trying to follow as I work to introduce this second arm of the company.

The Pressware Shop

When Pressware first started, it was primarily services-oriented. That is, it was primarily made up of doing contract work (which I love doing) with a few hobby projects on the side; however, as time has passed, I’ve been able to add to the team to continue to service-oriented side of things while also focusing on building products.

But there are already so many WordPress companies already available, why bother starting another one?

Continue reading

Publicly Display Post Meta Data in WordPress

Comments are closed on this article. If you have something to add, please do so on the original article!

A couple of weeks ago, I shared a simple plugin that added a meta box to the post editor dashboard screen that demonstrated how to display post meta data within WordPress. After it was released, I received a few questions as to how one would go about displaying this information on the frontend of a WordPress blog.

That is, how would one go about displaying the post meta data as part of the content for a single post (or post type) in WordPress.

Though I’m not necessarily a fan of doing this, I am a fan of giving other developers practical advice on how to extend existing plugins (using practices used throughout an existing plugin), and I’m also a fan of discussing why I am a fan or not a fan of doing something.

So in my latest article at Tuts+ Code, I did exactly that.

Continue reading

Writing JavaScript Helpers for the WordPress Theme Customizer

I’ve talked before about how I think the addition of the WordPress Theme Customizer (well, soon to be called the Customizer) is one of the nicest additions to the core application in a long time. I’ve also talked about how I fear the direction that some developers will take it.

Regardless, if you’ve worked with the Customizer long enough – especially when it comes to the JavaScript aspect of it – then you’ve likely noticed that you can end up writing relatively repetitive code especially when you’re working with something such as a list of items or something similar.

When you end up reaching this particular point, having too much of the same code with the only variations being a few strings ends up being a bit of a code smell.

In order to prevent this, it’s often better to write helper functions that abstracts the repetitive functionality into a single, ahem, function that you can call with the strings that are unique to your use case.

Here’s what I mean.

Continue reading

« Older posts Newer posts »

© 2026 Tom McFarlin

Theme by Anders NorenUp ↑