Creating Plugins

While the Barebones CMS is primarily designed for Widgets and Shortcodes, the main editor also offers extensibility through plugins. In theory, very few plugins should exist for Barebones CMS. Widgets and Shortcodes can handle about 95% of most needs.

Plugins for Barebones CMS are only available from inside the main Barebones CMS editor. They are not available for the frontend (what users see). This is an important distinction from Widgets and Shortcodes, which have both frontend and editor aspects. As a result, the "usefulness" of plugins are limited to mostly system admin sorts of tasks. Although plugins can also be creatively used to accomplish such tasks as making "good enough" translations of the Barebones CMS editor.

Your First Plugin

Creating a plugin is a fairly simple procedure. The most common form of plugin is an IP restricting plugin to keep hackers out of the system. Let's take a look at such a plugin:

	function Plugin_IPRestrict()
		if ($_SERVER["REMOTE_ADDR"] != "")
			echo "Invalid credentials.";

	BB_AddPluginAction("plugins_loaded", "Plugin_IPRestrict");

In this example, the function Plugin_IPRestrict() is registered with the "plugins_loaded" hook, which is called right after plugins are loaded and before the user accounts are loaded. Here's the relevant source code in 'edit.php':

	// Load plugins.
	$plugins = BB_GetPluginList();
	foreach ($plugins as $file)  require_once ROOT_PATH . "/" . PLUGIN_PATH . "/" . $file . "/index.php";


	// Make sure an account is loaded.  Using REQUEST allows automation and Flash-based uploads to work.

Notice how plugins that use the "plugins_loaded" hook are called with the BB_RunPluginAction() function. Plugins register their functions with hooks by calling BB_AddPluginAction() and then BB_RunPluginAction() executes all functions that have registered for that hook.

Creating a plugin is a combination of three steps:

The hardest part of that process is locating the correct hook and knowing what to do with it. There is no good way to document this procedure other than understanding the Execution Path and looking at the surrounding code to see if the code is doing something that needs to be changed. What follows are general guidelines of how plugin callbacks are structured.

General Guidelines

In general, official Barebones CMS editor components have plugin callbacks. It is good practice to introduce as many reasonable plugin hooks as possible. The main Barebones CMS editor and widgets have several hundred hooks available that are hopefully intuitive.

It is possible to create a plugin that tracks all plugin hook calls. This is done by registering a callback with the special "global_action" hook for BB_RunPluginAction() and "global_action_info" hook for BB_RunPluginActionInfo(). This is very useful if you want to, for example, log a path of execution within the editor to a file. Plugins using the registered global hooks slow down the editor a bit.

Most of the main editor hooks follow a fairly simple formula: An optional "pre_" or "post_" prefix followed by the current $_REQUEST["bb_action"] followed by another optional "_something". There are also a few hooks prior to entering the main processing area (e.g. "plugins_loaded").

The official Widgets and Shortcodes also follow a similar formula. The important thing is that all hooks are uniquely named. The chosen approach offers a good balance between readability, uniqueness, and future-proofing.

Plugins go into their own subdirectory under the 'plugins' directory in an 'index.php' file. The naming of the subdirectory does not matter but the 'bb_' prefix is reserved for official use.

When naming functions that hook a plugin, the function should have a name like 'Plugin_[YourPluginName]' and then anything after that, if necessary (i.e. if you are creating more than one callback function). This approach helps avoid naming conflicts.

Plugins may offer their own hooks by calling BB_RunPluginAction() or BB_RunPluginActionInfo() from within their callbacks. However, global hook callbacks may not do this. That would result in infinite recursion and crash PHP.

This all said, plugins are generally for non-user interface solutions to problems or when Widgets or Shortcodes won't suffice. Always attempt to find a Widget or Shortcode solution first.

© CubicleSoft