Symfony 4.4+Sonata用户编辑页RepeatedType密码字段问题解决方案

Hey there, let's break down how to fix this password field issue you're facing with Sonata Admin in Symfony 4.4, plus address your question about moving logic earlier in the process.

Why the Error Happens #

First, let's clarify the order of operations that leads to this error:

1. The form is submitted with an empty password field
2. Symfony's form component tries to bind the submitted data to your User entity
3. This is where the crash occurs: an empty password field passes null to your entity's password property, which expects a string type
4. Sonata's preUpdate method only runs after this data binding (and validation) step—so your logic never gets a chance to intercept the null value

Fix 1: Force Empty Password to Send an Empty String #

The simplest quick fix is to configure the form to replace empty values with an empty string instead of null. Update your formMapper code for the password field:

->add('password', PasswordType::class, [
    'required' => false,
    'empty_data' => '', // Converts null to an empty string
    'label' => 'User Password'
])

Then adjust your preUpdate method to skip encryption if the password is empty:

public function preUpdate($object)
{
    $password = $object->getPassword();
    if (!empty($password)) {
        // Your password encryption logic here
        $encoder = $this->getConfigurationPool()->getContainer()->get('security.password_encoder');
        $object->setPassword($encoder->encodePassword($object, $password));
    }
    // Empty password means we keep the existing value
}

Fix 2: Handle Null in the Entity's Setter #

Another approach is to make your User entity's setPassword method gracefully handle null values. This ensures the entity always receives a string:

// In your User entity
public function setPassword(?string $password): self
{
    // Option 1: Convert null to empty string to match string type requirement
    $this->password = $password ?? '';

    // Option 2: Ignore null entirely to preserve the existing password
    // if ($password !== null) {
    //     $this->password = $password;
    // }
    
    return $this;
}

With option 2, you don't need to modify the form at all—the setter will simply ignore null values and keep the original password.

Fix 3: Move Logic Earlier with Form Events (Your Question Answered!) #

Yes, you absolutely can move your logic to an earlier stage before the data binds to the entity. Use Symfony's form events to modify the submitted data before it touches your User entity.

Add this listener in your Admin class's configureFormFields method, after setting up your form fields:

use Symfony\Component\Form\FormEvent;
use Symfony\Component\Form\FormEvents;

// Inside configureFormFields
$formMapper->getFormBuilder()->addEventListener(FormEvents::PRE_SUBMIT, function (FormEvent $event) {
    $submittedData = $event->getData();
    
    // Remove the empty password field from submitted data
    if (isset($submittedData['password']) && empty($submittedData['password'])) {
        unset($submittedData['password']);
        $event->setData($submittedData);
    }
});

The PRE_SUBMIT event runs right after the form receives submitted data, before it's mapped to the entity. By removing the empty password field, you tell the form not to update the entity's password property at all—so it stays as the original value, no null involved.

Recommendation #

I'd go with Fix 3 if you want to keep your entity and form logic clean, since it prevents the null value from ever reaching the entity. If you prefer a simpler, quicker change, Fix 1 is a solid choice.

内容的提问来源于stack exchange，提问作者netzding