Basics - 10. Validation

Defining The Routes

Nehmen wir zunächst an, wir haben die folgenden Routen in unserer Datei routes/web.php definiert:

Route::get('post/create', 'PostController@create');

Route::post('post', 'PostController@store');

Die GET-Route zeigt ein Formular an, in dem der Benutzer einen neuen Blogbeitrag erstellen kann, während die POST-Route den neuen Blogbeitrag in der Datenbank speichert.

Creating The Controller

Als nächstes werfen wir einen Blick auf einen einfachen Controller, der diese Routen verwaltet. Wir lassen die store-Methode vorerst leer:

<?php

namespace App\Http\Controllers;

use Illuminate\Http\Request;
use App\Http\Controllers\Controller;

class PostController extends Controller
{
    /**
     * Show the form to create a new blog post.
     *
     * @return Response
     */
    public function create()
    {
        return view('post.create');
    }

    /**
     * Store a new blog post.
     *
     * @param  Request  $request
     * @return Response
     */
    public function store(Request $request)
    {
        // Validate and store the blog post...
    }
}

Writing The Validation Logic

Jetzt sind wir bereit, unsere store-Methode mit der Logik zu füllen, um den neuen Blogbeitrag zu validieren. Dazu verwenden wir die validate-Methode des Illuminate\Http\Request-Objekts. Wenn die Validierungsregeln übergeben werden, wird Ihr Code weiterhin normal ausgeführt; wenn die Validierung jedoch fehlschlägt, wird eine Ausnahme ausgelöst und die richtige Fehlerreaktion automatisch an den Benutzer zurückgesendet. Im Falle einer traditionellen HTTP-Anfrage wird eine Redirect-Antwort generiert, während bei AJAX-Anfragen eine JSON-Antwort gesendet wird.

Um ein besseres Verständnis der validate-Methode zu erhalten, springen wir zurück zur store-Methode:

/**
 * Store a new blog post.
 *
 * @param  Request  $request
 * @return Response
 */
public function store(Request $request)
{
    $validatedData = $request->validate([
        'title' => 'required|unique:posts|max:255',
        'body' => 'required',
    ]);

    // The blog post is valid...
}

Wie Sie sehen können, übergeben wir die gewünschten Validierungsregeln an die validate-Methode. Auch hier gilt: Wenn die Validierung fehlschlägt, wird automatisch die richtige Antwort generiert. Wenn die Validierung erfolgreich ist, wird unser Controller die normale Ausführung fortsetzen.

Stopping On First Validation Failure

Manchmal kann es sein, dass Sie nach dem ersten Validierungsfehler die Ausführung von Validierungsregeln für ein Attribut einstellen möchten. Ordnen Sie dazu dem Attribut die bail-Rule zu:

$request->validate([
    'title' => 'bail|required|unique:posts|max:255',
    'body' => 'required',
]);

In diesem Beispiel wird die max-Rule nicht überprüft, wenn die unique-Rule für das Titelattribut fehlschlägt. Die Regeln werden in der Reihenfolge ihrer Zuweisung validiert.

A Note On Nested Attributes

Wenn Ihre HTTP-Anfrage "verschachtelte" Parameter enthält, können Sie diese in Ihren Validierungsregeln mit der Syntax "Punkt" angeben:

$request->validate([
    'title' => 'required|unique:posts|max:255',
    'author.name' => 'required',
    'author.description' => 'required',
]);

Displaying The Validation Errors

Also, was ist, wenn die eingehenden Anforderungsparameter die angegebenen Validierungsregeln nicht erfüllen? Wie bereits erwähnt, leitet Laravel den Benutzer automatisch an seinen vorherigen Standort zurück. Darüber hinaus werden alle Validierungsfehler automatisch in die Session geflasht.

Nochmals, beachten Sie, dass wir die Fehlermeldungen nicht explizit an die View in unserer GET-Route binden mussten. Dies liegt daran, dass Laravel nach Fehlern in den Sitzungsdaten sucht und diese automatisch an die Ansicht bindet, wenn sie verfügbar sind. Die Variable $errors ist eine Instanz von Illuminate\Support\MessageBag. Weitere Informationen zur Arbeit mit diesem Objekt finden Sie in der Dokumentation.

