A Developer’s Guide to Using Free WordPress Plugins

WordPress, the most popular content management system in the world, is built on a structure that allows users to supplement core functionality with themes that provide visual designs and plugins that provide specific additional functionality.

There are now over 20,000 plugins in the official WordPress repository, all of them free to use. Anyone can upload a plugin, and if it is good it is likely to become very popular. This does, however, carry some risks. What if the plugin is poorly coded and breaks down? What if it’s incompatible with other plugins, the theme being used, or even core functionality? What if – heaven forbid – it has been deliberately set up to place malicious code on your website?

Should Developers Use Free Plugins?

The answer to this question depends upon your personal preference and status of your project. Personally, I prefer to write my own plugins whenever possible. In real life, that isn’t always possible: client requirements, deadlines, capabilities of other team members etc might not allow for that. In such situations, developers understandably consider whether a free plugin can provide the required functionalities.

It can be easier, faster and more cost-effective for even an experience developer to use a freely available plugin. There is nothing wrong with this, but the developer needs to be aware that there are some considerations that should be taken into account. Once you decide to work with free plugins, you have to consider various factors in choosing the right plugin in order to prevent unexpected behaviour.

Basics for Choosing WordPress Plugins

There is a group of factors that apply to anyone considering using a free WordPress plugin, whether they are site owners, amateur designers or professional developers.

Versions and Compatibility

Version details are placed at the top right corner of every WordPress plugin detail page. Check that you are using the latest version of the plugin and that it is compatible with the version of WordPress you are using. If a plugin has been updated recently, it’s an indicator that the author is keeping up with compatibility requirements.

Downloads, Ratings and Reviews

A high number of downloads and good user ratings indicate that users are not having problems using this plugin. Also make sure to check the reviews section to find out why users like this plugin and what difficulties they may have found in using this plugin.

Documentation and Support

Plugins may be created and distributed by large development agencies or a solo operator who had a good idea. Either way, the end user and you as the developer should look for clear, accurate and up-to-date documentation as well as a means of obtaining support from the plugin developer and/or a the community of people who use the plugin. A larger agency may have a website that provides knowledgebase, a Frequently Asked Questions page, a ticketing system and/or a forum where users can crowdsource solutions to problems.

Smaller or solo plugin developers may provide a blog that covers much the same set of purposes, preferably including a way of contacting the plugin author direct.

A nontechnical user such as an amateur setting up their own website may consider it worth taking the risk of using a plugin that does not have adequate documentation and support. A professional developer working for a client never should: the consequences could be disastrous for your reputation.

The Developer’s Perspective

The factors mentioned in the previous section apply to anyone considering using a free WordPress plugin. However, developers come equipped with skills and information not available to the everyday mortal and they thus carry a greater level of responsibility to check things ordinary users may not even know about.

Test in a Non-Crucial Environment

Never test new plugins in your production environment or any other WordPress installation that is important to you. Instead, try keeping a separate WordPress installation for testing purposes with the default themes and default plugins.

Keep your test environment tidy, so you don’t end up with lots of unused plugins that may conflict with each other. Make your testing environment mimic your production environment as closely as possible. Activate the chosen plugin, test it properly and then remove it before testing the next plugin.

Given that everything works as expected, it’s time to dig into the code and see whether the chosen plugin is suitable to use in your actual applications.

Function and Class Naming Conventions

Anyone can upload plugins to WordPress plugin repository as long as it meets the basic plugin submission guidelines. That creates the chance that two or more plugin developers used the same functions and class names, resulting in conflicts at runtime.

Such conflicts can be avoided by prefixing plugin functions and classes with a plugin related keyword. As a user of such plugins, you should be checking the function names to make sure they are unique at least within your application.

Consider the following function declarations.

Not Recommended

function get_key() {

}

Recommended

function akismet_get_key() {

}

There is no guarantee that prefixing will completely prevent conflicts, but using unique prefixes definitely reduces the chances of having duplicate functions.

Plugin Specific Tables

WordPress is flexible enough to create a wide range of web applications using its default table structure. But sometimes we need additional custom tables to provide plugin specific functionalities.

