Guest Post

Willing to develop plugins for WordPress? Good! Being a developer, you should never be afraid of making mistakes. “The only way to avoid mistakes is to have no new ideas, Organised, ” 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 WordPress plugin development, so I am discussing top seven mistakes you being a developer can easily avoid during WordPress plugin development.

Let’s be organised

1. No 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 plugins end up having bad functionality, flaws in oriented architecture and botched up codes. It’s highly recommended to follow the best practices of organised coding from the very beginning of WordPress plugin development. There are many tools available for plugin developers to develop their WordPress plugins at ease.

The Takeaway: Hacking does not produce fruitful results for your plugin development, so focus on making your plugin 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 submitting the plugin 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 plugin from the repository. In the case of any flaws being made, an email is sent to fix the plugin and submit it again for the review. However, there won’t be any reapproval if the intent behind developing the plugin is malicious.

3. Not Considering Compatibility While Writing Code

Before you begin your stint to write code, you must decide the version of WordPress 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, WordPress is also not compatible with many functions/hooks/filters. As per figures of WP Central, PHP 5.2 is being used by 15% of WordPress users. So, if you use namespaces in your code, you provide only 85% WordPress user with the opportunity to use your plugin.

Therefore, it’s paramount to have a clear understanding of your market size and compatibility before you begin development of your plugin. To make the best out of your WordPress plugin, you should go for WordPress 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 WordPress plugin 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 WordPress install. It lets you see PHP notices so that you can become better at development.

Besides, WP_DEBUG also serves the purpose of generating WordPress 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

WordPress plugin 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.

WordPress plugin 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 WordPress core prepare() function as it lets you sanitise the parameters of SQL queries.

6. Not Using WordPress Nonces

Use of WordPress 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, WordPress Nonce identifies the person and confirms the action from the user. In other words, we could also say that WordPress 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 in unexpected behaviour.

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.

Author Bio:

Manmohan Singh is a tech geek, enthusiastic reader and an active member of different programming forums. He loves to write on the topic that impacts human lives, such as global warming, space science together with the recent technology and digital marketing topics that include SEO, SEM, SMM, and more.