Decoupling Logic in MODX: When to Use Snippets vs. Plugins

The Conflict: Logic in the Template vs. Logic in the System

When building a site in MODX Revolution, you often hit a crossroads: do you need a piece of data to appear in a specific spot on a page, or do you need a process to happen automatically in the background? Choosing the wrong tool—putting a background process in a Snippet or a display element in a Plugin—leads to redundant code, slower page loads, and a CMS that is difficult to debug.

The core takeaway is that Snippets are for output (what the user sees) and Plugins are for behavior (what the system does). Mixing these roles breaks the separation of concerns and makes your site harder to maintain.

Snippets: The Dynamic Content Engine

Snippets are PHP scripts stored in the database that execute during the rendering process. They are called directly within a resource (page) or a Chunk (HTML template) using the [[SnippetName]] syntax. Because they return a string, they are ideal for fetching data from the MODX API and injecting it into the HTML.

To keep Snippets maintainable, you should avoid writing HTML directly inside the PHP. Instead, use the Snippet to process logic and then pass that data into a Chunk. This allows a designer to edit the layout without touching the PHP code.

Plugins: The Event-Driven Backbone

Unlike Snippets, Plugins are not called by the template. They are triggered by System Events. An event is a specific hook in the MODX lifecycle, such as OnDocFormSave (triggered when a page is saved) or OnHandleRequest (triggered when a page is requested).

Plugins are the correct choice for business logic that must happen regardless of which page is being viewed, such as synchronizing a resource with an external API or enforcing custom permission checks before a page renders.

Worked Example: Implementing a Custom 'Last Updated' Notification

Imagine you want to notify an administrator via email every time a specific category of resources is updated. Doing this in a Snippet is impossible because a Snippet only runs when the page is viewed, not when it is saved.

Implementation Steps:

1. Navigate to Elements → Plugins in the MODX Manager.
2. Create a new Plugin and name it NotifyAdminOnSave.
3. Set the System Event to OnDocFormSave.
4. Enter the following code (assuming you have the required PHP mail permissions on your server):

get('class_pfolder') == 'News') {
    $resourceName = $resource->get('pagetitle');
    $userId = $resource->get('editedby');
    $message = "Resource '{\$resourceName}' was updated by User ID: {\$userId}.";
    
    // Use PHP mail or a MODX-compatible mailer
    mail('[contact removed]', 'Resource Updated', $message);
}
?>

Verification: To test this, edit a resource within the 'News' folder and save it. Check the admin email inbox. If the email arrives, the Plugin is correctly hooked into the system event.

Trade-offs and Performance Risks

While the MODX API is powerful, there are two primary risks to consider:

• Database Overhead: Because Snippets and Plugins are stored in the database, they are not naturally tracked by Git. For larger projects, this creates a version control gap. You can mitigate this by using the Transport Packages (Extras) system to export and import your logic across environments.
• Synchronous Execution: Both Snippets and Plugins execute synchronously. If a Plugin makes a slow API call to an external server during OnHandleRequest, the user will see a white screen until that call completes. For heavy lifting, consider offloading the task to a cron job or an external queue.

Checking Your Implementation

To verify that your logic is executing without causing silent failures, check the MODX Error Log (Reports → Error Log). If a Snippet fails, it often returns an empty string or a PHP error that will be logged here. If a Plugin fails during a system event, it may prevent the resource from saving entirely, which will also be captured in the log.