Top 7 mistakes to avoid during WordPress plug-in development Willing to develop plug-in for Word Press? Good! Being a developer, you should never be afraid of making mistakes. “The only way to avoid mistakes is to have no new ideas” says an old adage by Albert Einstein. We have also noticed in the past that some of the big enterprise platforms, like cloud computing, big data, online project management tools, etc., have failed just because they tweaked their existing functionalities based on few new ideas. As the agenda here is Word Press plug-in development, so I am discussing top seven mistakes you being a developer can easily avoid during Word Press plug-in development. Let’s begin
1. No Organized Coding Many developers act frantically try to find a quick solution while developing a very small plugin. As a matter of fact, many of such plug-in end up having bad functionality, flaws in oriented architecture and botched up codes. It’s highly recommended to follow the best practices of organized coding from the very beginning of Word Press plug-in development. There are many tools available for plug-in developers to develop their Word Press plug-in at ease. The Takeaway: Hacking does not produce fruitful results for your plug-in development, so focus on making your plug-in code clean from day one.
2. Not Complying With Official Guidelines Of WordPress.org The official guidelines of WordPress.org are set of rules that one must adhere to if looking forward to submit the plug-in to the WordPress.org repository. It’s important to understand the guidelines and comply with them since any goof up could result in a ban for your plug-in from the repository. In case of any flaws being made, an email is sent to fix the plug-in and submit it again for the review. However, there won’t be any reapproval if the intent behind developing the plug-in is malicious.
3. Not Considering Compatibility While Writing Code Before you begin your stint to write code, you must decide the version of Word Press and PHP you want to develop for. It’s almost next to impossible to figure out which version your users are likely to use, therefore your decision has to be based on your potential market. Let’s understand this better with an example. You are looking forward providing support for PHP 5 and above. In this case, your code must not contain namespaces since they were introduced much later in PHP 5.3. Besides, Word Press is also not compatible with many functions/hooks/filters. As per figures of WP Central, PHP 5.2 is being used by 15% of Word
Press users. So, if you use namespaces in your code, you provide only 85% Word Press users the opportunity to use your plug-in. Therefore, it’s paramount to have a clear understanding of your market size and compatibility before you begin development of your plug-in. To make the best out of your Word Press plug-in, you should go for Word Press version 3.0 and PHP 5.0, and above.
4. Turning Off DEBUG Mode During Development One of the most common mistakes many developers make during Word Press plug-in development is keeping debug mode off. You must avoid that as it is the most important debugging configuration that you can have. You can turn on and off a Boolean constant, i.e. WP_DEBUG, in your wp-config.php file in your Word Press install. It lets you see PHP notices so that you can become better at development. Besides, WP_DEBUG also serves the purpose of generating Word Press debug messages and deprecated function usage. Deprecated functions come with expiry dates, so by turning debug mode you can easily figure out that and find a replacement before they expire.
5. No Clear Strategy To Ward Off The Risk Of SQL Injection Word Press plug-in developers must pay heed to SQL injection since it enables hackers to get access to valuable information from the database. All that hackers need to make this happen is to embed commands into an HTTP request and begin extracting information from site’s database. Here arises a question: How you can avoid SQL injection. Word Press plug-in experts suggest not using the parameter received from a user input AS IS, in SQL queries. The best remedy to this problem is to use the Word Press core prepare() function as it lets you sanitize the parameters of SQL queries.
6. Not Using Word Press Nonce’s Use of Word Press Nonce is also imperative since it provides strong protection to URLs and forms, thereby preventing their misuse. If a user wants to perform an action, like deleting a post, post review etc, Word Press Nonce identifies the person and confirms the action from the user. In other words, we could also say that Word Press Nonce is a unique identifier for a user performing an action. For creating the nonce, you need to use the wp_create_nonce() function. You can prevent Cross-Site Request Forgery (CSRF) attacks by appending the nonce to the URLs and adding it to forms as a hidden field through wp_nonce_field(). As a result, it becomes possible to figure out if the request to a specific URl was generated from the same site or from any other site. Nonces in WordPress are generated in the form of a hash which includes the user’s ID. As each user has a distinct nonce, it becomes instantly known as to which user has requested to perform a
specific action. Besides, none parameter prevents a user from getting tricked into clicking on a link that would result into unexpected behavior.
7. Not Prefixing Your Functions Being a plugin developer, you must know that other plugin developers could also use the same names for functions that you use. To your better understanding, if you use function names like copy_file(), save_data(), and database_table_exists(), there are always chances for them being used by other plugins too. The reason is simple: All functions from all plugins exist in WordPress execution space. So, as soon as a WordPress plugin activates, PHP begins loading the functions from the plugin into the WordPress execution space, without any separation or isolation of them for each plugin. Now, comes the remedy part to slough off this problem – Give a unique name to each function of your WordPress plugin by adding a prefix to them. For example, the aforementioned functions could be named as myplugin_copy_file(), myplugin_save_data() and myplugin_database_table_exists (). You can also use the abbreviation of your plugin’s name as the prefix for your plugin functions. In case, you are not interested in using prefixes with your plugin functions, you must use PHP classes that contain your functions. I have shed light on the most common mistakes WordPress plugin developers often make. However, if you have ever developed a WordPress plugin and made a mistake apart from the ones discussed above, please share it with us in the comment box below.