In unserem Beispiel wird der Benutzer also bei fehlgeschlagener Validierung auf die create-Methode unseres Controllers umgeleitet, so dass wir die Fehlermeldungen in der Ansicht anzeigen können:

<!-- /resources/views/post/create.blade.php -->

<h1>Create Post</h1>

@if ($errors->any())
    <div class="alert alert-danger">
        <ul>
            @foreach ($errors->all() as $error)
                <li>{{ $error }}</li>
            @endforeach
        </ul>
    </div>
@endif

<!-- Create Post Form -->

The @error Directive

Sie können auch die @error Blade Direktive verwenden, um schnell zu überprüfen, ob Validierungsfehlermeldungen für ein bestimmtes Attribut existieren. Innerhalb einer @error-Direktive können Sie die Variable $message wiederholen, um die Fehlermeldung anzuzeigen:

<!-- /resources/views/post/create.blade.php -->

<label for="title">Post Title</label>

<input id="title" type="text" class="@error('title') is-invalid @enderror">

@error('title')
    <div class="alert alert-danger">{{ $message }}</div>
@enderror

A Note On Optional Fields

Standardmäßig beinhaltet Laravel die Middleware TrimStrings und ConvertEmptyStringsToNull in den globalen Middleware-Stapel Ihrer Anwendung. Diese Middleware wird im Stapel von der Klasse App\Http\Kernel aufgelistet. Aus diesem Grund müssen Sie Ihre "optionalen" Anfragefelder oft als nullable markieren, wenn Sie nicht möchten, dass der Prüfer Nullwerte als ungültig betrachtet. Zum Beispiel:

$request->validate([
    'title' => 'required|unique:posts|max:255',
    'body' => 'required',
    'publish_at' => 'nullable|date',
]);

In diesem Beispiel geben wir an, dass das Feld publish_at entweder Null oder eine gültige Datumsdarstellung sein kann. Wenn der nullable Modifikator nicht zur Regeldefinition hinzugefügt wird, würde der Prüfer null als ungültiges Datum betrachten.

AJAX Requests & Validation

In diesem Beispiel haben wir ein traditionelles Formular verwendet, um Daten an die Anwendung zu senden. Viele Anwendungen verwenden jedoch AJAX-Anfragen. Wenn Sie die validate-Methode während einer AJAX-Anfrage verwenden, erzeugt Laravel keine Umleitungsantwort. Stattdessen erzeugt Laravel eine JSON-Antwort, die alle Validierungsfehler enthält. Diese JSON-Antwort wird mit einem 422 HTTP-Statuscode gesendet.

Form Request Validation

Creating Form Requests

Für komplexere Validierungsszenarien können Sie eine "Formularanforderung" erstellen. Formularanforderungen sind benutzerdefinierte Anforderungsklassen, die eine Validierungslogik enthalten. Um eine Formularanforderungsklasse zu erstellen, verwenden Sie den Befehl make:request Artisan CLI:

php artisan make:request StoreBlogPost

Die generierte Klasse wird im Verzeichnis app/Http/Requests abgelegt. Wenn dieses Verzeichnis nicht existiert, wird es beim Ausführen des Befehls make:request erstellt. Lassen Sie uns ein paar Validierungsregeln zur rules-Methode hinzufügen:

/**
 * Get the validation rules that apply to the request.
 *
 * @return array
 */
public function rules()
{
    return [
        'title' => 'required|unique:posts|max:255',
        'body' => 'required',
    ];
}

Wie werden also die Validierungsregeln bewertet? Alles, was Sie tun müssen, ist, die Anfrage auf Ihrer Controller-Methode zu tippen. Die eingehende Formularanforderung wird vor dem Aufruf der Controllermethode validiert, so dass Sie Ihre Steuerung nicht mit einer Validierungslogik überladen müssen:

Adding After Hooks To Form Requests

Wenn Sie einer Formularanforderung ein "after"-Hook hinzufügen möchten, können Sie die Methode withValidator verwenden. Diese Methode erhält den vollständig konstruierten Prüfer, so dass Sie jede seiner Methoden aufrufen können, bevor die Validierungsregeln tatsächlich ausgewertet werden:

/**
 * Configure the validator instance.
 *
 * @param  \Illuminate\Validation\Validator  $validator
 * @return void
 */
