Validation Rules
Last updated Mar 5th, 2021 | 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
$290 per month—let's make that $500!
Learn moreOverview¶
Your XML schema can define validation rules using nodes in the XML that follow this pattern
The rule may have have these attributes:
- field: the field's name. (required)
- name: a unique name for this validation rule. You can have multiple validation rules for each field. (required)
- Type: can be "callable", "preg_match" or "xPDOValidationRule" (required)
- rule: varies depending on the type. For type=callable, this will be the name of the callback function. For type=preg_match, this will be the regular expression. For type=xPDOValidationRule, a valid child class must be supplied. (required)
-
value: an optional argument to pass to the validation functions, e.g. when the type is
xPDOValidationRule
and the rule is a class that extends it. (optional) - message: this is a string describing the the validation rule if it fails. (required) In MODX 2+, the message field contains a lexicon string which can provide language specific message translations.
Regex Validation¶
Let's take this example from the modChunk schema:
Callable Validation¶
You can use your own functions for validation purposes by using "callable" as the type -- this relies on PHP's call_user_func() function. Because the function name is defined in XML where it is impossible to reference an object instance, you can only reference a regular PHP function like my_function
or a static class method, e.g. MyClass::myFunction
. Additionally check this 'callable' Rule
xPDOValidationRule Validation¶
This is how you can tie-into the built-in MODX validation rules. See the classes available inside the core/xpdo/validation/xpdovalidator.class.php
file:
- xPDOMinLengthValidationRule
- xPDOMaxLengthValidationRule
- xPDOMinValueValidationRule
- xPDOMaxValueValidationRule
- xPDOObjectExistsValidationRule
- xPDOForeignKeyConstraint
For example, look a the the rule defined for the modContentType
Using xPDOValidator¶
You can use the xPDOValidator to pre-validate the current state of an xPDOObject
or you can allow save()
to call validation (see xPDO::OPT_VALIDATE_ON_SAVE
) itself and fail if validation fails.
An example of pre-validation from MODX Revolution's modObjectCreateProcessor
class:
An example of examining the validation messages after save()
failure from MODX Revolution's modError
class:
Writing Your Own Validation Rules¶
If you want to write your own validation rules, you need to create a PHP class file inside of your namespace's model folder for each validation rule you define, e.g. core/components/my_pkg/model/my_pkg/my_validation_rule.class.php
. The name should be all lowercase and include a .class.php
extension. This is how xPDO knows how to find your class file (this is xPDO's "autoload-like" convention).
Let's look at a Custom Resource Class (CRC) that does not want to be nested under other CRC's -- it wants as its parent only the built-in MODX classes (modDocument, a WebLink, etc). Here's its XML schema definition:
And here's the corresponding validation rule from core/components/my_pkg/model/my_pkg/normalparents.class.php
:
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
$290 per month—let's make that $500!
Learn more