Regex
Validates that a value matches a regular expression.
Applies to | property or method |
Class | Regex |
Validator | RegexValidator |
Basic Usage
Suppose you have a description
field and you want to verify that it
begins with a valid word character. The regular expression to test for this
would be /^\w+/
, indicating that you're looking for at least one or
more word characters at the beginning of your string:
1 2 3 4 5 6 7 8 9 10 11 12
// src/Entity/Author.php
namespace App\Entity;
use Symfony\Component\Validator\Constraints as Assert;
class Author
{
/**
* @Assert\Regex("/^\w+/")
*/
protected $description;
}
Alternatively, you can set the match option to false
in order to
assert that a given string does not match. In the following example, you'll
assert that the firstName
field does not contain any numbers and give
it a custom message:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
// src/Entity/Author.php
namespace App\Entity;
use Symfony\Component\Validator\Constraints as Assert;
class Author
{
/**
* @Assert\Regex(
* pattern="/\d/",
* match=false,
* message="Your name cannot contain a number"
* )
*/
protected $firstName;
}
Note
As with most of the other constraints, null
and empty strings are
considered valid values. This is to allow them to be optional values.
If the value is mandatory, a common solution is to combine this constraint
with NotBlank.
Options
groups
type: array
| string
default: null
It defines the validation group or groups of this constraint. Read more about validation groups.
htmlPattern
type: string|null
default: null
This option specifies the pattern to use in the HTML5 pattern
attribute.
You usually don't need to specify this option because by default, the constraint
will convert the pattern given in the pattern option into an HTML5 compatible
pattern. Notably, the delimiters are removed and the anchors are implicit (e.g.
/^[a-z]+$/
becomes [a-z]+
, and /[a-z]+/
becomes .*[a-z]+.*
).
However, there are some other incompatibilities between both patterns which
cannot be fixed by the constraint. For instance, the HTML5 pattern
attribute
does not support flags. If you have a pattern like /^[a-z]+$/i
, you
need to specify the HTML5 compatible pattern in the htmlPattern
option:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
// src/Entity/Author.php
namespace App\Entity;
use Symfony\Component\Validator\Constraints as Assert;
class Author
{
/**
* @Assert\Regex(
* pattern = "/^[a-z]+$/i",
* htmlPattern = "[a-zA-Z]+"
* )
*/
protected $name;
}
Setting htmlPattern
to the empty string will disable client side validation.
match
type: boolean
default: true
If true
(or not set), this validator will pass if the given string matches
the given pattern regular expression. However, when this option is set
to false
, the opposite will occur: validation will pass only if the
given string does not match the pattern regular expression.
message
type: string
default: This value is not valid.
This is the message that will be shown if this validator fails.
You can use the following parameters in this message:
Parameter | Description |
---|---|
{{ value }} |
The current (invalid) value |
{{ label }} |
Corresponding form field label |
5.2
The {{ label }}
parameter was introduced in Symfony 5.2.
pattern
type: string
[default option]
This required option is the regular expression pattern that the input will be matched against. By default, this validator will fail if the input string does not match this regular expression (via the preg_match PHP function). However, if match is set to false, then validation will fail if the input string does match this pattern.
normalizer
type: a PHP callable default: null
This option allows to define the PHP callable applied to the given value before checking if it is valid.
For example, you may want to pass the 'trim'
string to apply the
trim PHP function in order to ignore leading and trailing
whitespace during validation.
payload
type: mixed
default: null
This option can be used to attach arbitrary domain-specific data to a constraint. The configured payload is not used by the Validator component, but its processing is completely up to you.
For example, you may want to use several error levels to present failed constraints differently in the front-end depending on the severity of the error.