Step 4 - Processors
Last updated Dec 8th, 2019 | Page history | Improve this page | Report an issue
Support the team building MODX with a monthly donation.
The budget raised through OpenCollective is transparent, including payouts, and any contributor can apply to be paid for their work on MODX.
Backers
Budget
$311 per month—let's make that $500!
Learn moreThis tutorial is part of a Series:
- Part I: Creating a Custom Resource Class
- Part II: Handling our CRC Behavior
- Part III: Customizing the Controllers
- Part IV: Customizing the Processors
This is a bit of bonus material to help identify some of the things you can do by extending the default processors.
Extending the Processors for our CRC¶
Extending the Processors for our CopyrightedResource is fairly simple. Load up your copyrightedresource.class.php file that contains your main class, and at the top, put this:
require_once MODX_CORE_PATH.'model/modx/modprocessor.class.php';
require_once MODX_CORE_PATH.'model/modx/processors/resource/create.class.php';
require_once MODX_CORE_PATH.'model/modx/processors/resource/update.class.php';
This tells MODX to load some base classes that we'll need – yes, we're sort of double-dipping here. Because our main class file is on MODX's radar and will be included when MODX loads, we just can require more files from there. At the bottom of the same file, after your CopyrightedResource class, put this:
class CopyrightedResourceCreateProcessor extends modResourceCreateProcessor {
}
class CopyrightedResourceUpdateProcessor extends modResourceUpdateProcessor {
}
Now we've overridden the processors for our class; MODX will automatically use these classes as the processor class when creating or updating our CRC. We can then override methods to provide custom functionality for our CopyrightedResource class. For example, here is a stub for our CopyrightedResource class and the Update processor that shows some methods that you could override:
class CopyrightedResourceUpdateProcessor extends modResourceUpdateProcessor {
/**
* Do any processing before the fields are set
* @return boolean
*/
public function beforeSet() {
$beforeSet = parent::beforeSet();
/* force all Copyrighted Page CRCs to be cacheable always */
$this->setProperty('cacheable',true);
return $beforeSet;
}
/**
* Do any processing before the save of the Resource but after fields are set.
* @return boolean
*/
public function beforeSave() {
$beforeSave = parent::beforeSave();
if ($this->object->get('longtitle') == 'Send an Error') {
$this->addFieldError('longtitle','Specify a different longtitle!');
}
/* force CopyrightedResource objects to always be non-folders */
$this->object->set('isfolder',false);
return $beforeSave;
}
/**
* Do any custom after save processing
* @return boolean
*/
public function afterSave() {
$afterSave = parent::afterSave();
$this->modx->log(modX::LOG_LEVEL_DEBUG,'Saving a Copyrighted Page!');
return $afterSave;
}
}
These are just trivial examples, but hopefully you get the idea. If you've been paying close attention to our examples on these pages, you may have noticed that we set some properties in the CopyrightedResource class (class_key), and we set others in CopyrightedResourceUpdateProcessor (cacheable, isfolder). This may leave you confused as to where you should modify a behavior – in the resource child class? In the controller class? or in the processor?
If the attribute is something that can be controlled by the GUI, then you'll have to do some customizations in the processors.
Extra Attributes¶
There are some attributes that are not in the modx_site_content
table. See the comments in the modresource.class.php file for a list of attributes. You can set them in your resource class via the set method, e.g.:
$this->set('show_in_tree',false);
$this->set('hide_children_in_tree',true);
You can customize the icon used in the MODX resource by creating a System Setting named after your custom resource class: mgr_tree_icon_ + strtolower($class_key)
. Set its value to CSS class that will be used.
Conclusion¶
And that's about it! There's obviously tons of possibilities with CRCs, and you can really go nuts on the customization that you can apply to them and their processing and rendering logic. Have fun!
Support the team building MODX with a monthly donation.
The budget raised through OpenCollective is transparent, including payouts, and any contributor can apply to be paid for their work on MODX.
Backers
Budget
$311 per month—let's make that $500!
Learn more