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 upgrading a an operating system, specifically if you’re on a Mac of any sort, people have mixed feelings. I’ve heard some people say they’ve lost a day’s worth of productivity. I’ve heard others say that the upgrade worked flawlessly.
With two very minor hiccups, the upgrade to Mojave has been in the latter camp. Specifically, at the time of this writing, Firefox doesn’t mainly play well with writing to the filesystem via its standard dialog. And my installed of Git was hosed.
If you’ve been following along with the series thus far, then you’re likely seeing just how useful proper debugging can be especially when working on WordPress.
That is to say that not only are you able to gain valuable insights into your own projects, but you can see how WordPress core works, too.
At this point, though, we haven’t done much. As you may recall from the previous post (or if you haven’t watched the screencast, now is a good time to do so), you can see just how much debugging offers.
The truth is, we’ve barely scratched the surface. As I mentioned last time, this post and this screencast are going to focus specifically on the following:
In the next post, we’re going to look at more advanced things we can do such as stepping into functions, stepping out of functions, and stepping over functions.
We’re still not at a point where we’re going to worry about changing variable values on-the-fly, but we’re definitely going to see how we can strategically use the debugger to step into certain functions, step over certain functions, and step out of certain functions.
In the most recent post in this series, I walked through the process of integrating Xdebug with your IDE. And given that I’ve been using Visual Studio Code as my IDE of choice, that’s also the IDE I’m using as the example.
Furthermore, it’s cross-platform, easy enough to get started for beginners, but powerful enough to extend and operate for more experienced programmers (and for the rest of us who fall in between).
In the last post, I stated that I’d be doing a series of screencasts. Specifically, I wrote the following:
Starting in the next post, I’ll begin sharing some screencasts that walk through how to debug functions and variables, change values on the fly, work with the debug console, and more.
In this post, I’m going to have a short screencast providing an introduction to debugging WordPress the first part of this series. Namely, launching an instance of a site built using WordPress and using the basics of debugging a plugin.
One of the things about working with the WordPress menu API (that is add_menu_page, add_submenu_page, and the like) is that it doesn’t make it easy to reorder the submenu items.
Sure, for certain things such as taxonomies or things like that, you can just change the order in which they are registered. But let’s say that you have a WordPress admin menu and then a few submenu pages under that particular menu.
By default, WordPress creates the top-level menu, and then it immediately creates a submenu item under the top-level menu that links to the same page. In many cases, this may be ideal.
In some cases, though, you may want to change that.
Years ago, I wrote a post in which I shared a public function to determine if the user had permissions to save information to the WordPress database. You can see the original gist in all of its aged glory (along with the solid comments) here (it’s five years old, even – wow).
As with anything programming related, time passes, things are refined, and things [hopefully] get better than they were before.
Though I still use and recommend a variant of the user_can_save (or userCanSave) function, I also think it’s important to go through the process of separating out the process of verifying the request.
So now it’s not just about determining if the user has permissions, but it’s about verifying the security information coming from the client – be it via a post back to the server or a request made via Ajax – and doing so using good programming techniques that align both with WordPress and with PHP.
To be clear, this is more about secure WordPress form submission from an options page or a settings page than it is, say, a form coming from a template. That’s another post for another time.
But still, there are plenty of us working on building applications on WordPress and that require the following.
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 ↑