Software Engineering in Web Development, Backend Services, and More
Articles, tips, and resources for WordPress-based development.
Escaping strings for WordPress is something that developers should be doing at any place in which the user can be sending information across the wire to the database.
Core offers some nice API functions for this. But if you’re writing a raw database query using $wpdb (which is something that I recommend only when an API doesn’t offer what’s needed), then there are still options, but you may need to fall back to a native PHP function.
Case in point: mysqli_real_escape_string.
The CLI is one of those tools that I think every developer should know how to use even if they don’t use it consistently. After all, we have plenty of applications for taking care of tasks, right?
The thing is, from time-to-time, it’s useful. During the process of working on projects, you may be hopping back and forth between an IDE, an SSH session, S/FTP, a task runner, debugging, and so on.
Sometimes, particularly in the beginning, it’s hard to juggle all of the commands in your head.
Though I love using applications to help take care of certain tasks, I’ve never fully let the command-line go. Sometimes, it’s just faster to type out a string of commands and let them do their work rather than poke around a number of different applications.
Maybe that’s stubborn. I don’t know. But what if you’ve not used the CLI? How do you maintain a quick reference to the available commands?
The “Perfect WordPress Development Stack” is one of those topics that comes up now and again in various blogs (and here it is again – how meta, right?), talks, tweets, and so on.
And I think it’s a good point of conversation. If you’re working with WordPress in a professional capacity, then you should have a stack that maintains some level of professionalism.
But what does that look like? It’s likely that some of you know where I’m going with us and the answer may sound like a cop-out.
It’s not, though. It’s generally what I’ve found to be true.
Deregistering WordPress stylesheets is one of those things that we don’t always have to consider.
If you’re starting a project from scratch, then it’s usually safe to say that you’re starting a project at ground zero and have control over most of the assets that are to be enqueued in the project.
On the other hand, if you’re coming into a project at a later date or you’re working on a plugin that has to work in conjunction with another plugin that might use a shared stylesheet then you may need to deregister an existing asset to make sure everything works well together.
Using PHP CodeSniffer is one of those tools that is part of my workflow that I find utterly invaluable. I haven’t always used it, though.
Don’t get me wrong: If you’ve read this blog for any length of time, you know I’m big on Coding Standards. But when it came to the PHP CodeSniffer, there was an extended period I had gone before I installed it.
Why, though?
Simply put, it was because I didn’t know it existed, at least not for WordPress. When I discovered there was a ruleset for WordPress (and WordPress VIP), it became something that I believe should be a necessary tool in every WordPress developer’s toolbox.
Depending on your IDE, you may or may not be able to install a plugin or an extension that will automatically monitor your code while you’re writing.
I made the change to Atom some time ago, which I’ll share more about momentarily, and it has excellent support for incorporating PHP CodeSniffer into your workflow.
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 ↑