These custom tables are generally created on activation of the plugin. Most developers won’t remove these custom tables on plugin deactivation. Therefore whenever you decide to get rid of an existing plugin, you have to remove the tables from database manually to prevent unnecessary expansion of databases.

Custom databases should also include the prefix in the config file without hard coding the table names. Consider the following code for proper table naming conventions.

Not Recommended

$portfolios = $wpdb->get_results( "SELECT * FROM wp_portfolio");

Recommended

$portfolios = $wpdb->get_results( "SELECT * FROM “.$wpdb->prefix . “portfolio");

Custom sql queries are needed to access these tables since WordPress does not provide built in methods. WordPress functions used to access data from tables are optimized for better performance. So with custom tables you might have slight performance decreases as they are not optimized.

Check whether your plugin uses custom tables and make sure to consider the above guidelines when choosing a plugin.

Security and Spamming

Security is a big concern in using free plugins. We don’t exactly know the quality of the codes and what developers are doing inside these codes. Therefore it’s important to check whether a plugin contains security holes or spamming content.

• First we need to look for data validation. If the user input data is not properly validated and sanitized, anyone will be able to enter data causing damage to our sites.

• Then we need to check whether a plugin accesses sensitive data like configuration details and user details, and whether it sends them to third party applications.

• Also we need to check whether a plugin sends emails to unknown email addresses with data from your database or files.

• Some developers insert spamming content like social profile links of developer, websites, affiliate ads and links with the plugin generated output. Make sure to remove such things from the code or avoid using such plugins.

These are only few of the security concerns that plugins will have in its code. When you find something malicious in plugin codes, make sure to share it with the community to prevent other users from using such plugins.

Plugin Specific Options

WordPress plugin developers use options to retain settings and other important information related to plugins. These options are stored in the default wp_options table.

Plugins that use the same keys for its options are hard to manage without conflicts, similar to the issue with function names and classes names. It’s worse in this scenario since two duplicate option keys may not generate visible errors but be in conflict. It can be extremely difficult to figure out the exact issue.

Consider following codes for creating plugin options.

Not Recommended

update_option( 'xml', $opt );

update_option( 'social', $opt );

Recommended

update_option( 'wpseo_xml', $opt );

update_option( 'wpseo_social', $opt );

Unfortunately, the only solution I know of to this problem is to manually check whether a plugin uses prefixes for its option keys.

Direct Loading of CSS and JavaScript

Inexperienced WordPress developers tend to load their CSS and JavaScripts files directly inside the plugin. That can cause problems.

• Duplicate CSS and JavaScript files
• Increased page loading time and possibility of breaking the code.
• Includes files everywhere inside the page

On the other hand, experienced developers will use wp_enqueue_scripts action to load the files. It checks whether a library is already loaded and has any dependencies before including it in the page, preventing any duplicates.

Consider the following codes for including scripts and styles.

Not Recommended

function include_scripts_styles(){

    echo ‘<script type="text/javascript" src="jquery.js"></script>’;

    echo ‘<link type="text/css" rel="stylesheet" href="styles.css" />‘;

}

Recommended

add_action('wp_enqueue_scripts', 'wppc_scripts');
function wppc_scripts() {
    wp_enqueue_script('jquery');
    wp_register_style('sample_style', plugins_url('styles.css', __FILE__));
    wp_enqueue_style('sample_style');
}

So, you should prefer to use plugins with more organized scripts and styles loading section to prevent maintenance issues.

Conclusion

Everything included in this article here is based on my own experiences with WordPress development. I’m not aware of anyone, from committed amateur to experienced professional, who has the required experience of every available plugin and how they will operate in every possible production environment. That’s probably not even possible.

What is possible is to draw upon your professional knowledge of how code works to give yourself and your client the best possible chance to avoid issues with free WordPress plugins. There is an added responsibility to share your knowledge with others. If you detect an issue that may affect how others make use of a plugin, let the world know. Probably the best way is through the avenues provided by the plugin developer, but you should also consider just contacting the plugin author and letting them know what you found out.

I invite WordPress developers to join this conversation and include their personal experiences in using free plugins. Whate are your personal pros and cons? Have you worked out your own procedural guidelines and safety practices? Do you have rules about plugins you will or won’t use?

I look forward to your comments and suggestions.