Код ошибки валидатора

Каждый сайт, который создает компания, должен отвечать принятым стандартам. В первую очередь затем, чтобы он попадал в поисковую выдачу и был удобен для пользователей. Если код страниц содержит ошибки, неточности, он становится “невалидным”, то есть не соответствующим требованиям. В результате интернет-ресурс не увидят пользователи или информация на нем будет отображаться некорректно. 

В этой статье рассмотрим, что такое валидность, какие могут быть ошибки в HTML-разметке и как их устранить.

Что такое HTML-ошибка валидации и зачем она нужна

Под понятием  “валидация” подразумевается процесс онлайн-проверки HTML-кода страницы на соответствие стандартам w3c. Эти стандарты были разработаны Организацией всемирной паутины и стандартов качества разметки. Сама организация продвигает идею унификации сайтов по HTML-коду — чтобы каждому пользователю, вне зависимости от браузера или устройства, было удобно использовать ресурс.

Если код отвечает стандартам, то его называют валидным. Браузеры могут его прочитать, загрузить страницы, а поисковые системы легко находят страницу по соответствующему запросу. 

Чем опасны ошибки в разметке

Ошибки валидации могут разными — видимыми для глаза простого пользователя или такими, которые можно засечь только с помощью специальных программ. В первом случае кроме технических проблем, ошибки в разметке приводят к негативному пользовательскому опыту. 

К наиболее распространённым последствиям ошибок в коде HTML-разметки также относят сбои в нормальной работе сайта и помехи в продвижении ресурса в поисковых системах.

Рассмотрим несколько примеров, как ошибки могут проявляться при работе:

• Медленно подгружается страница 

Согласно исследованию Unbounce, более четверти пользователей покидают страницу, если её загрузка занимает более 3 секунд, ещё треть  уходит после 6 секунд;

• Не видна часть текстовых, фото и видео-блоков 

Эта проблема делает контент для пользователей неинформативным, поэтому они в большинстве случаев уходят со страницы, не досмотрев её до конца;

• Страница может остаться не проиндексированной

Если поисковый робот распознает недочёт в разметке, он может пропустить страницу и прервать её размещение в поисковых системах;

• Разное отображение страниц на разных устройствах

Например, на компьютере или ноутбуке страница будет выглядеть хорошо, а на мобильных гаджетах половина кнопок и изображений будет попросту не видна.

Из-за этих ошибок пользователь не сможет нормально работать с ресурсом. Единственное решение для него — закрыть вкладку и найти нужную информацию на другом сайте. Так количество посетителей сайта постепенно уменьшается, он перестает попадать в поисковую выдачу  —  в результате ресурс становится бесполезным и пропадает в пучине Интернета.

Как проверить ошибки валидации

Владельцы ресурсов используют 2 способа онлайн-проверки сайтов на наличие ошибок — технический аудит или использование валидаторов. 

Первый случай подходит для серьёзных проблем и масштабных сайтов. Валидаторами же пользуются ежедневно. Наиболее популярный — сервис The W3C Markup Validation Service. Он сканирует сайт и сравнивает код на соответствие стандартам W3C. Валидатор выдаёт 2 типа несоответствий разметки стандартам W3C: предупреждения и ошибки. 

Давайте рассмотрим каждый из типов чуть подробнее.

Предупреждения

Предупреждения отмечают незначительные проблемы, которые не влияют на работу ресурса. Они появляются из-за расхождений написания разметки со стандартами W3C. 

Тем не менее, предупреждения всё равно нужно устранять, так как из-за них сайт может работать медленнее — например, по сравнению с конкурентами с такими же сайтами.

Примером предупреждения может быть указание на отсутствие тега alt у изображения. 

Ошибки

Ошибки  —  это те проблемы, которые требуют обязательного устранения. 

Они представляют угрозу для корректной работы сайта: например, из-за них могут скрываться разные блоки  — текстовые, фото, видео. А в некоторых более запущенных случаях содержимое страницы может вовсе не отображаться, и сам ресурс не будет загружаться. Поэтому после проверки уделять внимание ошибкам с красными отметками нужно в первую очередь.

Распространённым примером ошибки может быть отсутствие тега <!DOCTYPE html> в начале страницы, который помогает информации преобразоваться в разметку. 

Пример прохождения валидации для страницы сайта

Рассмотрим процесс валидации на примере сайта avavax.ru, который создали на WordPress.

В результате проверки валидатор выдал 17 замечаний. После анализа отчета их можно свести к 3 основным:

1. атрибут ‘text/javascript’ не требуется при подключении скрипта;
2. атрибут ‘text/css’ не требуется при подключении стиля;
3. у одного из элементов section нет внутри заголовка h1-h6.

Первое и второе замечания генерирует сам движок WordPress, поэтому разработчикам не нужно их убирать. Третье же замечание предполагает, что каждый блок текста должен иметь заголовок, даже если это не всегда необходимо или видно для читателя. 

Решить проблемы с предупреждениями для стилей и скриптов можно через добавление кода в файл темы function.php.

Для этого на хук wp_loaded нужно повесить функцию output_buffer_start(), которая загрузит весь генерируемый код html в буфер. При выводе в буфер вызывается функция output_callback($tag), которая просматривает все теги, находит нежелательные атрибуты с помощью регулярных выражений и заменяет их пробелами. Затем на хук ‘shutdown вешается функция output_buffer_end(), которая возвращает обработанное содержимое буфера.

Для исправления семантики на сайте нужно использовать заголовки. Валидатор выдаёт предупреждение на секцию about, которая содержит фото и краткий текст. Валидатор требует, чтобы в каждой секции был заголовок. Для исправления предупреждения нужно добавить заголовок, но сделать это  так, чтобы его не было видно пользователям:

1. Добавить заголовок в код:  <h3>Обо мне</h3>

Отключить отображение заголовка:

1 #about h3 {
2 display: none;
3 }

После этой части заголовок будет в коде, но валидатор его увидит, а посетитель — нет. 

За 3 действия удалось убрать все предупреждения, чтобы качество кода устроило валидатор. Это подтверждается зелёной строкой с надписью: “Document checking completed. No errors or warnings to show”.

Как исправить ошибку валидации

Всё зависит от того, какими техническими знаниями обладает владелец ресурса. Он может сделать это сам, вручную. Делать это нужно постепенно, разбирая ошибку за ошибкой. Но нужно понимать, что если при проверке валидатором было выявлено 100 проблем — все 100 нужно обязательно решить. 

Поэтому если навыков и знаний не хватает, лучше привлечь сторонних специалистов для улучшения качества разметки. Это могут быть как фрилансеры, так и профессиональные веб-агентства. При выборе хорошего специалиста, результат будет гарантироваться в любом случае, но лучше, чтобы в договоре оказания услуг будут чётко прописаны цели проведения аудита и гарантии решения проблем с сайтом. 

Если объём работ большой, выгоднее заказать профессиональный аудит сайта. С его помощью можно обнаружить разные виды ошибок, улучшить внешний вид и привлекательность интернет-ресурса для поисковых ботов, обычных пользователей, а также повысить скорость загрузки страниц, сделать качественную верстку и избавиться от переспама.

Плагины для браузеров, которые помогут найти ошибки в коде

