Увійти Реєстрація
Блог Серії
Кар'єра
Вакансії Компанії
Навчання
Документація Співбесіди Тестування Відео
Екосистема
Пакети Ресурси Проєкти Інструменти Події
Інше
Про нас Реклама

Статті за тегом «Валідація»

Статті, новини, туторіали та переклади від учасників спільноти

No results.
Tips 16 жовтня 2026

`confirmed` - підтвердження пароля без ручних порівнянь

Робите підтвердження пароля й порівнюєте поля вручну?

confirmed робить це автоматично.

Як працює:

Перевіряє, що поле збігається з {field}_confirmation.

Для password автоматично очікує password_confirmation.

Конвенція:

  • Поле: password
  • Підтвердження: password_confirmation

Працює з:

будь-якими полями — пароль, email тощо.

Порада: поле _confirmation не потрібно валідувати окремо.

public function rules()
{
  return [
    'password' => 'required|confirmed|min:8',
    'email' => 'required|email|confirmed',
    'new_password' => 'required|confirmed|min:8',
  ];
}
Tips 14 жовтня 2026

`prohibits` - взаємовиключна валідація

Користувач може платити карткою АБО PayPal. Не обома.

Писати кастомну логіку? Є вбудоване правило.

prohibits гарантує, що поле не може бути присутнім разом з іншим.

Коли корисно:

  • Взаємовиключні способи оплати
  • Або email, або телефон
  • Умовні обмеження полів

Схожі правила:

  • required_without — потрібно A, якщо B немає
  • required_with — потрібно A, якщо B є
  • prohibits — A забороняє B

Порада: комбінуйте з required_without для сценарію “або A, або B, але не обидва”.

public function rules()
{
  return [
    'card_number' => 'prohibits:paypal_email',
    'paypal_email' => 'prohibits:card_number',

    'email' => 'required_without:username|prohibits:username',
    'username' => 'required_without:email|prohibits:email',
  ];
}
Tips 12 жовтня 2026

`bail` - зупинити валідацію після першої помилки

У поля email 5 правил. Усі падають — користувач бачить 5 помилок.

Це плутає.

bail зупиняє валідацію поля на першій помилці.

Навіщо:

  • Кращий UX — по одній помилці
  • Продуктивність — не запускаємо дорогі перевірки
  • Чіткіші повідомлення

Як працює:

Додайте bail першим правилом для поля.

Порада: ставте перед дорогими правилами типу exists:, unique: або кастомними перевірками з API.

public function rules()
{
  return [
    'email' => 'bail|required|email|max:255|unique:users',
    'username' => [
      'bail',
      'required',
      'min:3',
      Rule::unique('users')->ignore($this->user),
      new CheckExternalAPI,
    ],
  ];
}
Tips 09 жовтня 2026

`prepareForValidation()` - чистимо дані до валідації

Телефон приходить як "(123) 456-7890", а в БД потрібен "1234567890".

Санітизація в контролері? Це вже запізно.

prepareForValidation() змінює дані запиту до запуску правил.

Коли корисно:

  • Нормалізація телефону
  • Прибирання пробілів
  • Конвертація типів
  • Додавання обчислюваних полів

Важливо:

Виконується до валідації — ідеально для нормалізації.

Порада: merge() додає/оновлює поля, replace() повністю замінює масив даних.

protected function prepareForValidation()
{
  $this->merge([
    'phone' => preg_replace('/[^0-9]/', '', $this->phone),
    'slug' => Str::slug($this->title),
    'price' => (float) $this->price,
    'name' => trim($this->name),
    'email' => strtolower(trim($this->email)),
  ]);
}
Tips 07 жовтня 2026

`exclude()` - прибираємо поля з валідованих даних

У формі є CSRF-токен та допоміжні поля. Ви не хочете, щоб вони потрапили у validated().

exclude_if, exclude_unless прибирають поля умовно.

Коли корисно:

  • Прибрати UI-only поля
  • Виключити поля залежно від ролі
  • Не логувати чутливі поля
  • Тримати валідовані дані “чистими”

Доступні правила:

  • exclude — завжди прибирає
  • exclude_if — прибирає, якщо умова істинна
  • exclude_unless — прибирає, якщо умова хибна
  • exclude_with — прибирає, якщо інше поле присутнє

Порада: краще за ручний unset() після валідації.

