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

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

В собственных проектах вы можете спокойно оставить всё как есть, однако, заказчика со стороны такая ситуация не всегда устраивает. Чаще всего проще устранить ворнинг, вместо того, чтобы долго и нудно объяснять, что на самом деле речь идёт о допустимой семантике.

Давайте рассмотрим на практическом примере.

Замечания валидатора


Я прогнал главную страницу сайта avavax.ru через validator.w3.org и получил 17 замечаний. По факту их всего 3. И они, в общем, типичны для большинства сайтов на WordPress.

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

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

Ворнинг 3 идёт из вёрстки. С точки зрения валидатора в каждой секции должен быть заголовок, хотя в реальной жизни он нам нужен не всегда.

Решение проблем

Убираем лишние атрибуты при подключении стилей и скриптов.

Для этого в файл темы function.php добавим вот такой код:

add_action('wp_loaded', 'output_buffer_start');
function output_buffer_start() { 
    ob_start("output_callback"); 
}
add_action('shutdown', 'output_buffer_end');
function output_buffer_end() { 
    ob_end_flush(); 
}
function output_callback($tag) {
    return preg_replace( "%[ ]type=[\'\"]text\/(javascript|css)[\'\"]%", '', $tag);
}

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

Как уже понял догадливый читатель, использование этого способа не добавляет сайту быстродействия. Немного улучшить проблему со скоростью загрузки можно если отказаться от красивого решения с регулярными выражениями и воспользоваться встроенной функцией str_replace(). При этом функция output_callback($tag) примет такой вид.

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

Исправляем семантику секции

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

<h3>Обо мне</h3>

И отключаем отображение:

#about h3 {
    display: none;
}

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

Заливаем изменения на сервер, проверяем. Валидатор доволен и радует нас зелёным цветом.

Вместо эпилога

Теперь вы знаете, как заставить сайт на WordPress пройти валидатор «на пятёрку». В целом, валидация html-кода – отличная вещь. Она позволяет вам находить незакрытые теги, дублирующиеся h1 заголовки, семантические ошибки. Однако слепое стремление к совершенной валидации не всегда уместно. Многие замечания никак не отразятся на работе сайта, а вот устранение их может серьёзно отразиться на скорости работы. Поэтому всегда здраво оценивайте, когда нужно вовремя остановиться в погоне за идеалом.