Make Plugins Execute Based on Resource Fields

Enable or disable plugins based on the values of specific resource fields


In the previous article, we looked at how to enable or disable Manager plugins based on context of the resource being edited or updated. In this one, we'll look at restrictions based on other fields of the resource.


MODX logo

Using Resource Fields to Enable or Disable Plugins

Since all of the resource fields are available in a resource-related event in the Manager like OnDocFormPrerender, or OnWebPagePrerender in the front end, you can use any of them to control your plugin.

The most common form of this is to restrict the plugin based on the parent of the current resource, so the plugin will only execute when editing or updating resources in a particular parent folder. Putting this code at the top of the plugin would do that:

This code would go in a plugin attached to a Manager event, usually OnDocFormPrerender.

if (isset($resource)) {
    $allowedParent = 12;
    $parent = $resource->get('parent');
    if ($parent !== $allowedParent) {
       return;
    }
}

We can still use the strict inequality test here (!==) because the parent field will always hold an integer. Be careful, though, because that operator requires that the two sides both be of the same type, so if we had used $allowedParent = '12', the test would never pass because one side is a string and the other is an integer. Some people like to use code like this, which forces the $parent to be an integer: if ($parent !== (int) $allowedParent).

Others would use the non-strict operator (!=), which doesn't require that the two sides be the same type. When comparing numeric values (string or integer), both != and ==, will convert both sides to integers for the comparison.

Note that we've used (int) to "cast" the parent's ID value to an integer. This is not strictly necessary if you want to use a strict comparison if you use 12 instead of '12' or "12" for the value of $allowedParent since MODX will return an integer for the parent ID. It's not a bad practice, though, since it will protect you if you forget and use a string for the value. Casts are very fast, so the execution penalty is trivial.

If you want to *disable* the plugin for children of a single parent folder, you'd do this:

if (isset($resource)) {
    $disAllowedParent = 12;
    if ($resource->get('parent') == $disAllowedParent) {
       return;
    }
}

Multiple Parents

To enable a plugin for children of multiple parents:

if (isset($resource)) {
    $allowedParents = array(12,22,34);
    $parent = $resource->get('parent');

    if (! in_array($allowedParents, $parent) {
       return;
    }
}

If you want the plugin to execute for resources at the root of the Resource tree, you can add 0 to the $allowedParents array.

To disable a plugin for children of multiple parents:

if (isset($resource)) {
    $disAllowedParents = array(12,21,43);
    $parent = $resource->get('parent');
    if (! in_array($disAllowedParents, $parent) {
       return;
    }
}

As with the code above, if you want to block execution for resources at the root of the Resource tree, you can add 0 to the $allowedParents array.

For both versions, if your plugin is connected to a resource-related event like OnDocFormPrerender you can count on the $resource variable being set. Be careful, though, if your plugin is attached to other events. If the $resource variable is not set, the plugin will crash. Adding a sanity check using if(isset($resource)) or if(!isset($resource)) will prevent disaster.

Make sure that if the $resource variable is not set, no plugin code that uses that variable will execute.

In some cases where the plugin is tied to multiple events, you may need to add a further test like this one:

if ($modx->event->name !== 'OnDocFormPrerender) {

}

Using other Resource Fields

The technique described above will work with any Resource field. You can restrict your plugin based on the resource's context, template, isfolder status, createdby, or any other resource field. The full list of resource field names is available here.

Pay attention to the type of the field if you use a strict comparison operator and be aware that the integer fields like parent, createdby, and template will contain the ID not the name of the parent, template, or user.

The boolean fields like isfolder, published, and deleted will always return true or false.

You might expect that the timestamp fields like editedon and publishedon would return a unix timestamp, but they don't. MODX will automatically convert them to a human-readable date string like: "2019-07-01 00:10:01". If you need to make a date comparison, you'll need to convert them back to timestamps with strtotime().

If you misspell the field name (i.e., 'isFolder'), the get() call will return NULL. Field names never contain upper-case letters, though a few also have underscores like context_key and class_key.


Restricting Plugins in the Front End

Using the code above in the front end of the site usually won't work because in front-end events like OnWebPagePrerender, OnWebPageInit, etc., the $resource variable will not be set. For front-end plugins, the simplest solution for this is to add this line at the top of your plugin:

$resource = $modx->resource;

That way, you can use the code above as is.

In the very rare situation where your plugin will execute in both the front end and in the Manager, you can use this code at the top:

if (! isset($resource)) {
    $resource = $modx->resource;
}

Coming Up

In the next article, we'll see how to disable or enable plugins in the Manager based on the value of a TV.



Looking for high-quality, MODX-friendly hosting? As of May 2016, Bob's Guides is hosted at A2 hosting. (More information in the box below.)



Comments (0)


Please login to comment.

  (Login)