public function withValidator($validator)
{
    $validator->after(function ($validator) {
        if ($this->somethingElseIsInvalid()) {
            $validator->errors()->add('field', 'Something is wrong with this field!');
        }
    });
}

Authorizing Form Requests

Die Formularanforderungsklasse enthält auch eine authorize-Methode. Innerhalb dieser Methode können Sie überprüfen, ob der authentifizierte Benutzer tatsächlich die Berechtigung hat, eine bestimmte Ressource zu aktualisieren. Beispielsweise können Sie bestimmen, ob ein Benutzer tatsächlich einen Blog-Kommentar besitzt, den er zu aktualisieren versucht:

/**
 * Determine if the user is authorized to make this request.
 *
 * @return bool
 */
public function authorize()
{
    $comment = Comment::find($this->route('comment'));

    return $comment && $this->user()->can('update', $comment);
}

Da alle Formularanforderungen die Basis-Laravel-Anforderungsklasse erweitern, können wir mit der user-Methode auf den aktuell authentifizierten Benutzer zugreifen. Beachten Sie auch den Aufruf der route-Methode im obigen Beispiel. Diese Methode gewährt Ihnen Zugriff auf die URI-Parameter, die auf der aufgerufenen Route definiert sind, wie beispielsweise den Parameter {comment} im folgenden Beispiel:

Route::post('comment/{comment}');

Wenn die authorize-Methode false zurückgibt, wird automatisch eine HTTP-Antwort mit einem 403-Statuscode zurückgegeben und Ihre Controller Methode wird nicht ausgeführt.

Wenn Sie planen, die Berechtigungslogik in einem anderen Teil Ihrer Anwendung zu haben, geben Sie true von der authorize-Methode zurück:

/**
 * Determine if the user is authorized to make this request.
 *
 * @return bool
 */
public function authorize()
{
    return true;
}

Customizing The Error Messages

Sie können die von der Formularanforderung verwendeten Fehlermeldungen anpassen, indem Sie die messages-Methode überschreiben. Diese Methode sollte ein Array von Attribut-/Regelpaaren und den entsprechenden Fehlermeldungen zurückgeben:

/**
 * Get the error messages for the defined validation rules.
 *
 * @return array
 */
public function messages()
{
    return [
        'title.required' => 'A title is required',
        'body.required'  => 'A message is required',
    ];
}

Customizing The Validation Attributes

Wenn Sie möchten, dass der :attribute-Teil Ihrer Validierungsnachricht durch einen benutzerdefinierten Attributnamen ersetzt wird, können Sie die benutzerdefinierten Namen angeben, indem Sie die attributes-Methode überschreiben. Diese Methode sollte ein Array von Attribut-/Namenspaaren zurückgeben:

/**
 * Get custom attributes for validator errors.
 *
 * @return array
 */
public function attributes()
{
    return [
        'email' => 'email address',
    ];
}

Manually Creating Validators

Wenn Sie die validate-Methode auf der Anforderung nicht verwenden möchten, können Sie eine Validatorinstanz manuell über die Validator-Facade erstellen. Die make-Methode auf der Fassade erzeugt eine neue Validatorinstanz:

<?php

namespace App\Http\Controllers;

use Illuminate\Http\Request;
use App\Http\Controllers\Controller;
use Illuminate\Support\Facades\Validator;

class PostController extends Controller
{
    /**
     * Store a new blog post.
     *
     * @param  Request  $request
     * @return Response
     */
    public function store(Request $request)
    {
        $validator = Validator::make($request->all(), [
            'title' => 'required|unique:posts|max:255',
            'body' => 'required',
        ]);

        if ($validator->fails()) {
            return redirect('post/create')
                        ->withErrors($validator)
                        ->withInput();
        }

        // Store the blog post...
    }
}

Das erste Argument, das an die make-Methode übergeben wird, sind die zu validierenden Daten. Das zweite Argument sind die Validierungsregeln, die auf die Daten angewendet werden sollten.

Nachdem Sie überprüft haben, ob die Anforderungsprüfung fehlgeschlagen ist, können Sie die withErrors-Methode verwenden, um die Fehlermeldungen in die Sitzung zu flashen. Bei Verwendung dieser Methode wird die Variable $errors nach der Umleitung automatisch mit Ihren Ansichten geteilt, so dass Sie sie dem Benutzer leicht wieder anzeigen können. Die withErrors-Methode akzeptiert einen Prüfer, einen MessageBag oder ein PHP-Array.

