Deconstructing the Plugin Boilerplate

Object Model

The basic object model for the plugin

  • plugin: main plugin object
  • public: all public facing code
  • admin: all admin code
  • loader:
  • activator:
  • deactivator

Main Plugin Folder

If your have used the boilerplate generator (see Plugin Boilerplate) you will have a folder given the name that you provided for your plugin. This folder contains the following:

When loaded, the plugin …

Public vs Admin

The Plugin Boilerplate folder structure separates code that is for admin (used when logged in to WordPress and using the Dashboard) form public facing code (used when the site is being visited or viewed).

Admin: http://your-site.com/wp-admin/… e.g. code to display a screen to edit plugin settings.
Public: http://your-site.com/… e.g. code to display an element within a web page or post.

Code that is used for both admin and public functionality, or cannot be considered as either, is kept in the boilerplate includes folder.

The admin and public folder structures are the same:

The class php files contain most of the plugin code

Tracing what happens

Using WordPress debugging (see debugging post ) we can place trace messages within functions and methods and trace calls to these functions and methods. For example, using the log_me() function we can place trace messages in:

plugin-name/includes/class-plugin-name-activator.php
plugin-name/includes/class-plugin-name-deactivator.php
plugin-name/uninstall.php

If we then install, activate, deactivate, and uninstall our plugin we will see the trace of calls in the debug.log.