Software Engineering in WordPress, PHP, and Backend Development
Personal opinions and how-to’s that I’ve written both here and as contributions to other blogs.
When it comes to pricing WordPress plugins, this isn’t exactly new territory. In fact, I’d say when it comes to pricing any online service or product, there are already tried and true ways that prove to be useful given certain scenarios.
It’s basic economics, I suppose.
So this post isn’t so much about various ways to go about pricing WordPress plugins, but what opportunities we have as developers, designers, companies, and so on as the WordPress landscape continues to change.
About three months ago, I published about on teasing Pressware.
Straight from the initial post itself:
But as years have passed, my focus has shifted, and I’ve begun to target specific things – namely WordPress and its tangential topics – I thought it fitting to label the business in that direction. Thus, The Pressware Company, or Pressware, for short.
And as of today, I’m proud to finally be releasing the landing page and the official launch of the brand.
I – along with a number of other contributors – have been working hard to close out issues and prepare the next version of the WordPress Plugin Boilerplate.
Sure, I’m excited, but while working on this particular plugin, I realized that for anyone who does work with a WordPress plugins either via git or Subversion, that you may be working with a mess of directories while trying to develop the thing.
It’s nothing that a symbolic link can’t fix, but first, let me explain the problem.
When it comes to building custom WordPress applications, plugins, or themes, one of the things that I’m a big proponent of doing is maintaining the native WordPress admin look and feel.
That is to say that I am not a fan of introducing option pages or other elements that deviate from the styles that WordPress core provides.
Case in point: Theme settings pages should match the same theme as the rest of the settings pages in WordPress. There shouldn’t be any major deviation in color scheme, font, or the way certain elements function. By that, I mean tabs should work without any fancy animation, and so on.
But there are times when modifying core user interface components that enhance the experience and that do deviate slightly from the core native WordPress core styling.
In those cases, is deviating from WordPress core acceptable?
In my previous post, I shared a few thoughts on how I think someone can become a better WordPress developer.
When it comes to talking with beginner – or intermediate – WordPress developers, one thing that I’ve noticed is that when you suggest the WordPress Codex as a resource, there’s beginning to be a somewhat-typical response that I’m beginning to hear:
Please don’t suggest the Codex.
Bummer, right?
Kinsta offers premium managed WordPress hosting for everyone, small or large. Powered by Google Platform and strengthened by Cloudflare, they take performance to the next level. All hosting plans include 24/7/365 support from their team of WordPress engineers. Get started with a free migration today.
If you are looking for WordPress guides and unbiased reviews, I recommend checking out WPKube. They also have an exclusive deals section.
© 2025 Tom McFarlin
Theme by Anders Noren — Up ↑