Automatic Redirection

Wenn Sie eine Prüfinstanz manuell erstellen möchten, aber dennoch die Vorteile der automatischen Umleitung der validate-Methode der Anforderungen nutzen möchten, können Sie die validate-Methode auf einer vorhandenen Prüfinstanz aufrufen. Wenn die Validierung fehlschlägt, wird der Benutzer automatisch umgeleitet oder, im Falle einer AJAX-Anfrage, wird eine JSON-Antwort zurückgegeben:

Validator::make($request->all(), [
    'title' => 'required|unique:posts|max:255',
    'body' => 'required',
])->validate();

Named Error Bags

Wenn Sie mehrere Formulare auf einer einzigen Seite haben, können Sie den MessageBag mit Fehlern benennen, so dass Sie die Fehlermeldungen für ein bestimmtes Formular abrufen können. Übergeben Sie einen Namen als zweites Argument an withErrors:

return redirect('register')
            ->withErrors($validator, 'login');

Sie können dann über die Variable $errors auf die benannte MessageBag-Instanz zugreifen:

{{ $errors->login->first('email') }}

After Validation Hook

Der Validator ermöglicht es Ihnen auch, Rückrufe anzuhängen, die nach Abschluss der Validierung ausgeführt werden sollen. Auf diese Weise können Sie auf einfache Weise weitere Validierungen durchführen und sogar weitere Fehlermeldungen in die Nachrichtensammlung aufnehmen. Um zu beginnen, verwenden Sie die after-Methode auf einer Validator-Instanz:

$validator = Validator::make(...);

$validator->after(function ($validator) {
    if ($this->somethingElseIsInvalid()) {
        $validator->errors()->add('field', 'Something is wrong with this field!');
    }
});

if ($validator->fails()) {
    //
}

Working With Error Messages

Nachdem Sie die error-Methode auf einer Validator-Instanz aufgerufen haben, erhalten Sie eine Illuminate\Support\MessageBag-Instanz, die über eine Vielzahl von praktischen Methoden zum Arbeiten mit Fehlermeldungen verfügt. Die Variable $errors, die automatisch allen Ansichten zur Verfügung gestellt wird, ist ebenfalls eine Instanz der MessageBag-Klasse.

Retrieving The First Error Message For A Field

Um die erste Fehlermeldung für ein bestimmtes Feld abzurufen, verwenden Sie die first-Methode:

$errors = $validator->errors();

echo $errors->first('email');

Retrieving All Error Messages For A Field

Wenn Sie ein Array mit allen Nachrichten für ein bestimmtes Feld abrufen müssen, verwenden Sie die get-Methode:

foreach ($errors->get('email') as $message) {
    //
}

Wenn Sie ein Array-Formularfeld validieren, können Sie alle Nachrichten für jedes der Array-Elemente mit dem Zeichen * abrufen:

foreach ($errors->get('attachments.*') as $message) {
    //
}

Retrieving All Error Messages For All Fields

Um ein Array aller Nachrichten für alle Felder abzurufen, verwenden Sie die all-Methode:

foreach ($errors->all() as $message) {
    //
}

Determining If Messages Exist For A Field

Die has-Methode kann verwendet werden, um zu bestimmen, ob Fehlermeldungen für ein bestimmtes Feld vorliegen:

if ($errors->has('email')) {
    //
}

Custom Error Messages

Bei Bedarf können Sie anstelle der Standardeinstellungen benutzerdefinierte Fehlermeldungen zur Validierung verwenden. Es gibt mehrere Möglichkeiten, benutzerdefinierte Nachrichten anzugeben. Zuerst können Sie die benutzerdefinierten Nachrichten als drittes Argument an die Methode Validator::make übergeben:

$messages = [
    'required' => 'The :attribute field is required.',
];

$validator = Validator::make($input, $rules, $messages);

In this example, the :attribute placeholder will be replaced by the actual name of the field under validation. You may also utilize other placeholders in validation messages. For example:

$messages = [
    'same'    => 'The :attribute and :other must match.',
    'size'    => 'The :attribute must be exactly :size.',
    'between' => 'The :attribute value :input is not between :min - :max.',
    'in'      => 'The :attribute must be one of the following types: :values',
];

Specifying A Custom Message For A Given Attribute

Manchmal möchten Sie eine benutzerdefinierte Fehlermeldung nur für ein bestimmtes Feld angeben. Sie können dies mit der "Punkt"-Notation tun. Geben Sie zuerst den Namen des Attributs und dann die Regel an:

$messages = [
    'email.required' => 'We need to know your e-mail address!',
];

Specifying Custom Messages In Language Files

In den meisten Fällen werden Sie Ihre benutzerdefinierten Nachrichten wahrscheinlich in einer Sprachdatei angeben, anstatt sie direkt an den Validator zu übergeben. Um dies zu tun, fügen Sie Ihre Nachrichten zu einem Custom Array (benutzerdefiniertes Array) in der Sprachdatei resources/lang/xx/validation.php hinzu.

'custom' => [
    'email' => [
        'required' => 'We need to know your e-mail address!',
    ],
],

Specifying Custom Attributes In Language Files

Wenn Sie möchten, dass der :attribute-Teil Ihrer Validierungsnachricht durch einen benutzerdefinierten Attributnamen ersetzt wird, können Sie den benutzerdefinierten Namen im Attribut-Array Ihrer Sprachdatei resources/lang/xx/validation.php angeben:

'attributes' => [
    'email' => 'email address',
],

Specifying Custom Values In Language Files

Manchmal kann es erforderlich sein, dass der :value-Teil Ihrer Validierungsnachricht durch eine benutzerdefinierte Darstellung des Wertes ersetzt wird. Beachten Sie beispielsweise die folgende Regel, die angibt, dass eine Kreditkartennummer erforderlich ist, wenn der payment_type einen Wert von cc hat:

$request->validate([
    'credit_card_number' => 'required_if:payment_type,cc'
]);

Wenn diese Validierungsregel fehlschlägt, wird die folgende Fehlermeldung ausgegeben:

The credit card number field is required when payment type is cc.

Anstatt cc als Wert der Zahlungsart anzuzeigen, können Sie eine benutzerdefinierte Wertdarstellung in Ihrer validation language file angeben, indem Sie ein Wertearray (value-Array) definieren:

'values' => [
    'payment_type' => [
        'cc' => 'credit card'
    ],
],

Wenn die Validierungsregel nun fehlschlägt, wird die folgende Meldung ausgegeben:

The credit card number field is required when payment type is credit card.

Conditionally Adding Rules

Validating When Present

In einigen Situationen kann es sinnvoll sein, Validierungsprüfungen gegen ein Feld nur dann durchzuführen, wenn dieses Feld im Eingabefeld vorhanden ist. Um dies schnell zu erreichen, fügen Sie die manchmal vorkommende Regel zu Ihrer Regelliste hinzu:

$v = Validator::make($data, [
    'email' => 'sometimes|required|email',
]);

Im obigen Beispiel wird das E-Mail-Feld nur dann überprüft, wenn es im $data-Array vorhanden ist.

Complex Conditional Validation

Manchmal ist es sinnvoll, Validierungsregeln hinzuzufügen, die auf komplexerer bedingter Logik basieren. Beispielsweise können Sie ein bestimmtes Feld nur dann benötigen, wenn ein anderes Feld einen höheren Wert als 100 hat. Oder Sie benötigen zwei Felder, um einen bestimmten Wert nur dann zu erhalten, wenn ein anderes Feld vorhanden ist. Das Hinzufügen dieser Validierungsregeln muss kein Problem sein. Erstellen Sie zunächst eine Validator-Instanz mit Ihren statischen Regeln, die sich nie ändern:

$v = Validator::make($data, [
    'email' => 'required|email',
    'games' => 'required|numeric',
]);

Nehmen wir an, unsere Webanwendung ist für Spielsammler. Wenn sich ein Spielesammler bei unserer Anwendung registriert und mehr als 100 Spiele besitzt, möchten wir, dass er erklärt, warum er so viele Spiele besitzt. Zum Beispiel betreiben sie vielleicht einen Game Resale Shop, oder sie sammeln einfach gerne. Um diese Anforderung bedingt hinzuzufügen, können wir die sometimes-Methode auf der Validator-Instanz verwenden.