Для поиска ошибок валидации можно использовать и встроенные в браузеры плагины. Они помогут быстро находить неточности еще на этапе создания кода. 

Для каждого браузера есть свой адаптивный плагин:

• HTML Validator для браузера Firefox;
• HTML Validator for Chrome;
• HTML5 Editor для Opera.

С помощью этих инструментов можно не допускать проблем, которые помешают нормальному запуску сайта. Плагины помогут оценить качество внешней и внутренней оптимизации, контента и другие характеристики.

Коротко о главном

Валидация — процесс выявления проблем с HTML-разметкой сайта и ее соответствия стандартам W3C. Это унифицированные правила, с помощью которых сайт может нормально работать и отображаться и для поисковых роботов, и для пользователей. 

Проверку ресурса можно проводить тремя путями: валидаторами, специалистам полномасштабного аудита и плагинами в браузере. В большинстве случаев валидатор — самое удобное и быстрое решение для поиска проблем. С его помощью можно выявить 2 типа проблем с разметкой — предупреждения и ошибки. 

Работать необходимо сразу с двумя типами ошибок. Даже если предупреждение не приведет к неисправности сайта, оставлять без внимания проблемные блоки нельзя, так как это снизит привлекательность ресурса в глазах пользователя. Ошибки же могут привести к невозможности отображения блоков на сайте, понижению сайта в поисковой выдаче или полному игнорированию ресурса со стороны поискового бота.

Даже у крупных сайтов с миллионной аудиторией, например, Яндекс.Дзен или ВКонтакте, есть проблемы с кодом. Но комплексный подход к решению проблем помогает устранять серьёзные моменты своевременно. Нужно развивать сайт всесторонне, чтобы получить результат от его существования и поддержки. Если самостоятельно разобраться с проблемами не получается, не стоит “доламывать” — лучше обратиться за помощью к профессионалам, например, агентствам по веб-аудиту. 

200

Ugh… (309, 400, 403, 409, 415, 422)… a lot of answers trying to guess, argue and standardize what is the best return code for a successful HTTP request but a failed REST call.

It is wrong to mix HTTP status codes and REST status codes.

However, I saw many implementations mixing them, and many developers may not agree with me.

HTTP return codes are related to the HTTP Request itself. A REST call is done using a Hypertext Transfer Protocol request and it works at a lower level than invoked REST method itself. REST is a concept/approach, and its output is a business/logical result, while HTTP result code is a transport one.

For example, returning «404 Not found» when you call /users/ is confuse, because it may mean:

• URI is wrong (HTTP)
• No users are found (REST)

«403 Forbidden/Access Denied» may mean:

• Special permission needed. Browsers can handle it by asking the user/password. (HTTP)
• Wrong access permissions configured on the server. (HTTP)
• You need to be authenticated (REST)

And the list may continue with ‘500 Server error» (an Apache/Nginx HTTP thrown error or a business constraint error in REST) or other HTTP errors etc…

From the code, it’s hard to understand what was the failure reason, a HTTP (transport) failure or a REST (logical) failure.

If the HTTP request physically was performed successfully it should always return 200 code, regardless is the record(s) found or not. Because URI resource is found and was handled by the HTTP server. Yes, it may return an empty set. Is it possible to receive an empty web-page with 200 as HTTP result, right?

Instead of this you may return 200 HTTP code with some options:

• «error» object in JSON result if something goes wrong
• Empty JSON array/object if no record found
• A bool result/success flag in combination with previous options for a better handling.

Also, some internet providers may intercept your requests and return you a 404 HTTP code. This does not means that your data are not found, but it’s something wrong at transport level.

From Wiki:

In July 2004, the UK telecom provider BT Group deployed the Cleanfeed
content blocking system, which returns a 404 error to any request for
content identified as potentially illegal by the Internet Watch
Foundation. Other ISPs return a HTTP 403 «forbidden» error in the same
circumstances. The practice of employing fake 404 errors as a means to
conceal censorship has also been reported in Thailand and Tunisia. In
Tunisia, where censorship was severe before the 2011 revolution,
people became aware of the nature of the fake 404 errors and created
an imaginary character named «Ammar 404» who represents «the invisible
censor».

Why not simply answer with something like this?

{
  "result": false,
  "error": {"code": 102, "message": "Validation failed: Wrong NAME."}
}

Google always returns 200 as status code in their Geocoding API, even if the request logically fails: https://developers.google.com/maps/documentation/geocoding/intro#StatusCodes

Facebook always return 200 for successful HTTP requests, even if REST request fails: https://developers.facebook.com/docs/graph-api/using-graph-api/error-handling

It’s simple, HTTP status codes are for HTTP requests. REST API is Your, define Your status codes.

Наличие ошибок в коде страницы сайта всегда влечет за собой негативные последствия – от ухудшения позиций в ранжировании до жалоб со стороны пользователей. Ошибки валидации могут наблюдаться как на главной, так и на иных веб-страницах, их наличие свидетельствует о том, что ресурс является невалидным. Некоторые проблемы замечают даже неподготовленные пользователи, другие невозможно обнаружить без предварительного аудита, анализа. О том, что такое ошибки валидации и как их обнаружить, мы сейчас расскажем.

Ошибка валидации, что это такое?

Для написания страниц используется HTML – стандартизированный язык разметки, применяемый в веб-разработке. HTML, как любой другой язык, имеет специфические особенности синтаксиса, грамматики и т. д. Если во время написания кода правила не учитываются, то после запуска сайта будут появляться различные виды проблем. Если HTML-код ресурса не соответствует стандарту W3C, то он является невалидным, о чем мы писали выше.

Почему ошибки валидации сайта оказывают влияние на ранжирование, восприятие?

Наличие погрешностей в коде – проблема, с которой необходимо бороться сразу после обнаружения. Поисковые системы «читают» HTML-код, если он некорректный, то процесс индексации и ранжирования может быть затруднен. Поисковые роботы должны понимать, каким является ресурс, что он предлагает, какие запросы использует. Особо критичны такие ситуации для ресурсов, имеющих большое количество веб-страниц.

Как проверить ошибки валидации?

Для этой работы используется либо технический аудит сайта, либо валидаторы, которые ищут проблемы автоматически. Одним из самых популярных является сервис The W3C Markup Validation Service, выполняющий сканирование с оглядкой на World Wide Web Consortium (W3C). Рассматриваемый валидатор предлагает три способа, с помощью которых можно осуществить проверку сайта:

• ввод URL-адреса страниц, которые необходимо просканировать;
• загрузка файла страницы;
• ввод части HTML-кода, нуждающегося в проверке.

После завершения проверки вы получите развернутый список выявленных проблем, дополненных описанием, ссылками на стандарты W3C. По ходу анализа вы увидите слабые места со ссылками на правила, что позволит самостоятельно исправить проблему.

Существуют другие сервисы, позволяющие выполнить проверку валидности кода:

• Dr. Watson. Проверяет скорость загрузки страниц, орфографию, ссылки, а также исходный код;
• InternetSupervision.com. Отслеживает производительность сайта, проверяет доступность HTML.

Плагины для браузеров, которые помогут найти ошибки в коде

Решить рассматриваемую задачу можно с помощью плагинов, адаптированных под конкретный браузер. Можно использовать следующие инструменты (бесплатные):

