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.
A couple of months ago, I did a short series on Envato on Ajax in the WordPress Dashboard. This month, I’m continuing to talk about Ajax in WordPress and how to include it on the frontend in your themes, plugins, and other projects.
Though the Codex has two great articles on Ajax in WordPress – that is, the introduction and how to use it on the server-side – there’s not a lot of documentation for how to implement it on the front end
When it comes to writing code specifically for WordPress, I try my best to follow a combination of the WordPress coding standards, tips and advice from various books I’ve read (which I hope to cover in a future post), tips from others in the community, and certain habits that I’ve developed along way the way.
The thing that I’ve always struggled with determining is what constitutes clean code. There is code that follows standards, then there’s clean code, and I think that the definition is almost somewhat subjective.
With the open source nature of WordPress, the desire to improve education around the platform, the desire to improve the plugins repository, and the existence of things such as Theme Review team, Theme Unit Test, and tools specifically for helping us write code, there’s an innate desire for programmers to write clean code – I just think that we could do a better job defining it.
To be clear, I don’t believe that clean code is synonymous with quality code, nor do I believe that clean code is synonymous with good code. They’re absolutely all related, but they aren’t the same thing.
With said, what does constitute clean code specifically in the context of WordPress development?
WANTED: WordPress Professionals With a Passion for Education. Enquire Within. http://t.co/UyG6C7dc
— Wptuts+ (@wptuts) October 3, 2012
Yesterday, @EnvatoWP invited others to apply to begin writing for WPTuts+, the Envato WordPress site.
One of the things that my team and I have consistently discussed when working on Standard is how to actually maintain or version numbers. It doesn’t stop there, of course – even in my own work, I give considerable thought (how lame does that sound?) as to how I should track the version numbers of my projects.
Thought I tend to follow the schema of “Major Version, Minor Version, Hot Fix” (i.e., 3.0.2), I’m unsatisfied. And to put it bluntly, I’m discontent with the whole thing version numbering issue: They’re inconsistent, they aren’t user-friendly, and I’m not even sure what we should do about it.
This is the final post in the series JavaScript in WordPress. Be sure to read the first article, too!
In the first post in this series, I briefly mentioned that there is a problem with writing JavaScript in WordPress. In boils down to the fact that people are writing JavaScript who don’t truly know jQuery (let alone JavaScript), and that there are lack of standards to follow.
And though I’m not interested in defining the coding standards for JavaScript in WordPress – at least not here – I am interested in sharing four things that I’ve found to be successful in writing maintainable jQuery in WordPress for both individual and team-based projects.
Note, of course, that these are geared towards jQuery. After all, that is WordPress’ JavaScript library of choice.
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 ↑