Creating a plugin for WooCommerce

Want to create a plugin to extend WooCommerce? Plugins are essentially the same as regular WordPress plugins so for information on writing them see Writing a plugin

Check if WooCommerce is active ↑ Back to Top

Most WooCommerce plugins won’t need to run unless WooCommerce is already active. You can wrap your plugin in a check to see if WooCommerce is installed or not:

 * Check if WooCommerce is active
if ( in_array( 'woocommerce/woocommerce.php', apply_filters( 'active_plugins', get_option( 'active_plugins' ) ) ) ) {
    // Put your plugin code here

Main file naming ↑ Back to Top

The main plugin file should take the name of the plugin directly. E.g. a plugin called woocommerce-some-plugin would have it’s main file named woocommerce-some-plugin.php

Textdomains ↑ Back to Top

To follow the guidelines in, the text domain should match your plugin folder name. E.g. a plugin called woocommerce-some-plugin would have the text domain woocommerce-some-plugin. No underscores.

Follow WordPress PHP Guidelines ↑ Back to Top

WordPress has a set of guidelines to make all WordPress code consistent and easier to read. This includes quotes, indentation, brace style, shorthand php tags, yoda conditions, naming conventions, and a whole bunch more. Please read through the guidelines as they are very important so anyone can read your code.

These code conventions also prevent you from making dumb mistakes (like Apple did with iOS 7.0.6).

Custom Tables ↑ Back to Top

Creating custom tables should be avoided. If possible, you should always use WordPress custom post typestaxonomies, and options.

Prevent Data Leaks ↑ Back to Top

You should always try to prevent direct access data leaks. Add this line of code after the opening PHP tag in each PHP file:

if ( ! defined( 'ABSPATH' ) ) { 
    exit; // Exit if accessed directly

Readme ↑ Back to Top

All plugins should have the standard WordPress readme.

Use WordPress / WooCommerce UI ↑ Back to Top

It’s important to have a consistent UI across plugins than have totally different UIs for each plugin. All plugins should be hooked into the WordPress / WooCommerce UI. Application data should be loaded via API instead of via an iframe.

If you’re integrating a plugin with WooCommerce we strongly recommend that you use the WC_Integration class.

Make it Extensible ↑ Back to Top

Developers should use WordPress actions and filters to allow for easy modification / customization of their items without users having to touch the plugin’s core code base.

Additionally, if your plugin creates a front-end output, it’s recommended to have some sort of templating engine in place so that users of the plugin can create custom template files in their theme’s woocommerce folder that will overwrite the plugin’s template files.

For more information, check out Pippin’s post on Writing Extensible Plugins with Actions and Filters.

Remove Unused Code ↑ Back to Top

With version control there’s no point in leaving commented out code in the plugin. It must makes it annoying to scroll through and read the code. Remove it and add it back in later if you need it.

Comment! ↑ Back to Top

If you have a function what does the function do? There should be comments for most if not every function in your code. Someone (including yourself) may want to modify your code and comments are very helpful for that. We recommend using PHP Doc Blocks similar to WooCommerce.

Avoid God Objects ↑ Back to Top

God Objects are objects that know too much or do too much. The whole point of object oriented programming is taking a large problem and breaking it down into smaller parts. By having functions do too much it’s hard to follow that logic and a bug will be much harder to fix. Instead of having a couple massive functions break them down into smaller pieces.

Test Your Code with WP_DEBUG ↑ Back to Top

You should always develop with WP_DEBUG mode on so you can see all of the PHP warnings that are sent to the screen. It’s usually simple things like making sure a variable is set before checking the value.

Separate Business Logic & Presentation Logic ↑ Back to Top

It’s a good practice to separate business logic (ex. how the plugin works) from presentation logic (ex. how it looks). Two separate pieces of logic are more easily maintained and swapped out if necessary. A simplistic example would be have two different classes one for displaying the end results and one for the admin settings page.

Use Transients to Store Offsite Information ↑ Back to Top

If you provide some sort of service via an API it’s best to store that information so that future queries will be done much faster and the load on your service is lessened. You can use WordPress transients to store data for a certain amount of time.

Back to the top