Best Practices

Standard
[display-posts post_type="content" id="3672" include_content=true include_title=false wrapper="div" wrapper_class=""]

Best Practices

Here are some best practices to help in organizing your code so it works well alongside other WordPress plugins and WordPress core.

Prefix Everything #

All files, variables, and functions should be prefixed with a unique identifier. Prefixes prevent other plugins from overwriting your variable values or accidentally calling your functions. It will also prevent you from doing the same. Adding the initials of your plugin name or your name is a good start.

Here are a few examples of using prefixes in code.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
if ( !function_exists('myplugin_init' ) ) {
     function myplugin_init() {
          register_setting( 'myplugin_setting_example', 'foo' );
          register_setting( 'myplugin_setting_demo', 'bar' );
     }
}
 
if ( !function_exists( 'myplugin_get_demo_setting' ) ) {
     function myplugin_get_demo_setting() {
          return get_option( 'myplugin_setting' );
     }
}
 
/* File path: settings/myplugin_example.php */

Top ↑

File Organization #

The root level of your plugin directory should contain your plugin-name.php and, optionally, your uninstall file. All other files should be organized into folders whenever possible.

It’s also helpful to separate your admin code, and use the conditional is_admin to prevent it from loading when not needed. For example, in your main plugin file you might have the following:

1
2
3
4
5
6
if ( is_admin ) {
     // We are in admin mode
     require_once( dirname(__file__).'/admin/myplugin_admin.php' );
}
?>

Folder Structure #

A clear folder structure helps you and others working on your plugin. Keep similar files together. For example, place JavaScript files in a /js folder, style sheets in a /css folder, and images in an /images folder.

Here’s a sample folder structure for reference:

/my-plugin-name
     my-plugin-name.php
     uninstall.php
     /admin
     /js
     /css
     /images
     /includes
     /settings

Top ↑

Plugin Architecture #

The architecture, or code organization, you choose for your plugin will likely depend on the size of your plugin. For small, single-purpose plugins that only have a small interaction with WordPress Core, themes or other plugins, there’s little benefit in over-engineering it into a one or more classes, unless you know the plugin is going to expand greatly later on.

Large plugins with lots of groupable code, starting off with an end goal in mind of classes, separate style and scripts files, and even build-related files may help code organization and long-term maintenance of the plugin.

Top ↑

Architecture Patterns #

While there are a number of possible architecture patterns, they can broadly be grouped into three variations:

Top ↑

Architecture Patterns Explained #

Specific implementations of the more complex of the above code organizations have already been written up as tutorials and slides:

Top ↑

Boilerplate Starting Points #

Instead of starting from scratch for each new plugin you write, you may want to start with a boilerplate. The advantage of using a boilerplate is consistency among your own plugins, and for commonly used boilerplates, a format that other plugin contributors would also recognize.

These also serve as further examples of different yet comparable architectures.

Of course, you could take different aspects of these and others to create your own custom boilerplate.

 
Skip to toolbar