Building a Basic Plugin

In order to make plugin building as streamlined as possible we build our plugins out of Bacon. Bacon is a framework built as WordPress library of mu-plugins. In the mu-plugins directory is a plugin-stub that contains the basics for building a discreet plugin.

Simply cd into your plugins directory and execute the following;

cp -r ../mu-plugins/plugin-stub hm-new-plugin-name

Upon completion enter the rd-new-plugin-name directory and edit plugin.php identifier block and rename the class as appropriate. Remember to properly instantiate your new plugin or you will cause a PHP FATAL execution error, resulting in a White Screen of Death (WSOD).

If you intend on including other assets like css, fonts, images, javascript you should follow the standard plugin file system hierarchy (see below).

Using this hierarchy ensures consistency and familiarity for the rest of the development team. The goal of using a framework is to work within it’s confines because consistency helps reduce long term technical debt. The Bacon framework has been designed to ensure flexibility while promoting PHP clean coding standards.

Most plugins and their internal files will extend the WP_Base class. Following this convention ensure we use the standard methods and format for registering CSS & JS. Depending on the location with you classes registration method for example if you are registering JS withing the plugin.php in the root of you plugin then you would define the file spec as follows:

const FILE_SPEC = FILE;

However is this were to happen in a php file inside of inc then use the DIR magick constant. In either case this simple constant sets up the built-in get_asset_url() method.

const FILE_SPEC = DIR; 
public function register_scripts() { 
  wp_register_script( 
    self::SCRIPT_NAME, 
    $this->get_asset_url( self::SCRIPT_FILE ), 
    $this->depends, 
    self::VERSION, 
    self::IN_FOOTER 
  ); 
  wp_enqueue_script( self::SCRIPT_NAME );
}

Also note the expanded the function call structure. We have found that expanding the call out like this reduces eye strain and greatly enhances code review efficiency.

Finally observe the named constants. We do this to ensure maximum readability and expedited interpretation. Take the last parameter to wp_register_script() which is a bool and depending upon whether it is set to true of false changes the destination of the script when it is finally enqueued. When you are writing or reviewing code you honestly should not waste time trying to remember the difference. By using the constant we have clearly defined the value as well the intended outcome in an unchanging manner.