• HTML Validator для браузера Firefox;
• HTML Validator for Chrome;
• Validate HTML для Firefox.

После проверки нужно решить, будете ли вы устранять выявленные ошибки. Многие эксперты акцентируют внимание на том, что поисковые системы сегодня уделяют больше внимания качеству внешней/внутренней оптимизации, контенту, другим характеристикам. Однако валидность нельзя оставлять без внимания, ведь если даже обнаруженные проблемы не будут мешать поисковым ботам, то они точно начнут раздражать посетителей сайта.

Как исправить ошибку валидации?

В первую очередь нужно сосредоточить внимание на слабых местах, связанных с контентом – это то, что важно для поисковых систем. Если во время сканирования было выявлено более 25 проблем, то их нельзя игнорировать из-за ряда причин:

• частичная индексация;
• медленная загрузка;
• баги, возникающие во время непосредственной коммуникации пользователя с ресурсом.

Например, игнорирование ошибок может привести к тому, что некоторые страницы не будут проиндексированы. Для решения рассматриваемой проблемы можно привлечь опытного фрилансера, однако лучшее решение – заказ услуги в веб-агентстве, что позволит исправить, а не усугубить ситуацию.

Технический и SEO-аудит

Выявление ошибок – первый шаг, ведь их еще нужно будет устранить. При наличии большого пула проблем целесообразно заказать профессиональный аудит сайта. Он поможет найти разные виды ошибок, повысит привлекательность ресурса для поисковых ботов, обычных пользователей: скорость загрузки страниц, верстка, переспам, другое.

В заключение

На всех сайтах наблюдаются ошибки валидации – их невозможно искоренить полностью, но и оставлять без внимания не стоит. Например, если провести проверку сайтов Google или «Яндекс», то можно увидеть ошибки, однако это не означает, что стоит вздохнуть спокойно и закрыть глаза на происходящее. Владелец сайта должен ставить во главу угла комплексное развитие, при таком подходе ресурс будет наполняться, обновляться и «лечиться» своевременно. Если проблем мало, то можно попробовать устранить их своими силами или с помощью привлечения стороннего частного специалиста. В остальных случаях лучше заказать услугу у проверенного подрядчика.

Вступление

Laravel предлагает несколько разных подходов для проверки входящих данных вашего приложения. По умолчанию базовый класс контроллера Laravel использует ValidatesRequestsчерту, которая предоставляет удобный метод для проверки входящего HTTP-запроса с помощью множества мощных правил проверки.

Валидация Быстрый старт

Чтобы узнать о мощных функциях проверки Laravel, давайте рассмотрим полный пример проверки формы и отображения сообщений об ошибках пользователю.

Определение маршрутов

Сначала предположим, что в нашем файле определены следующие маршруты :routes/web.php

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

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

GETМаршрут будет отображать форму для пользователя , чтобы создать новое сообщение в блоге, в то время как POSTмаршрут будет хранить запись в блоге в базе данных.

Создание контроллера

Далее, давайте посмотрим на простой контроллер, который обрабатывает эти маршруты. Мы storeпока оставим метод пустым:

<?php

namespace AppHttpControllers;

use IlluminateHttpRequest;
use AppHttpControllersController;

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...
    }
}

Написание логики валидации

Теперь мы готовы заполнить наш storeметод логикой для проверки нового сообщения в блоге. Для этого мы будем использовать validateметод, предоставленный объектом. Если правила проверки пройдут, ваш код будет работать нормально; однако, если проверка не пройдена, будет выдано исключение, и правильный ответ об ошибке будет автоматически отправлен обратно пользователю. В случае традиционного HTTP-запроса будет сгенерирован ответ о перенаправлении, а JSON-ответ будет отправлен для AJAX-запросов.IlluminateHttpRequest

Чтобы лучше понять validateметод, давайте вернемся к storeметоду:

/**
 * 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...
}

Как видите, мы передаем в метод нужные правила валидации validate. Опять же, если проверка не пройдена, автоматически генерируется правильный ответ. Если проверка пройдена, наш контроллер продолжит нормально работать.

Остановка при первом сбое проверки

Иногда может потребоваться прекратить запуск правил проверки для атрибута после первого сбоя проверки. Для этого присвойте bailправило атрибуту:

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

В этом примере, если uniqueправило для titleатрибута не выполнено, maxправило не будет проверено. Правила будут утверждены в порядке их назначения.

Примечание о вложенных атрибутах

Если ваш HTTP-запрос содержит «вложенные» параметры, вы можете указать их в правилах проверки, используя синтаксис «точка»:

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

Отображение ошибок валидации

Итак, что если параметры входящего запроса не соответствуют заданным правилам проверки? Как упоминалось ранее, Laravel автоматически перенаправит пользователя обратно на прежнее место. Кроме того, все ошибки проверки автоматически будут мигать в сеансе .

Опять же, обратите внимание, что нам не нужно было явно привязывать сообщения об ошибках к представлению нашего GETмаршрута. Это потому, что Laravel будет проверять ошибки в данных сеанса и автоматически связывать их с представлением, если они доступны. $errorsПеременная будет экземпляром . Для получения дополнительной информации о работе с этим объектом ознакомьтесь с его документацией .IlluminateSupportMessageBag

$errorsПеременная связана с видом со стороны промежуточного программного обеспечения , которое обеспечивается в группе промежуточного программного обеспечения . Когда применяется это промежуточное программное обеспечение, переменная всегда будет доступна в ваших представлениях , что позволяет вам удобно предполагать, что переменная всегда определена и ее можно безопасно использовать.IlluminateViewMiddlewareShareErrorsFromSessionweb$errors$errors

Таким образом, в нашем примере пользователь будет перенаправлен на createметод нашего контроллера при сбое проверки, что позволит нам отображать сообщения об ошибках в представлении:

<!-- /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 -->

@errorДиректива

Вы также можете использовать директиву @error Blade, чтобы быстро проверить, существуют ли сообщения об ошибках валидации для данного атрибута. Внутри @errorдирективы вы можете вызвать $messageпеременную для отображения сообщения об ошибке:

<!-- /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

Примечание о необязательных полях

По умолчанию Laravel включает TrimStringsи ConvertEmptyStringsToNullпромежуточное ПО в глобальный стек промежуточного ПО вашего приложения. Эти промежуточные программы перечислены в стеке классом. Из-за этого вам часто нужно помечать ваши «необязательные» поля запроса так, как будто вы не хотите, чтобы валидатор считал значения недействительными. Например:AppHttpKernelnullablenull

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

В этом примере мы указываем, что publish_atполе может быть либо nullдействительным представлением даты. Если nullableмодификатор не добавлен в определение правила, валидатор будет считать nullнедопустимую дату.

AJAX-запросы и валидация

В этом примере мы использовали традиционную форму для отправки данных в приложение. Однако многие приложения используют запросы AJAX. При использовании validateметода во время запроса AJAX, Laravel не будет генерировать ответ перенаправления. Вместо этого Laravel генерирует ответ JSON, содержащий все ошибки проверки. Этот ответ JSON будет отправлен с кодом состояния 422 HTTP.

Проверка запроса формы

Создание запросов формы

Для более сложных сценариев проверки вы можете создать «запрос формы». Запросы форм — это пользовательские классы запросов, которые содержат логику проверки. Чтобы создать класс запроса формы, используйте команду Artisan CLI:make:request

php artisan make:request StoreBlogPost

Сгенерированный класс будет помещен в каталог. Если этот каталог не существует, он будет создан при запуске команды. Давайте добавим несколько правил проверки в метод:app/Http/Requestsmake:requestrules

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

Вы можете напечатать любые зависимости, которые вам нужны, в rulesсигнатуре метода. Они будут автоматически разрешены через сервисный контейнер Laravel .

Итак, как оцениваются правила валидации? Все, что вам нужно сделать, это напечатать запрос на метод вашего контроллера. Входящий запрос формы проверяется перед вызовом метода контроллера, что означает, что вам не нужно загромождать ваш контроллер какой-либо логикой проверки:

/**
 * Store the incoming blog post.
 *
 * @param  StoreBlogPost  $request
 * @return Response
 */
