This week I’m going to show you how to do an audit for the codebase of a WordPress plugin.
A checklist of areas where you can steadily make improvements helps you make the best decision of where you should spend your time.
You should always be auditing your plugin for areas of improvement, but often this type of improvement isn’t prioritized.
Its often easier to add new features than audit and fix existing issues
Cleaning up your codebase is some of the most important work you can do for your plugin.
When you don’t take time to audit your WordPress plugin’s codebase:
- You’re vulnerable to security issues
- You could be slowing down your users’ sites
- You could be causing an error that breaks a core feature
Once you know the major areas to audit your WordPress plugin, you can systematically work through each.
Here are the 3 most important steps you can do in an audit:
Step 1: Do a full review of the plugin
There are a few key points of your plugin that you will want to dig into to get a full picture.
Architecture
When reviewing a plugin, it’s important to review the overall architecture and understand how it all works together.
Be sure to think through everything that your plugin interacts with. If there are any 3rd party dependencies, make sure that your plugin interfaces with them securely and efficiently.
Database
Review all interactions with the database, whether through general queries, WP_Query, or raw SQL queries. Review everything to be sure that you’re running the least amount of queries necessary and that the queries that are used are as efficient as possible.
Keep in mind that some things are more efficient to query manually than core WordPress functions.
Test Coverage
Automated tests are an important part of software development and ensure that the code you’ve written does what you expect.
It’s a great way to evaluate if your making changes that break your functionality.
If you don’t have any tests or don’t have very many, that’s a good thing to note here. Adding automated testing will improve your plugin’s quality and make the code more reliable.
Step 2: Evaluate Security Issues & Best Practices
The WordPress codex does a great job walking through best practices that should be used to help write secure code for your plugin.
The guiding principles listed at the start of the Security section are a great start:
- Never trust user input.
- Escape as late as possible.
- Escape everything from untrusted sources (e.g., databases and users), third-parties (e.g., Twitter), etc.
- Never assume anything.
- Sanitation is okay, but validation/rejection is better.
Step 3: Implement Code Editor Tools & Review Results
Code Sniffing
This is a practice used to verify that code is using proper formatting, but it will also help suggest areas of improvement. I use PHP Code Sniffer (PHPCS) for this.
For example, when using the WordPress Coding Standards, it will highlight when your code does not properly escape values when outputting them.
It’s really helpful in quickly identifying and fixing issues in existing code as well as the code you are currently writing.
Static Analysis
Static analysis is a powerful tool because it will load all of your code and look for bugs that your users haven’t ever told you about in support requests (or bugs that haven’t occurred yet).
I’ve written about this in a past newsletter because using a Static Analysis tool is one of the best ways to check your code for bugs before you push out new versions to your users.
PHP Compatibility
Plugins should always be reviewing compatibility with different versions of PHP.
Especially now that new versions are released more frequently than they used to.
This is also something that you can evaluate with PHPCS automatically every time you submit a pull request on Github.
If you are using PHP Code Sniffer, here is a library that I use to check for compatibility with different PHP versions.
In Conclusion
Every WordPress plugin developer should be auditing plugin code on a consistent basis. It’s critical to improve the existing code while writing new secure and efficient code.
To review, there are 3 main steps for auditing your plugin:
- Review overall architecture, database, and tests
- Evaluate security & wordPress best practices
- Set up tools to help identify current issues
I hope this has helped give you some direction when doing an audit on your own plugin’s codebase.
That’s all for now, see you next week!
