The following piece of PHP code works to capture input from a Livewire form. The form updates a user's password, and for the keen-eyed amongst you, you may find that large sections of it are taken from the Laravel Fortify framework.
/**
* Validate and update the user's password.
*
* @param mixed $user
* @param array $input
* @return void
*/
public function update($user, array $input)
{
try {
Validator::make($input, [
'current_password' => ['required', 'string'],
'password' => $this->passwordRules(),
])->after(function ($validator) use ($user, $input) {
if (! isset($input['current_password']) || ! Hash::check($input['current_password'], $user->password)) {
$validator->errors()->add('current_password', __('The provided password does not match your current password.'));
}
})->validateWithBag('updatePassword');
} catch (\Illuminate\Validation\ValidationException $e) {
dd ($e);
}
$user->forceFill([
'password' => Hash::make($input['password']),
])->save();
}
If a user enters invalid data, the dd($e);
line of code shows me the exception object. The exception object thrown at this point contains an error bag named updatePassword
. This is to be expected because the validateWithBag()
function dictates that this should be so.
All good so far. However...
If I try to capture the error in the Livewire template (or for that matter, any Blade template), the named error bag disappears. To prove the point, the following <div>
does appear when a current_password
error is detected.
@error ('current_password')
<div>Show error here: {{ $message }}</div>
@enderror
But the following <div>
does not get shown by the framework:
@error ('current_password', 'updatePassword')
<div>Show error here: {{ $message }}</div>
@enderror
If I try to echo out the $errors
object from the blade template itself, then the object type is no longer of type \Illuminate\Validation\ValidationException
, but rather of type Illuminate\Support\ViewErrorBag
.
@php dd($errors); @endphp
Perhaps this is to be expected. But the problem is that the only error bag contained in this $errors
object is 'default'
. The error messages themselves are correct, but they are not in the bag I would expect them to be in.
Why is this?!
It's not a huge problem per-se, but it would be nice to understand what's going on. As the application expands, it becomes increasingly likely that a clash in error-message-id could lead to unexpected behaviour.