|
|
When you start off with plugin development, you can make a lot of mistakes. And that’s fine! We all make mistakes and that’s one of the best ways to learn and improve to become a better developer. Here are five common mistakes that beginning WordPress plugin developers make, and good ways to fix them.
1. Developing with DEBUG mode Off
Turning on Debug from the beginning of plugin development can be a huge boon to your project. In fact, I would venture to say that it is the most important debugging configuration that you can have. WP_DEBUG is a boolean constant that you can turn off and on in your wp-config.php file in your WordPress install.
If WP_DEBUG is set to true, you will start seeing PHP notices that can provide you with beneficial messages that aid development. It also functions towards generating WordPress debug messages and deprecated function usage that displayed on your site’s pages.
It’s important to use the debug mode for these deprecated functions as they are set to expire at a later date. You can easily find a replacement to use by knowing if you are using a deprecated function in a particular theme or plugin that you are working on.
Some argue that WP_DEBUG should never be used on a live site because visitors could see potential errors, but if you use a special log file to catalog your errors, you won’t have your errors displayed to your site’s visitors. Here’s a great article if you want to do that.
2. Not sticking to WordPress.org official guidelines
If you’re looking to submit your plugin to the WordPress.org repository, you will have to follow the official guidelines. An example of an important guideline: plugins must be free.
Sticking to the official guidelines (which are more like a set of rules) is crucial. If you aren’t careful, your plugin could be banned from the repository without prior notice. If you have done so, you’ll receive an email from the repository moderator with the opportunity to fix your plugin and re-submit it for review. In other cases where the intent is malicious, there won’t be any re-approval.
3. Not starting with good organized code
Development isn’t always linear. Sometimes you start a very small plugin and neglect all the best practices just to “hack” a quick solution.
Unfortunately, many of the plugins that start that way tend to grow quicker than expected–which can result in a widely popular project with messy functions, broken object-oriented architecture, and a lot of inconsistent coding standards. Our project, RatingWidget, started as a small wrapper plugin for our SaaS rating solution. Today our WordPress plugin contains over 10,000 lines of code. We never imagined that it would happen–but it did. So please keep your plugin’s code clean from day one. Leave the hacking for someone else and focus on development. In addition, you can leverage a lot of great tools for plugin developers that will help you to do it easily.
So please keep your plugin’s code clean from day one. Leave the hacking for someone else and focus on development.
4. Writing code without thinking about compatibility
Before you start writing code, you have to decide which version of WordPress and PHP version you will develop for. You can’t know which version your user will have, so you will have to make a decision based on your potential market.
Here’s an example. If you decide to support PHP 5 and above, you cannot use namespaces in your code since they were introduced later in PHP 5.3. There are also functions/hooks/filters that WordPress doesn’t support.
Here’s a great source explaining how you can alienate a market by coding a certain way. As you can see, 15% of WordPress users are using PHP 5.2. By utilizing namespaces in a plugin, you immediately lose 15% of your potential user base.
Before developing your plugin, you must consider your market size and compatibility. To maximize your market share, I recommend to target your WordPress plugin to WordPress version 3.0 and PHP 5.0, and above.
To maximize your market share, I recommend to target your WordPress plugin to WordPress version 3.0 and PHP 5.0, and above.
5. Not understanding and defending against SQL injection
SQL injection is a series of attacks in which hackers try to embed commands into an HTTP request that triggers behaviors from a site’s database. These attacks can give hackers valuable information from the database and potentially give them access to the whole site.
How do you defend against SQL injection? You should never, and I mean NEVER, use the parameter received from a user input AS IS, in your SQL queries. The best solution is to use the WordPress core prepare() function. This function helps you “sanitize” the SQL queries’ parameters. Check out this great post from Samuel Wood (Otto), on how to use prepare functions.
Are there any plugin development mistakes that you have made? The best way to learn is from mistakes after all. Let me know so we can get a discussion going.
The "Not starting with good organized code" mistake is the one an entire post could be about. Unfortunately, I made this mistake and it is hard to recover from. My main plugin, started out as a "thrown together" solution that eventually got released and has had many many updates. Now that I am going back and trying to get it organized and documented correctly, it is definitely quite challenging. I highly recommend starting the initial version as organized and modularized code.
The guidelines and the compatibility are my first priority!