Symfony 4 Forms: Build, Render & Conquer!


UniqueEntity & Validation Directly on Form Fields

With a Subscription, click any sentence in the script to jump to that part of the video!

Login Subscribe

The registration form works, but we have a few problems. First, geez, it looks terrible. We'll fix that a bit later. More importantly, it completely lacks validation... except, of course, for the HTML5 validation that we get for free. But, we can't rely on that.

No problem: let's add some validation constraints to email and plainPassword! We know how to do this: add annotations to the class that is bound to this form: the User class. Find the email field and, above, add @Assert\NotBlank(). Make sure to hit tab to auto-complete this so that PhpStorm adds the use statement that we need on top. Also add @Assert\Email().

... lines 1 - 14
class User implements UserInterface
... lines 17 - 23
... lines 25 - 26
* @Assert\NotBlank()
* @Assert\Email()
private $email;
... lines 31 - 248

Nice! Move back to your browser and inspect the form. Add the novalidate attribute so we can skip HTML5 validation. Then, enter "foo" and, submit! Nice! Both of these validation annotations have a message option - let's customize the NotBlank message: "Please enter an email".

... lines 1 - 23
... lines 25 - 26
* @Assert\NotBlank(message="Please enter an email")
... line 28
private $email;
... lines 31 - 250

Cool! email field validation, done!

Unique User Validation

But... hmm... there's one other validation rule that we need that's related to email: when someone registers, we need to make sure their email address isn't already registered. Try [email protected] again. I'll add the novalidate attribute so I can leave the password empty. Register! It explodes!

Integrity constraint violation: duplicate entry "[email protected]

Ok, fortunately, we do have the email column marked as unique in the database. But, we probably don't want a 500 error when this happens.

This is the first time that we need to add validation that's not just as simple as "look at this field and make sure it's not blank", "or a valid email string". This time we need to look into the database to see if the value is valid.

When you have more complex validation situations, you have two options. First, try the Callback constraint! This allows you do whatever you need. Well, mostly. Because the callback lives inside your entity, you don't have access to any services. So, you couldn't make a query, for example. If Callback doesn't work, the solution that always works is to create your very own custom validation constraint. That's something we'll do later.

Fortunately, we don't need to do that here, because validating for uniqueness is so common that Symfony has a built-in constraint to handle it. But, instead of adding this annotation above your property, it lives above your class. Add @UniqueEntity. Oh, and notice! This added a different use statement because this class happens to live in a different namespace than the others.

This annotation needs at least one option: the fields that, when combined, need to be unique. For us, it's just email. You'll probably want to control the message too. How about: I think you've already registered.

... lines 1 - 7
use Symfony\Bridge\Doctrine\Validator\Constraints\UniqueEntity;
... lines 9 - 12
... line 14
* @UniqueEntity(
* fields={"email"},
* message="I think you're already registered!"
* )
class User implements UserInterface
... lines 21 - 255

Oh, and just a reminder: if you have the PHP annotations plugin installed, you can hold command or control and click the annotation to open its class and see all its options.

Let's try it! Move over and refresh! Got it! That's a much nicer error.

Adding Validation Directly to Form Fields

There is one last piece of validation that's missing: the plainPassword field. At the very least, it needs to be required. But, hmm. In the form, this field is set to 'mapped' => false. There is no plainPassword property inside User that we can add annotations to!

No problem. Yes, we usually add validation rules via annotations on a class. But, if you have a field that's not mapped, you can add its validation rules directly to the form field via a constraints array option. What do you put inside? Remember how each annotation is represented by a concrete class? That's the key! Instantiate those as objects here: new NotBlank(). To pass options, use an array and set message to Choose a password!.

Heck, while we're here, let's also add new Length() so we can require a minimum length. Hold command or control and click to open that class and see the options. Ah, yea: min, max, minMessage, maxMessage. Ok: set min to, how about 5 and minMessage to Come on, you can think of a password longer than that!

... lines 1 - 12
class UserRegistrationFormType extends AbstractType
public function buildForm(FormBuilderInterface $builder, array $options)
... lines 18 - 20
->add('plainPassword', PasswordType::class, [
'mapped' => false,
'constraints' => [
new NotBlank([
'message' => 'Choose a password!'
new Length([
'min' => 5,
'minMessage' => 'Come on, you can think of a password longer than that!'
... lines 35 - 41

Done! These constraint options will work exactly the same as the annotations. To prove it, go back and refresh! Got it! Now, validating an unmapped field is no problem. We rock!

Next: the registration form is missing one other field: the boring, but, unfortunately, all-important "Agree to terms" checkbox. The solution... is interesting.

Leave a comment!

  • 2018-12-31 Victor Bocharsky

    Hey Leif,

    Yes, you're correct! It's required by design by validator. Though, you can bypass allowing entity to be in invalid state with form DTO: - it will be further in this course. But this way requires more work, so it's still controversial question.

    Thank you for sharing your solution with others btw!


  • 2018-12-30 Leif__

    Why am I getting 500 errors instead of just showing the errors to the user ?

    InvalidArgumentException HTTP 500 Internal Server Error
    Expected argument of type "string", "NULL" given at property path "username".

    I have the Assert on the User and using the same code as you
    @Assert\NotBlank(message="Please enter a username")

    Edit : Turns out you need to allow your class to be in an invalid state to let Symfony manage errors for forms bound to entities. You have to set the return type of your methods to "?string" for example, even if the property is required and should never be null. This lets Symfony set the property to an invalid value (like null for an email adress) and then errors will show up on your form

  • 2018-11-20 weaverryan

    Hey Peter Kosak!

    > First one is regarding custom validation. I would like to have a password that contains at least 8 characters and then at least 1 upper, 1 lower, 1 number & 1 special character? How would I do this? I believe I need some sort of my own validator.

    I would either use the Regex constraint ( or the Callback constraint... if the Regex is too ugly :).

    > Second question is controlling some Validation Annotation in entity by software settings(.env) for example.

    THIS *would* require a custom validation constraint (which we do talk about later in this tutorial). With a custom validation constraint, you have a "validator", which is a service. Because of that, we can use dependency injection to "inject" your custom rules, for example, from .env. This would mean, for example, that you would have some new @Password annotation, which would ultimately call your custom validation constraint, where you could apply the dynamic logic.

    Let me know if this all makes sense! Cool questions!


  • 2018-11-19 Peter Kosak

    Hi Ryan,

    I have 2 questions:
    First one is regarding custom validation. I would like to have a password that contains at least 8 characters and then at least 1 upper, 1 lower, 1 number & 1 special character? How would I do this? I believe I need some sort of my own validator.

    Second question is controlling some Validation Annotation in entity by software settings(.env) for example.
    Lets say at the moment application supports maximum 8 characters. So I have in my entity NotBlank max 8 but now other client decided to support 9 characters. Obviously I dont want to create another version where the only difference will be NotBlank max 9 Annotation.

    Would you recommend in this case to not use Annotation and define validation rules directly in FormType class? Is there a way to have variables in annotation. Lets say NotBlank(min = $myMinVariableFromDotEnv)?