$v->sometimes('reason', 'required|max:500', function ($input) {
    return $input->games >= 100;
});

Das erste Argument, das an die sometimes-Methode übergeben wird, ist der Name des Feldes, das wir bedingt validieren. Das zweite Argument sind die Regeln, die wir hinzufügen wollen. Wenn das Closure, das als drittes Argument übergeben wurde, true zurückgibt, werden die Regeln hinzugefügt. Diese Methode macht es zum Kinderspiel, komplexe bedingte Validierungen zu erstellen. Sie können sogar bedingte Validierungen für mehrere Felder auf einmal hinzufügen:

$v->sometimes('reason', 'cost'], 'required', function ($input) {
    return $input->games >= 100;
});

Validating Arrays

Die Validierung von array-basierten Formular-Eingabefeldern muss kein Problem sein. Sie können die "Punktnotation" verwenden, um Attribute innerhalb eines Arrays zu überprüfen. Wenn beispielsweise der eingehende HTTP-Request ein Feld photos[profile] enthält, können Sie es wie folgt validieren:

$validator = Validator::make($request->all(), [
    'photos.profile' => 'required|image',
]);

Sie können auch jedes Element eines Arrays validieren. Um beispielsweise zu überprüfen, ob jede E-Mail in einem bestimmten Array-Eingabefeld eindeutig ist, können Sie Folgendes tun:

$validator = Validator::make($request->all(), [
    'person.*.email' => 'email|unique:users',
    'person.*.first_name' => 'required_with:person.*.last_name',
]);

Ebenso können Sie das Zeichen * verwenden, wenn Sie Ihre Validierungsnachrichten in Ihren Sprachdateien angeben, so dass es ein Kinderspiel ist, eine einzige Validierungsnachricht für array-basierte Felder zu verwenden:

'custom' => [
    'person.*.email' => [
        'unique' => 'Each person must have a unique e-mail address',
    ]
],

Custom Validation Rules

Using Rule Objects

Laravel bietet eine Vielzahl hilfreicher Validierungsregeln, aber Sie können auch einige Ihrer eigenen Regeln angeben. Eine Methode zur Registrierung benutzerdefinierter Validierungsregeln ist die Verwendung von Regelobjekten. Um ein neues Regelobjekt zu erzeugen, können Sie den Befehl make:rule Artisan verwenden. Verwenden wir diesen Befehl, um eine Regel zu erstellen, die überprüft, ob eine Zeichenkette in Großbuchstaben geschrieben ist. Laravel wird die neue Regel in das Verzeichnis app/Rules aufnehmen:

php artisan make:rule Uppercase

Sobald die Regel erstellt wurde, sind wir bereit, ihr Verhalten zu definieren. Ein Regelobjekt enthält zwei Methoden: passes und message. Die Übergabemethode empfängt den Attributwert und den Namen und sollte je nachdem, ob der Attributwert gültig ist oder nicht, true oder false zurückgeben. Die message-Methode sollte die Validierungsfehlermeldung zurückgeben, die verwendet werden sollte, wenn die Validierung fehlschlägt: 

<?php

namespace App\Rules;

use Illuminate\Contracts\Validation\Rule;

class Uppercase implements Rule
{
    /**
     * Determine if the validation rule passes.
     *
     * @param  string  $attribute
     * @param  mixed  $value
     * @return bool
     */
    public function passes($attribute, $value)
    {
        return strtoupper($value) === $value;
    }

    /**
     * Get the validation error message.
     *
     * @return string
     */
    public function message()
    {
        return 'The :attribute must be uppercase.';
    }
}

Sie können den trans helper aus Ihrer message-Methode aufrufen, wenn Sie eine Fehlermeldung aus Ihren Übersetzungsdateien zurückgeben möchten:

/**
 * Get the validation error message.
 *
 * @return string
 */
public function message()
{
    return trans('validation.uppercase');
}

Sobald die Regel definiert ist, können Sie sie an einen Prüfer anhängen, indem Sie eine Instanz des Regelobjekts mit Ihren anderen Prüfregeln übergeben:

use App\Rules\Uppercase;

$request->validate([
    'name' => ['required', 'string', new Uppercase],
]);

Using Closures

