One of the greatest things about WordPress that has made it so popular is the incredible API the application has providing an easy way to customize and extend the application. Unfortunately, this can also be one of it’s greatest drawbacks as well. If you want to be successful as a WordPress plugin developer, you need to familiarize yourself with the WordPress API.
As a plugin developer, I have made it a priority to understand the inner workings of WordPress as much as possible and to always use WP functions whenever possible. This can be a challenge because WP is in a constant state of development (with a stated objective of two major releases per year), and also there are still pieces of the application that are either poorly documented or completely undocumented.
There are a couple of reasons that as a WordPress plugin developer, one of your best practices must be to familiarize yourself with WP’s functions and classes and use those whenever possible.
I will start with the obvious. Why would you waste time reinventing the wheel? If there is already a way to do something with a WordPress function, why build your own? That just seems like wasted effort and extra code that you will need to maintain yourself.
Most WordPress Classes can be extended, and many functions have action and filter hooks that you can connect to in order to customize your outcome. It is much better to work within that API than it is to “go rogue.” Unfortunately, too many developers ignore this, and that is not only detrimental to their own projects, but also to any outside users that might be using their plugins.
The other and more primary reason for following this best practice is that you must worry about maintaining compatibility on your own. This dovetails with the explanation I already outlined in that you are doing your own maintenance.
Consider Samuel Wood’s announcement today about MySQL changes in WP 3.9. I have wanted to write on the subject from a “not reinventing the wheel” perspective for some time, but this announcement really motivated me. The reason this peaked my interest is that, of the plugin’s I see that violate this rule, MySQL is probably the biggest culprit.
Instead of using WP’s wpdb class to handle database queries, read/writes, etc, I see plugin’s all the time that do their database work directly accessing the db. That certainly can lead to security issues, and that’s a topic for another talk. But it also leads to the kinds of problems outlined in Otto’s post.
My suspicion is that most developers who violate this type of best practice also do not follow the WP development announcements in advance either, so I am probably preaching to the choir. But if you are someone who is either a developer now or yearn to be, do things right the first time around and you’ll save yourself a lot of headache later.
While there is information yet undocumented, there is also a great deal of information available in the Codex:
And if it’s not already documented in the Codex or could be expanded, did you know that you can help by contributing to the Codex?
Curious about contributing to the Codex? Here’s my Codex page with some of the pages that I’ve either started or worked on.
Enjoyed this article?
Don't miss a single post. Subscribe to our RSS feed!
