Exploring MODx From the Inside: How MODx Plugins Work

How MODx Plugins Work

Plugins are custom code that is inserted at specified points in the various processes of the core of MODx. They make use of event functions that are sprinkled throughout the parser and the other processing scripts, such as displaying the forms for creating or editing documents, saving documents, snippets, etc. and at various points during user logins. In this manner it is possible to customize the core behavior of MODx without changing the core scripts.

Plugins are created in the same manner as most other MODx content; there is a form with a few fields for its name, a description, and a textarea field for the plugin code. The key to using a plugin is the System Events tab. This tab contains checkboxes enabling the plugin to "listen" as it were for whatever events are checked. The code in the plugin is executed at the point in the MODx script where that event function is specified.

Third-party snippets can also use this "event" model to allow customization without actually hacking the original script. One such snippet is the WebLogin snippet. Another snippet is the TreasureChest e-commerce snippet. These snippets make use of plugins by inserting their event names into the system_eventnames table in the MODx database on installation, and calling the invokeEvent function.

Creating a Plugin

To create a plugin, go to Resources, Manage Resources in the main manager menu.

Create Plugin

The Configuration tab has four fields:

The System Events tab is where you select the event or events you want your code to intercept.

System Events Tab

Standard plugin code

While you can just have your plugin's code in the plugin itself, it is often better to use external .php files and have your plugin code include the external file:

include '../assets/plugins/myPlugin/myPlugin.php';

While you can code a function any way you are comfortable, it is a good idea to use the Event object so that you can take advantage of the features of the Event object. If you will be using more than one event in your plugin, then a switch statement will let you catch which one is being triggered.

// Get a reference to the event
$e = & $modx->Event;
switch ($e->name) {
   case "OnDocFormRender":
       include $path.'docform.inc.php'; //$path is from configuration
    break;
}

If your code includes function definitions, you need to declare the $modx object global at the beginning of your function definition in order for all of the API functions to be available.

function myFunction() {
    global $modx;
...
}

If you wish your plugin to display something on the finished page, load the output into a variable such as $output, then use the Event class function $e->output($output). The plugin processing code will return the variable's content, adding it to the content of whatever you are modifying. An example of this can be seen in the Bottom Button Bar plugin, which adds the Save/Duplicate/Delete/Cancel buttons at the bottom of most of the Manager resource editing pages.

// Add the new bar to the output
$e->output($output);

There are several plugins included with the default MODx installation, so you can open them for editing and look at the code to get examples and ideas. They were all written by different people, so they often have different structures. You can choose a structure that suits your coding style best; they all work just the same.

Plugin code is processed using the PHP eval() function.

Available Data

It is important to be aware of what data is available at various events. For example, the OnPageUnauthorized event is invoked just before the $modx->documentObject array is created. This makes sense, because if the viewer doesn't have permission to view the page and is being sent to the unauthorized page, there's no need to further process the document. So while the $modx->documentIdentifier is available, a plugin using this event would need to do its own database query to get any further information about this document. However, the core arrays and objects, such as the $modx object, the $modx->db object and the $modx->config[] array are available.

The PHP system arrays are always available, such as $_POST, $_COOKIE and $_SESSION.

Comment On This Article

Do you find something unclear? Did I miss something or get something wrong? What do you like or not like about this chapter? Please do not ask for help here; use the forums if you need help.


If you have trouble reading the code, click on the code itself to generate a new random code.
Security Code:
 
Guest
Comment
Sun October 25, 2009, 10:11:56
Thanks
Guest
Comment
Thu September 10, 2009, 20:31:56
I really like your style and comments, but one thing that's bothering me is that you write all of your code and just include it. While I understand this, it doesn't give us code to look at in context. Such as API calls and other tools necessary.

For example, I'm trying to learn to write a plugin to make a decision based on a template variable and display certain content. I'm sure you've done just that, and included it as a php include. However it doesn't cover any of that and as we all know modx isn't very well documented.

Your stuff is great, but specific examples beyond just 'write your code externally and include it' isn't enough for us dummies.

Thanks