Wenn Sie die Funktionalität einer benutzerdefinierten Regel nur einmal in Ihrer Anwendung benötigen, können Sie anstelle eines Regelobjekts einen Verschluss verwenden. Der Abschluss erhält den Namen des Attributs, den Wert des Attributs und einen $fail Callback, der aufgerufen werden sollte, wenn die Validierung fehlschlägt:

$validator = Validator::make($request->all(), [
    'title' => [
        'required',
        'max:255',
        function ($attribute, $value, $fail) {
            if ($value === 'foo') {
                $fail($attribute.' is invalid.');
            }
        },
    ],
]);

Using Extensions

Eine weitere Methode zur Registrierung benutzerdefinierter Validierungsregeln ist die Verwendung der extend-Methode an der Validator-Facade. Lassen Sie uns diese Methode innerhalb eines service provider verwenden, um eine benutzerdefinierte Validierungsregel zu registrieren:

<?php

namespace App\Providers;

use Illuminate\Support\ServiceProvider;
use Illuminate\Support\Facades\Validator;

class AppServiceProvider extends ServiceProvider
{
    /**
     * Register any application services.
     *
     * @return void
     */
    public function register()
    {
        //
    }

    /**
     * Bootstrap any application services.
     *
     * @return void
     */
    public function boot()
    {
        Validator::extend('foo', function ($attribute, $value, $parameters, $validator) {
            return $value == 'foo';
        });
    }
}

Der benutzerdefinierte Validator Closure erhält vier Argumente: den Namen des zu validierenden $attributs, den $value des Attributs, ein Array von $parameters, die an die Regel übergeben werden, und die Validator-Instanz.

Sie können auch eine Klasse und Methode an die extend-Methode anstelle eines Closure übergeben:

Validator::extend('foo', 'FooValidator@validate');

Defining The Error Message

Sie müssen auch eine Fehlermeldung für Ihre benutzerdefinierte Regel definieren. Sie können dies entweder über ein Inline Custom Message Array oder durch Hinzufügen eines Eintrags in die Validierungssprachendatei tun. Diese Nachricht sollte in der ersten Ebene des Arrays platziert werden, nicht innerhalb des custom-Arrays, was nur für attributspezifische Fehlermeldungen gilt:

"foo" => "Your input was invalid!",

"accepted" => "The :attribute must be accepted.",

// The rest of the validation error messages...

Beim Erstellen einer benutzerdefinierten Validierungsregel müssen Sie manchmal benutzerdefinierte Platzhalter-Ersetzungen für Fehlermeldungen definieren. Sie können dies tun, indem Sie wie oben beschrieben einen benutzerdefinierten Validator erstellen und dann die Replacer-Methode auf der Validator-Facade aufrufen. Sie können dies innerhalb der Boot-Methode eines Service Provider tun:

/**
 * Bootstrap any application services.
 *
 * @return void
 */
public function boot()
{
    Validator::extend(...);

    Validator::replacer('foo', function ($message, $attribute, $rule, $parameters) {
        return str_replace(...);
    });
}

Implicit Extensions

Wenn ein zu validierendes Attribut nicht vorhanden ist oder eine leere Zeichenkette enthält, werden standardmäßig keine normalen Validierungsregeln, einschließlich benutzerdefinierter Erweiterungen, ausgeführt. Beispielsweise wird die unique-Rule nicht gegen eine leere Zeichenkette ausgeführt:

$rules = ['name' => 'unique:users,name'];

$input = ['name' => ''];

Validator::make($input, $rules)->passes(); // true

Damit eine Regel auch dann ausgeführt werden kann, wenn ein Attribut leer ist, muss die Regel implizieren, dass das Attribut erforderlich ist. Um eine solche "implizite" Erweiterung zu erstellen, verwenden Sie die Methode Validator::extendImplicit():

Validator::extendImplicit('foo', function ($attribute, $value, $parameters, $validator) {
    return $value == 'foo';
});

Implicit Rule Objects

Wenn Sie möchten, dass ein Regelobjekt ausgeführt wird, wenn ein Attribut leer ist, sollten Sie die Schnittstelle Illuminate\Contracts\Validation\ImplicitRule implementieren. Dieses Interface dient als "Marker-Interface" für den Validierer und enthält daher keine Methoden, die Sie implementieren müssen.