public function rules()
{
  return [
    'name' => 'required',
    'admin_notes' => 'exclude', // не потрапить у validated()
    'is_admin' => 'exclude_unless:user.role,admin',
    'card_number' => 'exclude_if:payment_method,cash',
    'paypal_email' => 'exclude_if:payment_method,card',
  ];
}
Tips 05 жовтня 2026

`after()` - хук валідації після проходження всіх правил

Треба перевірити комбінацію полів? Або пов’язані записи в БД?

Звичайні правила працюють незалежно. Хук after() запускається після того, як усі правила пройшли.

Коли корисно:

  • Валідація кількох полів разом
  • Перевірки в БД
  • Складна бізнес-логіка
  • Кастомні повідомлення помилок на основі кількох полів

Суть:

Callback отримує Validator. Помилки додаються вручну.

Порада: after() ідеальний для валідації, що залежить від кількох полів або запитів до БД.

public function withValidator($validator)
{
  $validator->after(function ($v) {
    if ($this->start_date > $this->end_date) {
      $v->errors()->add(
        'end_date',
        'Дата завершення має бути після початку.'
      );
    }

    $total = $this->quantity * $this->price;
    if ($total > 1000 && ! $this->has_approval) {
      $v->errors()->add(
        'has_approval',
        'Замовлення понад $1000 потребують підтвердження.'
      );
    }
  });
}
Tips 02 жовтня 2026

Кастомні правила валідації - коли вбудованих недостатньо

Потрібно перевірити дані через зовнішній API? Або зробити складну перевірку в БД?

Вбудованих правил може не вистачити. Кастомні правила дають повний контроль.

Два підходи:

  • Класи-правила (перевикористовні, тестовані)
  • Closure (швидко, інлайн)

Коли використовувати:

  • Бізнес-специфічна валідація
  • Перевірки через зовнішній API
  • Складні запити до БД
  • Перевірки, що залежать від кількох полів

Порада: для правил, які повторюються в різних формах, краще робити окремий клас-правило.

// Швидко: closure-правило
public function rules()
{
  return [
    'username' => [
      'required',
      function ($attr, $value, $fail) {
        if (strtoupper($value) !== $value) {
          $fail("Поле {$attr} має бути у ВЕРХНЬОМУ регістрі.");
        }
      },
    ],
  ];
}

// Перевикористовно: php artisan make:rule Uppercase
class Uppercase implements Rule
{
  public function passes($attribute, $value): bool
  {
    return strtoupper($value) === $value;
  }

  public function message(): string
  {
    return 'Поле :attribute має бути у верхньому регістрі.';
  }
}
Tips 30 вересня 2026

sometimes() - умовні правила валідації

Email обов’язковий… але лише коли тип користувача — customer.

Писати кастомну логіку валідації в контролері? Неохайно.

sometimes() застосовує правила лише тоді, коли умова істинна.

Як це працює:

  • 1-й аргумент — назва поля
  • 2-й аргумент — правила
  • 3-й аргумент — callback-умова

Коли корисно:

  • Поле обов’язкове залежно від іншого поля
  • Різні правила для різних типів користувачів
  • Складна бізнес-логіка у валідації

Порада: складні умови виносьте в окремі методи для читабельності.

$validator = Validator::make($request->all(), [
  'name' => 'required',
  'type' => 'required|in:customer,guest',
]);

$validator->sometimes(
  'email',
  'required|email',
  fn ($input) => $input->type === 'customer'
);

$validator->sometimes(
  ['phone', 'address'],
  'required',
  fn ($input) => $input->type === 'customer'
);

// Складна умова
$validator->sometimes('company_name', 'required', function ($i) {
  return $i->account_type === 'business'
    && $i->annual_revenue > 100000;
});
Laravel 13.27
Новини 27 серпня 2026

Laravel 13.27: маскування параметрів запитів, бінарні порівняння та пасимістичні блокування

У Laravel 13.27 з'явилася можливість приховувати параметри запитів вException-повідомленнях, нові методи whereBinary() для точних порівнянь, refreshForUpdate() для перезавантаження моделі під блокуванням та багато інших покращень безпеки й продуктивності.

4

Матеріали за темою «Валідація»: усе, що ми писали про це українською. Нижче - суміжні теми, якщо шукаєте ширше.

Зараз опубліковано 15 матеріалів від 2 авторів. Останній матеріал - 16 жовтня 2026.