public function store(StoreBlogPost $request)
{
    // The incoming request is valid...

    // Retrieve the validated input data...
    $validated = $request->validated();
}

Если проверка не пройдена, будет сгенерирован ответ о перенаправлении, чтобы отправить пользователя обратно в его предыдущее местоположение. Ошибки также будут мигать в сеансе, чтобы они были доступны для отображения. Если запрос был запросом AJAX, пользователю будет возвращен HTTP-ответ с кодом состояния 422, включая JSON-представление ошибок проверки.

Добавление после хуков для формирования запросов

Если вы хотите добавить хук «после» к запросу формы, вы можете использовать withValidatorметод. Этот метод получает полностью сконструированный валидатор, позволяющий вам вызвать любой из его методов до того, как правила валидации действительно будут оценены:

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

Запросы формы авторизации

Класс запроса формы также содержит authorizeметод. В рамках этого метода вы можете проверить, действительно ли аутентифицированный пользователь имеет полномочия на обновление данного ресурса. Например, вы можете определить, действительно ли пользователю принадлежит комментарий в блоге, который он пытается обновить:

/**
 * 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);
}

Поскольку все запросы формы расширяют базовый класс запросов Laravel, мы можем использовать userметод для доступа к аутентифицированному в настоящее время пользователю. Также обратите внимание на вызов routeметода в примере выше. Этот метод предоставляет вам доступ к параметрам URI, определенным на вызываемом маршруте, таким как параметр в примере ниже:{comment}

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

Если authorizeметод возвращается false, HTTP-ответ с кодом состояния 403 будет автоматически возвращен, и ваш метод контроллера не будет выполнен.

Если вы планируете использовать логику авторизации в другой части вашего приложения, вернитесь trueиз authorizeметода:

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

Вы можете напечатать любые зависимости, которые вам нужны, в authorizeсигнатуре метода. Они будут автоматически разрешены через сервисный контейнер Laravel .

Настройка сообщений об ошибках

Вы можете настроить сообщения об ошибках, используемые запросом формы, переопределив messagesметод. Этот метод должен возвращать массив пар атрибут / правило и соответствующие им сообщения об ошибках:

/**
 * 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',
    ];
}

Настройка атрибутов проверки

Если вы хотите, чтобы :attributeчасть вашего сообщения проверки была заменена именем настраиваемого атрибута, вы можете указать настраиваемые имена, переопределив attributesметод. Этот метод должен возвращать массив пар атрибут / имя:

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

Создание валидаторов вручную

Если вы не хотите использовать validateметод в запросе, вы можете создать экземпляр валидатора вручную, используя Validator фасад . makeМетод на фасаде создает новый экземпляр валидатора:

<?php

namespace AppHttpControllers;

use Validator;
use IlluminateHttpRequest;
use AppHttpControllersController;

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...
    }
}

Первым аргументом, переданным makeметоду, являются проверяемые данные. Второй аргумент — это правила проверки, которые должны применяться к данным.

После проверки, не прошла ли проверка запроса, вы можете использовать этот withErrorsметод для отправки сообщений об ошибках в сеанс. При использовании этого метода $errorsпеременная будет автоматически предоставлена ​​вашим представлениям после перенаправления, что позволит вам легко отображать их обратно пользователю. withErrorsМетод принимает валидатор, а MessageBag, или PHP array.

Автоматическое перенаправление

Если вы хотите создать экземпляр валидатора вручную, но все же воспользоваться преимуществами автоматического перенаправления, предлагаемого методом запросов validate, вы можете вызвать validateметод в существующем экземпляре валидатора. Если проверка не пройдена, пользователь будет автоматически перенаправлен или, в случае запроса AJAX, будет возвращен ответ JSON:

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

Именованные пакеты с ошибками

Если у вас есть несколько форм на одной странице, вы можете назвать имена MessageBagошибок, что позволит вам получать сообщения об ошибках для конкретной формы. Передайте имя в качестве второго аргумента withErrors:

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

Затем вы можете получить доступ к именованному MessageBagэкземпляру из $errorsпеременной:

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

После проверки крюк

Валидатор также позволяет вам добавлять обратные вызовы, которые будут выполняться после завершения проверки. Это позволяет вам легко выполнять дальнейшую проверку и даже добавлять больше сообщений об ошибках в коллекцию сообщений. Чтобы начать, используйте afterметод на экземпляре валидатора:

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

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

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

Работа с сообщениями об ошибках

После вызова errorsметода для Validatorэкземпляра вы получите экземпляр, который имеет множество удобных методов для работы с сообщениями об ошибках. Переменная , которая автоматически становится доступной для всех представлений также является экземпляром класса.IlluminateSupportMessageBag$errorsMessageBag

Получение первого сообщения об ошибке для поля

Чтобы получить первое сообщение об ошибке для данного поля, используйте firstметод:

$errors = $validator->errors();

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

Получение всех сообщений об ошибках для поля

Если вам нужно получить массив всех сообщений для данного поля, используйте getметод:

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

Если вы проверяете поле формы массива, вы можете получить все сообщения для каждого из элементов массива, используя *символ:

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

Получение всех сообщений об ошибках для всех полей

Чтобы получить массив всех сообщений для всех полей, используйте allметод:

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

Определение наличия сообщений для поля

hasМетод может быть использован , чтобы определить , существуют ли какие — либо сообщения об ошибках для данного поля:

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

Пользовательские сообщения об ошибках

При необходимости вы можете использовать пользовательские сообщения об ошибках для проверки вместо значений по умолчанию. Есть несколько способов указать пользовательские сообщения. Во-первых, вы можете передать пользовательские сообщения в качестве третьего аргумента методу:Validator::make

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

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

В этом примере :attributeзаполнитель будет заменен действительным именем проверяемого поля. Вы также можете использовать другие заполнители в сообщениях проверки. Например:

$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',
];

Указание пользовательского сообщения для данного атрибута

Иногда вам может потребоваться указать пользовательское сообщение об ошибке только для определенного поля. Вы можете сделать это, используя обозначение «точка». Сначала укажите имя атрибута, а затем правило:

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

Указание пользовательских сообщений в языковых файлах

В большинстве случаев вы, вероятно, будете указывать свои пользовательские сообщения в языковом файле, а не передавать их непосредственно в Validator. Для этого добавьте ваши сообщения в customмассив в языковой файл.resources/lang/xx/validation.php

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

Указание пользовательских атрибутов в языковых файлах

Если вы хотите, чтобы :attributeчасть вашего сообщения проверки была заменена именем настраиваемого атрибута, вы можете указать это имя в attributesмассиве вашего языкового файла:resources/lang/xx/validation.php

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

Указание пользовательских значений в языковых файлах

Иногда вам может понадобиться :valueзаменить часть вашего сообщения для проверки пользовательским представлением значения. Например, рассмотрим следующее правило, которое указывает, что номер кредитной карты требуется, если значение payment_typeимеет cc:

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

Если это правило проверки не выполнено, оно выдаст следующее сообщение об ошибке:

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

Вместо отображения ccв качестве значения типа платежа вы можете указать представление пользовательского значения в вашем validationязыковом файле, определив valuesмассив:

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

Теперь, если правило проверки не выполнено, оно выдаст следующее сообщение:

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

Доступные правила проверки

Ниже приведен список всех доступных правил проверки и их функции:

• Accepted
• Active URL
• After (Date)
• After Or Equal (Date)
• Alpha
• Alpha Dash
• Alpha Numeric
• Array
• Bail
• Before (Date)
• Before Or Equal (Date)
• Between
• Boolean
• Confirmed
• Date
• Date Equals
• Date Format
• Different
• Digits
• Digits Between
• Dimensions (Image Files)
• Distinct
• E-Mail
• Ends With
• Exists (Database)
• File
• Filled
• Greater Than
• Greater Than Or Equal
• Image (File)
• In
• In Array
• Integer
• IP Address
• JSON
• Less Than
• Less Than Or Equal
• Max
• MIME Types
• MIME Type By File Extension
• Min
• Not In
• Not Regex
• Nullable
• Numeric
• Present
• Regular Expression
• Required
• Required If
• Required Unless
• Required With
• Required With All
• Required Without
• Required Without All
• Same
• Size
• Sometimes
• Starts With
• String
• Timezone
• Unique (Database)
• URL
• UUID

accepted

Проверяемое поле должно быть yes , on , 1 или true . Это полезно для подтверждения принятия «Условий обслуживания».

active_url

Проверяемое поле должно иметь действительную запись A или AAAA в соответствии с dns_get_recordфункцией PHP.

after (Date)

Проверяемое поле должно быть значением после указанной даты. Даты будут переданы в strtotimeфункцию PHP:

'start_date' => 'required|date|after:tomorrow'

Вместо того, чтобы передавать строку даты для оценки strtotime, вы можете указать другое поле для сравнения с датой:

'finish_date' => 'required|date|after:start_date'

after_or_equal: date

Проверяемое поле должно быть значением после или равным указанной дате. Для получения дополнительной информации см. Правило после .

alpha

Проверяемое поле должно состоять исключительно из буквенных символов.

alpha_dash

Проверяемое поле может содержать буквенно-цифровые символы, а также тире и подчеркивания.

alpha_num

Проверяемое поле должно состоять из буквенно-цифровых символов.

array

Проверяемое поле должно быть PHP array.

bail

Прекратите запуск правил проверки после первого сбоя проверки.

before (Date)

Проверяемое поле должно быть значением, предшествующим данной дате. Даты будут переданы в strtotimeфункцию PHP . Кроме того, как afterправило, в качестве значения можно указать имя другого проверяемого поля date.

before Or Equal (Date)

Проверяемое поле должно быть значением, предшествующим или равным указанной дате. Даты будут переданы в strtotimeфункцию PHP . Кроме того, как afterправило, в качестве значения можно указать имя другого проверяемого поля date.

between:min,max

Проверяемое поле должно иметь размер от заданного минимального до максимального значения . Строки, числа, массивы и файлы оцениваются так же, как sizeправило.

boolean

Проверяемое поле должно быть в состоянии быть логическим. Принимаемые входные true, false, 1, 0, "1", и "0".

confirmed

Проверяемое поле должно иметь соответствующее поле foo_confirmation. Например, если проверяемое поле имеет значение password, соответствующее password_confirmationполе должно присутствовать во входных данных.

date

Проверяемое поле должно быть действительной, не относительной датой в соответствии с strtotimeфункцией PHP.

date_equals: date

Проверяемое поле должно быть равно заданной дате. Даты будут переданы в strtotimeфункцию PHP .

date_format: format

Проверяемое поле должно соответствовать заданному формату . Вы должны использовать либоdate или date_formatпри проверке поля, но не оба.

different:field

Проверяемое поле должно иметь значение, отличное от поля .

digits:value

Проверяемое поле должно быть числовым и иметь точную длину значения .

digits_between:min,max

Проверяемое поле должно иметь длину от заданного минимального до максимального значения .

dimensions

Проверяемый файл должен быть изображением, соответствующим ограничениям размеров, указанным в параметрах правила:

'avatar' => 'dimensions:min_width=100,min_height=200'

Доступны следующие ограничения: min_width , max_width , min_height , max_height , ширина , высота , коэффициент .

Отношение ограничение должно быть представлено в виде ширины , деленная на высоту. Это может быть указано либо с помощью оператора like или с плавающей точкой :3/21.5

'avatar' => 'dimensions:ratio=3/2'

Так как это правило требует нескольких аргументов, вы можете использовать метод для свободного создания правила:Rule::dimensions

use IlluminateValidationRule;

Validator::make($data, [
    'avatar' => [
        'required',
        Rule::dimensions()->maxWidth(1000)->maxHeight(500)->ratio(3 / 2),
    ],
]);

distinct

При работе с массивами проверяемое поле не должно иметь повторяющихся значений.

'foo.*.id' => 'distinct'

email

Проверяемое поле должно быть отформатировано как адрес электронной почты.

ends_with:foo,bar,…

Проверяемое поле должно заканчиваться одним из указанных значений.

exists:table,column

Проверяемое поле должно существовать в данной таблице базы данных.

Основное использование правила существования

'state' => 'exists:states'

Если columnопция не указана, будет использовано имя поля.

Указание пользовательского имени столбца

'state' => 'exists:states,abbreviation'

Иногда вам может потребоваться указать конкретное соединение с базой данных, которое будет использоваться для existsзапроса. Это можно сделать, добавив имя соединения к имени таблицы, используя синтаксис «точка»:

'email' => 'exists:connection.staff,email'

Если вы хотите настроить запрос, выполняемый правилом валидации, вы можете использовать Ruleкласс для свободного определения правила. В этом примере мы также указываем правила проверки в виде массива вместо использования |символа для их разделения:

use IlluminateValidationRule;

Validator::make($data, [
    'email' => [
        'required',
        Rule::exists('staff')->where(function ($query) {
            $query->where('account_id', 1);
        }),
    ],
]);

file

Проверяемое поле должно быть успешно загруженным файлом.

filled

Проверяемое поле не должно быть пустым, если оно присутствует.

gt:field

Проверяемое поле должно быть больше указанного поля . Два поля должны быть одного типа. Строки, числа, массивы и файлы оцениваются с использованием тех же соглашений, что и sizeправило.

gte:field

Проверяемое поле должно быть больше или равно данному полю . Два поля должны быть одного типа. Строки, числа, массивы и файлы оцениваются с использованием тех же соглашений, что и sizeправило.

image

Проверяемый файл должен быть изображением (jpeg, png, bmp, gif или svg)

in:foo,bar,…

Проверяемое поле должно быть включено в данный список значений. Поскольку для этого правила часто требуется implodeмассив, метод может быть использован для свободного построения правила:Rule::in

use IlluminateValidationRule;

Validator::make($data, [
    'zones' => [
        'required',
        Rule::in(['first-zone', 'second-zone']),
    ],
]);

in_array:anotherfield.*

Проверяемое поле должно существовать в значениях другого поля .

integer

Проверяемое поле должно быть целым числом.

ip

Проверяемое поле должно быть IP-адресом.

ipv4

Проверяемое поле должно быть адресом IPv4.

ipv6

Проверяемое поле должно быть адресом IPv6.

json

Проверяемое поле должно быть допустимой строкой JSON.

lt:field

Проверяемое поле должно быть меньше указанного поля . Два поля должны быть одного типа. Строки, числа, массивы и файлы оцениваются с использованием тех же соглашений, что и sizeправило.

lte:field

Проверяемое поле должно быть меньше или равно данному полю . Два поля должны быть одного типа. Строки, числа, массивы и файлы оцениваются с использованием тех же соглашений, что и sizeправило.

max:value

Проверяемое поле должно быть меньше или равно максимальному значению . Строки, числа, массивы и файлы оцениваются так же, как sizeправило.

mimetypes:text/plain,…

Проверяемый файл должен соответствовать одному из указанных типов MIME:

'video' => 'mimetypes:video/avi,video/mpeg,video/quicktime'

Чтобы определить тип MIME загруженного файла, его содержимое будет прочитано, и платформа попытается угадать тип MIME, который может отличаться от типа MIME, предоставленного клиентом.

mimes:foo,bar,…

Проверяемый файл должен иметь тип MIME, соответствующий одному из перечисленных расширений.

Основное использование правила MIME

'photo' => 'mimes:jpeg,bmp,png'

Несмотря на то, что вам нужно только указать расширения, это правило фактически проверяет тип файла MIME, читая содержимое файла и угадывая его тип MIME.

Полный список типов MIME и их соответствующих расширений можно найти по следующему адресу : https://svn.apache.org/repos/asf/httpd/httpd/trunk/docs/conf/mime.types.

min:value

Проверяемое поле должно иметь минимальное значение . Строки, числа, массивы и файлы оцениваются так же, как sizeправило.

not_in:foo,bar,…

Проверяемое поле не должно быть включено в данный список значений. Метод может быть использован для построения свободно правила:Rule::notIn

use IlluminateValidationRule;

Validator::make($data, [
    'toppings' => [
        'required',
        Rule::notIn(['sprinkles', 'cherries']),
    ],
]);

not_regex:pattern

Проверяемое поле не должно соответствовать заданному регулярному выражению.

Внутренне это правило использует preg_matchфункцию PHP . Указанный шаблон должен соответствовать форматированию, требуемому для этого, preg_matchи, следовательно, также включать допустимые разделители. Например: .'email' => 'not_regex:/^.+$/i'

Примечание. При использовании шаблонов regex/ not_regexможет потребоваться указать правила в массиве вместо использования разделителей канала, особенно если регулярное выражение содержит символ канала.

nullable

Проверяемое поле может быть null. Это особенно полезно при проверке примитивов, таких как строки и целые числа, которые могут содержать nullзначения.

numeric

Проверяемое поле должно быть числовым.

present

Проверяемое поле должно присутствовать во входных данных, но может быть пустым.

regex:pattern

Проверяемое поле должно соответствовать заданному регулярному выражению.

Внутренне это правило использует preg_matchфункцию PHP . Указанный шаблон должен соответствовать форматированию, требуемому для этого, preg_matchи, следовательно, также включать допустимые разделители. Например: .'email' => 'regex:/^.+@.+$/i'

Примечание. При использовании шаблонов regex/ not_regexможет потребоваться указать правила в массиве вместо использования разделителей канала, особенно если регулярное выражение содержит символ канала.

required

Проверяемое поле должно присутствовать во входных данных и не быть пустым. Поле считается «пустым», если выполняется одно из следующих условий:

• Значение есть null.
• Значение является пустой строкой.
• Значением является пустой массив или пустой Countableобъект.
• Значением является загруженный файл без пути.

required_if:anotherfield,value,…

Проверяемое поле должно присутствовать и не быть пустым, если поле другого поля равно какому-либо значению .

Если вы хотите построить более сложное условие для required_ifправила, вы можете использовать метод. Этот метод принимает логическое значение или замыкание. Когда передано Закрытие, Закрытие должно возвратиться или указать, требуется ли проверяемое поле:Rule::requiredIftruefalse

use IlluminateValidationRule;

Validator::make($request->all(), [
    'role_id' => Rule::requiredIf($request->user()->is_admin),
]);

Validator::make($request->all(), [
    'role_id' => Rule::requiredIf(function () use ($request) {
        return $request->user()->is_admin;
    }),
]);

required_unless:anotherfield,value,…

Проверяемое поле должно присутствовать и не быть пустым, если поле другого поля не равно какому-либо значению .

required_with:foo,bar,…

Проверяемое поле должно присутствовать и не быть пустым, только если присутствуют какие-либо другие указанные поля.

required_with_all:foo,bar,…

Проверяемое поле должно присутствовать и не быть пустым, только если присутствуют все другие указанные поля.

required_without:foo,bar,…

Проверяемое поле должно присутствовать и не быть пустым, только если нет других указанных полей.

required_without_all:foo,bar,…

Проверяемое поле должно присутствовать и не быть пустым, только если все другие указанные поля отсутствуют.

same:field

Данное поле должно соответствовать проверяемому полю.

size:value

Проверяемое поле должно иметь размер, соответствующий заданному значению . Для строковых данных значение соответствует количеству символов. Для числовых данных значениесоответствует заданному целочисленному значению. Для массива размер соответствует countмассиву. Для файлов размер соответствует размеру файла в килобайтах.

starts_with:foo,bar,…

Проверяемое поле должно начинаться с одного из указанных значений.

string

Проверяемое поле должно быть строкой. Если вы хотите, чтобы поле также было null, вы должны назначить nullableправило для поля.

timezone

Проверяемое поле должно быть действительным идентификатором часового пояса в соответствии с timezone_identifiers_listфункцией PHP.

unique:table,column,except,idColumn

Проверяемое поле не должно существовать в данной таблице базы данных.

Указание пользовательского имени столбца:

columnВариант может быть использован для определения соответствующего столбца базы данных в полях. Если columnопция не указана, будет использовано имя поля.

'email' => 'unique:users,email_address'

Настраиваемое соединение с базой данных

Иногда вам может понадобиться установить пользовательское соединение для запросов к базе данных, выполняемых валидатором. Как показано выше, при настройке в качестве правила проверки будет использоваться соединение с базой данных по умолчанию для запроса к базе данных. Чтобы переопределить это, укажите соединение и имя таблицы, используя синтаксис «точка»:unique:users

'email' => 'unique:connection.users,email_address'

Принудительное уникальное правило игнорирования заданного идентификатора:

Иногда вы можете игнорировать данный идентификатор во время уникальной проверки. Например, рассмотрим экран «Обновить профиль», который включает имя пользователя, адрес электронной почты и местоположение. Возможно, вы захотите убедиться, что адрес электронной почты является уникальным. Однако, если пользователь изменяет только поле имени, а не поле электронной почты, вы не хотите, чтобы выдавалась ошибка проверки, поскольку пользователь уже является владельцем адреса электронной почты.

Чтобы поручить валидатору игнорировать идентификатор пользователя, мы будем использовать Ruleкласс для свободного определения правила. В этом примере мы также указываем правила проверки в виде массива вместо использования |символа для разделения правил:

use IlluminateValidationRule;

Validator::make($data, [
    'email' => [
        'required',
        Rule::unique('users')->ignore($user->id),
    ],
]);

Вы никогда не должны передавать какой-либо пользовательский ввод запроса в ignoreметод. Вместо этого вы должны передавать только сгенерированный системой уникальный идентификатор, такой как идентификатор с автоматическим увеличением или UUID, из экземпляра модели Eloquent. В противном случае ваше приложение будет уязвимо для атаки SQL-инъекцией.

Вместо того, чтобы передавать значение ключа модели в ignoreметод, вы можете передать весь экземпляр модели. Laravel автоматически извлечет ключ из модели:

Rule::unique('users')->ignore($user)

Если ваша таблица использует имя столбца первичного ключа, отличное от id, вы можете указать имя столбца при вызове ignoreметода:

Rule::unique('users')->ignore($user->id, 'user_id')

По умолчанию uniqueправило проверяет уникальность столбца, совпадающего с именем проверяемого атрибута. Однако вы можете передать другое имя столбца в качестве второго аргумента uniqueметода:

Rule::unique('users', 'email_address')->ignore($user->id),

Добавление дополнительных предложений Where:

Вы также можете указать дополнительные ограничения запроса, настроив запрос с помощью whereметода. Например, давайте добавим ограничение , которое проверяет account_idIS 1:

'email' => Rule::unique('users')->where(function ($query) {
    return $query->where('account_id', 1);
})

url​​​​​​​

Проверяемое поле должно быть действительным URL.

uuid​​​​​​​

Проверяемое поле должно быть действительным универсальным уникальным идентификатором (UUID) RFC 4122 (версия 1, 3, 4 или 5).

Условия добавления правил

Проверка при наличии

В некоторых ситуациях вам может потребоваться выполнить проверки правильности для поля, только если это поле присутствует во входном массиве. Чтобы быстро это сделать, добавьте sometimesправило в список правил:

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

В приведенном выше примере emailполе будет проверено, только если оно присутствует в $dataмассиве.

Если вы пытаетесь проверить поле, которое всегда должно присутствовать, но может быть пустым, ознакомьтесь с этим примечанием к дополнительным полям

Комплексная условная проверка

Иногда вы можете захотеть добавить правила проверки, основанные на более сложной условной логике. Например, вам может потребоваться указать данное поле только в том случае, если другое поле имеет значение больше 100. Или вам может потребоваться, чтобы два поля имели заданное значение только при наличии другого поля. Добавление этих правил проверки не должно быть проблемой. Сначала создайте Validatorэкземпляр со своими статическими правилами,которые никогда не меняются:

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

Давайте предположим, что наше веб-приложение предназначено для коллекционеров игр. Если коллекционер игр регистрируется в нашем приложении и им принадлежит более 100 игр, мы хотим, чтобы они объяснили, почему у них так много игр. Например, возможно, они управляют магазином перепродажи игр, или, возможно, им просто нравится коллекционировать. Чтобы условно добавить это требование, мы можем использовать sometimesметод в Validatorэкземпляре.

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

Первым аргументом, переданным sometimesметоду, является имя поля, которое мы условно проверяем. Второй аргумент — это правила, которые мы хотим добавить. Если Closureпередано в качестве третьего аргумента true, правила будут добавлены. Этот метод позволяет легко создавать сложные условные проверки. Вы можете даже добавить условные проверки для нескольких полей одновременно:

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

$inputПараметр , переданный к вашему Closureбудет экземпляром и может использоваться для доступа к вашему вводу и файлам.IlluminateSupportFluent

Проверка массивов

Проверка полей ввода на основе массива не должна быть проблемой. Вы можете использовать «точечную нотацию» для проверки атрибутов в массиве. Например, если входящий HTTP-запрос содержит поле, вы можете проверить его следующим образом:photos[profile]

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

Вы также можете проверить каждый элемент массива. Например, чтобы проверить, что каждое электронное письмо в данном поле ввода массива уникально, вы можете сделать следующее:

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

Аналогичным образом, вы можете использовать этот *символ при указании ваших сообщений проверки в ваших языковых файлах, что позволяет без труда использовать одно сообщение проверки для полей на основе массива:

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

Пользовательские правила проверки

Использование объектов правил

Laravel предлагает множество полезных правил проверки; тем не менее, вы можете указать свои собственные. Одним из способов регистрации пользовательских правил проверки является использование объектов правил. Чтобы создать новый объект правила, вы можете использовать команду Artisan. Давайте использовать эту команду для генерации правила, которое проверяет строку в верхнем регистре. Laravel поместит новое правило в каталог:make:ruleapp/Rules

php artisan make:rule Uppercase

Как только правило было создано, мы готовы определить его поведение. Объект правила содержит два метода: passesи message. passesМетод получает значение атрибута и имя, и он должен возвращать trueили в falseзависимости от того, является ли или нет значение атрибута. messageМетод должен возвращать сообщение об ошибке проверки , которая должна использоваться при сбое проверки:

<?php

namespace AppRules;

use IlluminateContractsValidationRule;

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.';
    }
}

Вы можете вызвать transпомощника из вашего messageметода, если хотите вернуть сообщение об ошибке из ваших файлов перевода:

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

Как только правило было определено, вы можете присоединить его к валидатору, передав экземпляр объекта правила с другими вашими правилами валидации:

use AppRulesUppercase;

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

Использование замыканий

Если вам требуется функциональность настраиваемого правила только один раз в приложении, вы можете использовать Closure вместо объекта правила. Замыкание получает имя атрибута, значение атрибута и $failобратный вызов, который должен быть вызван в случае сбоя проверки:

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

Использование расширений

Другой метод регистрации пользовательских правил проверки — использование extendметода на Validator фасаде . Давайте использовать этот метод в сервис-провайдере для регистрации пользовательского правила проверки:

<?php

namespace AppProviders;

use IlluminateSupportServiceProvider;
use IlluminateSupportFacadesValidator;

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';
        });
    }
}

Пользовательский валидатор Closure получает четыре аргумента: имя $attributeпроверяемого $valueобъекта, атрибута, массив, $parametersпередаваемый правилу, и Validatorэкземпляр.

Вы также можете передать класс и метод в extendметод вместо Closure:

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

Определение сообщения об ошибке

Вам также необходимо определить сообщение об ошибке для вашего пользовательского правила. Это можно сделать либо с помощью встроенного пользовательского массива сообщений, либо добавив запись в файл языка проверки. Это сообщение должно быть помещено в первый уровень массива, а не в customмассив, который предназначен только для сообщений об ошибках, относящихся к атрибуту:

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

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

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

При создании пользовательского правила проверки иногда может потребоваться определить пользовательские замены заполнителей для сообщений об ошибках. Вы можете сделать это, создав пользовательский Validator, как описано выше, затем вызвав replacerметод на Validatorфасаде. Вы можете сделать это в рамках bootметода поставщика услуг :

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

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

Неявные расширения

По умолчанию, когда проверяемый атрибут отсутствует или содержит пустую строку, обычные правила проверки, включая пользовательские расширения, не запускаются. Например, unique правило не будет запущено для пустой строки:

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

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

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

Чтобы правило запускалось, даже если атрибут пуст, правило должно подразумевать, что атрибут является обязательным. Чтобы создать такое «неявное» расширение, используйте метод:Validator::extendImplicit()

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

«Неявное» расширение подразумевает, что атрибут является обязательным. Независимо от того, действительно ли он аннулирует отсутствующий или пустой атрибут, зависит от вас.

Разберем, насколько критическими для работы сайта и его продвижения могут быть ошибки в HTML-коде, и зачем нужны общие стандарты верстки.

Что такое валидность кода

После разработки дизайна программисты верстают страницы сайта — приводят их к единой структуре в формате HTML. Задача верстальщика — сделать так, чтобы страницы отображались корректно у всех пользователей на любых устройствах и браузерах. Такая верстка называется кроссплатформенной и кроссбраузерной — это обязательное требование при разработке любых сайтов.

Для этого есть специальные стандарты: если им следовать, страницу будут корректно распознавать все браузеры и гаджеты. Такой стандарт разработал Консорциумом всемирной паутины — W3C (The World Wide Web Consortium). HTML-код, который ему соответствует, называют валидным.

Валидность также касается файлов стилей — CSS. Если в CSS есть ошибки, визуальное отображение элементов может нарушиться.

Разработчикам рекомендуется следовать критериям этих стандартов при верстке — это поможет избежать ошибок в коде, которые могут навредить сайту.

Чем ошибки в HTML грозят сайту

Типичные ошибки кода — незакрытые или дублированные элементы, неправильные атрибуты или их отсутствие, отсутствие кодировки UTF-8 или указания типа документа.

Какие проблемы могут возникнуть из-за ошибок в HTML-коде

• страницы загружаются медленно;
• сайт некорректно отображается на разных устройствах или в браузерах;
• посетители видят не весь контент;
• программист не замечает скрытую рекламу и вредоносный код.

Как валидность кода влияет на SEO

Валидность не является фактором ранжирования в Яндекс или Google, так что напрямую она не влияет на позиции сайта в выдаче поисковых систем. Но она влияет на мобилопригодность сайта и на то, как поисковые боты воспринимают разметку, а от этого косвенно могут пострадать позиции или трафик.

Почитать по теме:
Главное о микроразметке: подборка знаний для веб-мастеров

Представитель Google Джон Мюллер говорил о валидности кода:

«Мы упомянули использование правильного HTML. Является ли фактором ранжирования валидность HTML стандарту W3C?

Это не прямой фактор ранжирования. Если ваш сайт использует HTML с ошибками, это не значит, что мы удалим его из индекса — я думаю, что тогда у нас будут пустые результаты поиска.
Но есть несколько важных аспектов:

— Если у сайта действительно битый HTML, тогда нам будет очень сложно его отсканировать и проиндексировать.
— Иногда действительно трудно подобрать структурированную разметку, если HTML полностью нарушен, поэтому используйте валидатор разметки.
— Другой аспект касается мобильных устройств и поддержки кроссбраузерности: если вы сломали HTML, то сайт иногда очень трудно рендерить на новых устройствах».

Итак, критические ошибки в HTML мешают

• сканированию сайта поисковыми ботами;
• определению структурированной разметки на странице;
• рендерингу на мобильных устройствах и кроссбраузерности.

Даже если вы уверены в своем коде, лучше его проверить — ошибки могут возникать из-за установки тем, сторонних плагинов и других элементов, и быть незаметными. Не все программисты ориентируются на стандарт W3C, так что среди готовых решений могут быть продукты с ошибками, особенно среди бесплатных.

Как проверить код на валидность

Не нужно вычитывать код и считать символы — для этого есть сервисы и инструменты проверки валидности HTML онлайн.

Что они проверяют:

• Синтаксис
  Синтаксические ошибки: пропущенные символы, ошибки в написании тегов.
• Вложенность тэгов
  Незакрытые и неправильно закрытые теги. По правилам теги закрываются также, как их открыли, но в обратном порядке. Частая ошибка — нарушенная вложенность

  .

• DTD (Document Type Definition)
  Соответствие кода указанному DTD, правильность названий тегов, вложенности, атрибутов. Наличие пользовательских тегов и атрибутов — то, чего нет в DTD, но есть в коде.

Обычно сервисы делят результаты на ошибки и предупреждения. Ошибки — опечатки в коде, пропущенные или лишние символы, которые скорее всего создадут проблемы. Предупреждения — бессмысленная разметка, лишние символы, какие-то другие ошибки, которые скорее всего не навредят сайту, но идут вразрез с принятым стандартом.

Валидаторы не всегда правы — некоторые ошибки не мешают браузерам воспринимать код корректно, зато, к примеру, минификация сокращает длину кода, удаляя лишние пробелы, которые не влияют на его отображение.

Почитать по теме:
Уменьшить вес сайта с помощью gzip, brotli, минификации и других способов

Поэтому анализируйте предложения сервисов по исправлениям и ориентируйтесь на здравый смысл.

Перед исправлением ошибок не забудьте сделать резервное копирование. Если вы исправите код, но что-то пойдет не так и он перестанет отображаться, как должен, вы сможете откатить все назад.

HTML и CSS валидаторы — онлайн-сервисы для проверки кода

Есть довольно много валидаторов, выберите тот, в котором вам удобнее работать. Мы рекомендуем использовать известные сервисы от создателей стандартов. Если пояснения на английском воспринимать сложно, можно использовать автоматический перевод страницы.

Валидатор от W3C

Англоязычный сервис, онлайн проверяет соответствие HTML стандартам: можно проверить код по URL, залить файл или вставить код в окошко.

Инструмент покажет список ошибок и предупреждений с пояснениями — описанием ошибки и ее типом, а также укажет номер строки, в которой нужно что-то исправить. Цветом отмечены типы предупреждений и строчки с кодом.

Валидатор CSS от W3C

Инструмент от W3C для проверки CSS, есть русский язык. Работает по такому же принципу, анализирует стили на предмет ошибок и предупреждений. Первым идет блок ошибок, предупреждения собраны ниже отдельно.

Исправления ошибок и валидации HTML и CSS может быть недостаточно: всегда есть другие возможности испортить отображение сайта. Если что-то не работает, как надо, проведите полноценный аудит, чтобы найти ошибки.

С другой стороны, не зацикливайтесь на поиске недочетов в HTML — если код работает, а контент отображается корректно, лучше направить ресурсы на что-то другое — оптимизацию и ускорение загрузки, например.

Была ли эта статья полезна?

Есть вопрос?

Закажите недорогой хостинг

Заказать

всего от 290 руб