Software Engineering in Web Development, Backend Services, and More
Personal opinions and how-to’s that I’ve written both here and as contributions to other blogs.
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?
Recently, I received an email from a fellow developer who had finished reading a number of series of articles on WordPress, who had watched a number of WordPress tutorial videos, and was working towards mastering WordPress.
He went on to discuss his current skill set, his aspirations, and the type of projects he eventually wanted to take on as his career progressed.
Not bad, right?
Here, you’ve got a person that knows who he is, knows where he wants to be, and is looking for advice on how to get there.
Unfortunately, there was only so much advice I could give (I’d love to master WordPress, as well!), but the bottom is line I responded with a series of things that i think he – or anyone – can do in order to become a better WordPress developer.
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.
© 2026 Tom McFarlin
Theme by Anders Noren — Up ↑
