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

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

В этой статье рассмотрим, что такое валидность, какие могут быть ошибки в 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 типа проблем с разметкой — предупреждения и ошибки. 

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

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

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

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

Для написания страниц используется 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 или «Яндекс», то можно увидеть ошибки, однако это не означает, что стоит вздохнуть спокойно и закрыть глаза на происходящее. Владелец сайта должен ставить во главу угла комплексное развитие, при таком подходе ресурс будет наполняться, обновляться и «лечиться» своевременно. Если проблем мало, то можно попробовать устранить их своими силами или с помощью привлечения стороннего частного специалиста. В остальных случаях лучше заказать услугу у проверенного подрядчика.

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

Проверить сайт на валидность важно по нескольким причинам:

• выявить ошибки и устранить их
• для каждого пользователя ( зависит от его браузера и версии ) страница может отображаться по-разному. Браузеры смогут отобразить страницу с небольшими огрехами, но каждый отобразит по-своему.
• если браузеры могут автоматически исправить маленькие недочеты, то поисковые системы замечают любую погрешность. К примеру на западе поисковики серьезно относятся к валидности сайтов, у нас уже тоже не исключение.

Всему этому необходимо следовать. А задает эти нормы W3C Консорциум Всемирной паутины ( World Wide Web Consortium ).

Проверка HTML кода на валидность

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

 Validate by URI — проверка по URL
Validate by File Upload — проверить загружаемый файл
Validate by Direct Input — вставка и проверка участка кода

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

Подмечу, что часто достаточно исправить 1 или пару ошибок, чтобы сайт полностью соответствовал правилам. ( Например, в этом случае достаточно было сделать 1 исправление в 1 файле, чтобы пропало 5 ошибок ).

Далее будет выведен список ошибок и их решение.

Все на английском, правда в валидаторе есть полезная опция «Clean up Markup with HTML-Tidy», ниже расскажу о ней.

Также  можно будет выбрать дополнительные опции при проверке на валидность:

• Show Source – отобразить исходный код вашей страницы
• Show Outline – показать строку, где есть ошибки
• Validate error pages – проверить страницы ошибок, например 404 — страницы не существует
• List Messages Sequentially – показать ошибки и предупреждения списком, последовательно
• Group Error Messages by Type – группировать ошибки с общими признаками
• Clean up Markup with HTML Tidy — программа HTML Tidy выводит исправленный код, не входит в состав W3C validator, поэтому не гарантируется полная корректность

Исправление ошибок валидности

Теперь попытаемся разобраться как исправлять ошибки.

1. Копируем строчку с ошибкой ( … не копируем, это продолжение кода )

2. Определяем в каком файле она находится. Открываем сайт, CTRL + U просматриваем исходный код страницы и ищем ошибку CTRL + F. Часто ошибка не связана с файлами шаблона, она может находиться в файлах плагинов, либо в подпапках вашего шаблона, поэтому нужны некоторые знания

3. Далее открываем файл и при помощи записи под ошибкой, либо при помощи программы HTML Tidy ( включаем опцию вверху страницы валидатора), в таком случае ищем уже исправленный код ( просто копируйте код на 2-3 символа до красного выделения ). И исправляем.

Часто встречаемые ошибки валидации

Тег noindex

Пример:
<noindex> <a rel=»nofollow» href=»…» >…</a></noindex>

Ошибка валидатора: You have used the element named above in your document, but the document type you are using does not define an element of that name

Пояснение: noindex — не входит официальную спецификацию тега языка гипертекстовой разметки веб-страниц HTML. Также полезно знать, что ЯНДЕКС учитывает, как и Google, Yahoo и Bing, rel=»nofollow»

Правильно:
<a rel=»nofollow» href=»…» >…</a>

Пример:
<a href="index.php?pid=1&id=2">...</a>

Ошибка валидатора: Unknown entity…

Пояснение:  использовать &amp; вместо &

Правильно:
<a href="index.php?pid=1&amp;id=2">...</a>

Неверная вложенность

Пример:
<strong><li>...</strong></li>

Ошибка валидатора: Missing </li> tag

Пояснение: элементы должны быть закрыты в обратном порядке их открытию

Правильно:
<strong><li>...</li></strong>

Чувствительность DOCTYPE к регистру

Пример:
<!doctype html public "-//w3c//dtd xhtml 1.0 transitional//en" "http://www.w3.org/tr/xhtml1/dtd/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" >

Ошибка валидатора: Missing DOCTYPE

Пояснение: DOCTYPE зависим к регистру

Правильно:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="<a>http://www.w3.org/1999/xhtml</a>" >

Не прописан закрывающий «/»

Пример:
…style.css" type="text/css" media="screen">

Пояснение:  «пустые элементы», как img или br, должны заканчиваться»/» c пробелом перед этим

Правильно:
…style.css» type=»text/css» media=»screen» />

Тэги прописаны в верхнем регистре

Пример:
<STRONG><LI>...</LI></STRONG>

Ошибка валидатора: There is no such element…

Пояснение: в XHTML документах все элементы и атрибуты должны быть в нижнем регистре, т.к. этот язык регистрозависим и для него <li> и <LI> разные тэги

Правильно:
<strong><li>...</li></strong>

Значения атрибутов прописаны без кавычек

Пример:
<style type=text/css>...</style>

Ошибка валидатора: Missing » »

Пояснение: значения атрибутов пишутся вместе с кавычками

Правильно:
<style type="text/css">...</style>

У img отсутствует атрибут alt

Пример:

<img src="/image/1.png" height="10" width="10" alt="" title="">

Ошибка валидатора: required attribute «alt» not specified

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

Правильно:

<img src="/image/1.png" height="10" width="10" alt="" title="">

В итоге вы сможете исправить ошибки сайта и сделать сайт валидным.

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

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

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

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

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

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

Что такое отладка?

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

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

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

1. WP_DEBUG

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

Чтобы включить WP_DEBUG, вам нужно выполнить некоторое кодирование, отредактировав файл wp-config.php и добавив необходимые строки, чтобы команда записала все действия в журнале. Эта задача кодирования не для всех: вам нужно быть очень осторожным при редактировании файла wp-config.php, потому что, если вы пропустите строку или даже символ, ваш сайт может перестать работать. Кроме того, сделайте резервную копию вашего сайта/файлов, прежде чем делать что-либо. Если вы все испортите, вы можете восстановить резервную копию и откатить все обратно до нормального состояния.

Чтобы отредактировать файл wp-config.php, используйте файловый менеджер вашего хостинг-провайдера или используйте FTP-клиент, чтобы загрузить файл и открыть его локально в предпочитаемом вами текстовом редакторе. Файл находится в главном каталоге вашей установки WordPress. После того, как вы откроете его, найдите строку, где определен WP_DEBUG. Это должно выглядеть так:

define('WP_DEBUG', false);

Если такой строки нет, поищите следующий комментарий:

/* That’s all, stop editing! Happy blogging. */

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

define('WP_DEBUG', true); 
define('WP_DEBUG_LOG', true); 
define('WP_DEBUG_DISPLAY', false); 
@ini_set('display_errors',0);

Сохраните измененный файл и, если вы используете FTP, загрузите его на свой сайт. Затем попытайтесь спровоцировать ошибку (или дождитесь ее появления) и проверьте файл debug.log. Вы найдете его в папке wp-content вашей установки WordPress. Вы можете открыть его с помощью текстового редактора и найти сообщения об ошибках, которые показывают, что вызывает проблемы на вашем сайте.

После этого вы должны отключить ведение журнала, изменив значения true на false во всех строках, которые вы добавили или изменили в файле wp-config.php.

2. Отчеты об ошибках WPDB

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

Вы не должны делать это на живом веб-сайте, если вам все равно, будут ли ваши посетители получать сообщения об ошибках на своих экранах. Лучше использовать промежуточный веб-сайт (как описано ниже), где вы можете протестировать все, что хотите, не позволяя всем увидеть, что происходит под капотом.

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

Чтобы начать генерировать отчеты об ошибках базы данных, добавьте в файл wp-config.php следующую строку (так же, как описано выше, для создания журнала отладки):

define('SAVEQUERIES', true);

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

global $wpdb; 
print_r($wpdb->queries);

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

3. Использование промежуточного сайта

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

Важно, чтобы промежуточный веб-сайт точно отражал содержание и структуру вашего фактического веб-сайта. Всякий раз, когда вы обновляете свой сайт WordPress новым контентом или новыми надстройками (в основном плагинами и темами), вы должны обновить свой промежуточный сайт с копией фактического. Таким образом, если проблема возникнет на вашем живом веб-сайте, вы сможете скопировать ее в своей промежуточной среде.

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

Но если ваш хостинг-провайдер не предлагает вам такую ​​возможность, вы можете создать промежуточный сайт с помощью плагина WP Staging. Этот плагин позволяет легко клонировать ваш сайт, а затем использовать клон, как если бы он был реальным. Вы всегда будете знать, когда находитесь в рабочей среде, потому что оранжевая полоса в верхней части экрана скажет вам об этом.

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

4. Query Monitor

Его название может вводить в заблуждение, потому что Query Monitor делает гораздо больше, чем просто отслеживает запросы. Это полная панель разработчика для WordPress, позволяющая отлаживать скрипты, таблицы стилей, вызовы API, запросы к базе данных, ошибки PHP и многое другое. Некоторые расширенные функции позволяют отлаживать вызовы Ajax и проверять возможности пользователей.

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

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

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

5. Инструменты разработчика Firefox

Ранее известный как Firebug, Инструменты разработчика Firefox — это специальная версия Firefox, созданная специально для разработчиков и предлагающая новейшие функции и инструменты для разработки. Он не является специфичным для WordPress, но оказывается очень полезным для отладки сайтов.

Инструменты разработчика Firefox неизбежно сравниваются с более популярными Chrome DevTools. При этом солидная компоновка Firefox выделяется. Например, вы можете щелкнуть правой кнопкой мыши любой элемент, чтобы открыть вкладку «Инспектор», и веб-консоль предлагает расширенный вывод при печати объектов, показывая гораздо больше информации, чем просто его имя.

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

С помощью инструмента «Инспектор» вы можете просматривать и изменять страницы HTML и CSS, что позволяет делать это со страницами, загруженными локально в Firefox или на удаленном устройстве, например Firefox для Android.

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

6. New Relic

Являясь одним из крупнейших игроков в отрасли APM (Application Performance Monitoring), New Relic является коммерческим продуктом, который ежедневно используют тысячи разработчиков во всем мире, чтобы получить представление о производительности своих программных продуктов. Он имеет плагиновую архитектуру, которая обеспечивает добавленную функциональность третьими сторонами, что приводит к практически бесконечному спектру технологий, которые можно отслеживать с помощью этого инструмента.

При цене от 9,37$ до 200$ за хост в месяц он предназначен для профессиональной отладки. Он также несет в себе расширенную кривую обучения, поэтому помимо затрат денег на решение, вам также нужно потратить время, чтобы научиться его использовать. Пользователи New Relic ценят тот факт, что он легко интегрируется в приложения для APM и мониторинга инфраструктуры.

7. Debug Bar

Debug Bar представляет собой набор плагинов, доступных через меню отладки на панели администратора WordPress, которое отображает широкий спектр отладочной информации. Его параметры включают консоль, шорткоды, константы, типы записей, cron, действия и фильтры, переходные процессы, удаленные запросы, а также сценарии списков и зависимости стилей. Это плагин с открытым исходным кодом, поэтому его можно использовать бесплатно.

Основной плагин, Debug Bar, предоставляет базовую функциональность, расширенную остальными плагинами. Он работает со встроенными в WordPress флагами отладки, такими как WP_DEBUG и SAVEQUERIES. Когда эти флаги активны, панель отладки добавляет полезную информацию об отладке, такую ​​как предупреждения PHP и запросы MySQL, избавляя вас от необходимости искать и читать файлы журнала.

Каждый параметр в меню панели отладки предоставляет свою долю мощности отладки. В консоли, например вы можете запускать произвольный PHP-код, который отлично подходит для тестирования содержимого переменных (среди прочего).

Cron отображает информацию о запланированных событиях WordPress, такую ​​как время следующего события, количество запланированных событий, список пользовательских запланированных событий и т. Д. Действия и фильтры — еще одна опция для отображения хуков, прикрепленных к текущему запросу. На вкладке «Действия» отображаются действия, связанные с текущим запросом, а на вкладке «Фильтры» отображаются все теги фильтров, а также функции, прикрепленные к каждому из них.

Заключение

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

Также рекомендуем прочитать:

1. 10 способов SEO оптимизации WordPress и производительности контента
2. 7 способов, как увеличить скорость загрузки вашего сайта
3. Что такое черный список URL-адресов и как от него защититься?
4. Увеличить производительность WordPress с помощью этих плагинов

Небезопасные данные могут прийти из разных источников: пользователи, другие сайты, ваша база данных и т.д. Такие данные должны проверяться/очищаться (проходить валидацию) при получении или при выводе на экран. Например очистка нужна при создании SQL запроса. Новички часто недооценивают эту «не обязательную» процедуру — ведь все же и так работает.

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

Многие функции очистки вводимых данных подходят и для очистки принимаемых данных.

Функции валидации (по типам передаваемых данных)

Числа

(int) $int

intval( $int )

Превращает $int в целое число. Это функции PHP.

(float) $int

floatval( $int )

Превращает $int дробное число (число с плавающей точкой). Это функция PHP.

absint( $int )

Превращает $int в целое положительное число. Т.е. если передать -5 вернет 5.

Массивы

array_map( ‘absint’, $array )

Превращает все значения $array в неотрицательные числа. array_map() — это PHP функция.

‘absint’ — это функция absint(), которая применяется к значением массива $array. Замените ‘absint’ на любое другое название функции и все значения массива будут обработаны этой функцией.

map_deep( $value, $callback ) (с версии 4.4)

Применяет указанную функцию к значениям переданного массива или свойствам объекта. Рекурсивная функция.

Строки (вывод на экран)

esc_html( $text )

Заменяет спецсимволы на HTML сущности в переданном тексте, возвращает отформатированный текст. Заменяются следующие символы: ", ', &, <, >.

esc_attr( $text )

Преобразует знаки " ' < > & в html сущности. Не создает двойного преобразования.

esc_textarea( $text )

Очищает текст/строку для использования в html теге textarea.

esc_url( $url, $protocols, $_context )

Очищает УРЛ для использования его в тексте, изменяет неправильные и удаляет опасные символы.

esc_sql( $data )

Подготавливает строку к использованию в SQL запросе. Защищает от SQL инъекций. Может принимать массив строк для обработки.

esc_js( $text )

Подготавливает строку для использования в JavaScript. Чтобы уберечь от ошибок: экранирует кавычки, меняет символы " <> & на спецсимволы HTML и поправляет окончание строки.

esc_html__( $text, $domain )

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

esc_html_e( $text, $domain )

Переводит (локализует) строку и очищает её для вывода на экран — заменяет в ней спецсимволы на HTML сущности.

esc_attr__( $text, $domain )

Переводит указанную строку и обрабатывает её функцией esc_attr().

esc_attr_e( $text, $domain )

Выводит переведенный текст очищенный функцией esc_attr().

Строки (принимаемые данные)

WordPress функции для очистки

В WordPress есть ряд функций с помощью которых можно очистить строки которые приходят в виде данных. Почти все такие функции начинаются с префикса sanitize_:

sanitize_key( $key )

Очищает строку, чтобы использовать её как ключ. Ключи используются как разные внутренние ID. Оставит только: a-z0-9_-.

sanitize_text_field( $text )

Очищает строку передаваемую из поля input (обычно при сохранении в базу данных) или при получении из БД. Удаляет почти все оставляя только текст: без HTML тегов, переносов строк и т.д.

sanitize_textarea_field( $text )

Очищает строку передаваемую из поля textarea (при сохранении в базу данных) или при получении из БД. Удаляет все HTML символы, табуляции, HTML сущности и т.д. Оставляет чистый текст. С версии WP 4.7.

sanitize_html_class( $text )

Подготавливает текст для использования его в html атрибуте class: удаляет все неподходящие символы.

sanitize_title( $title )

Используется для создания ярлыков (slug) записей/рубрик.

sanitize_title_with_dashes( $title )

Очищает заголовок, заменяя пробелы на (-).

sanitize_user( $username, $strict )

Очищает имя пользователя (логин, username), удаляя небезопасные символы.
$strict = true — значит в именах будут доступны только: [a-zA-Z0-9 _*.-].

sanitize_file_name( $filename )

Очищает название файла, заменяя пробелы на ‘_’ и удаляя недопустимые символы.

sanitize_mime_type( $mime_type )

Очищает строку для использования её как MIME тип. Удаляет все кроме -+*.a-zA-Z0-9/.

sanitize_term_field( $field, $value, $term_id, $taxonomy, $context )

Очищает значение термина (рубрики) для использования в тексте.

sanitize_post_field( $field, $value, $post_id, $context )

Очищает указанное значение указанного поля поста.

sanitize_option( $option, $value )

Очищает значения различных опций, в зависимости от типа опции.

PHP функции для проверки

ctype_alnum( $text )

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

ctype_alnum( 'AbCd1zyZ9' ); // true
ctype_alnum( 'foo!#$bar' ); // false
ctype_alnum( 'foo bar' );   // false

strlen( $string )

mb_strlen( $string )

Для проверки того, что строка имеет ожидаемое количество символов.

preg_match( $pattern, $subject, $match )

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

// проверка по символам: могут быть только 0-9.-
if ( preg_match( '/[^0-9.-]/', $data ) ) {
	wp_die( 'Неверный формат' );
}

strpos( $haystack, $needle )

Для проверки на предмет наличия подстроки в другой строке.

$mystring = 'abc';
$findme   = 'a';
if( false !== strpos( $mystring, $findme ) ){
	echo 'a найдена в abc';
}

Строки (HTML)

wp_kses( $string, $allowed_html )

Чистит строку, оставляя в ней только указанные/допустимые HTML теги, их атрибуты и значения атрибутов. Следует использовать при выводе текста где могут быть небезопасные HTML теги.

Для удобного использования, у wp_kses() есть обертки. Например, чтобы не передавать массив допустимых тегов, а использовать базовый с минимальным набором допустимых html тегов, можно использовать:

wp_kses_post( $text ) — удалить недопустимые для записи теги, учитывая права текущего пользователя.

wp_filter_post_kses( $text ) — тоже что wp_kses_post(), только ожидает экранированные данные.

wp_kses_data( $text ) — если нужно ограничить допустимые теги до минимума, как это делается в комментариях. Ожидает не экранированный текст.

wp_filter_kses( $text ) — тоже что и wp_kses_data(), только ожидает экранированную строку.

wp_filter_nohtml_kses( $text ) — удаляет все HTML теги из переданного текста. Ожидает экранированную строку. Возвращает очищенный текст.

Фильтры wp_kses() медленные и съедают много ресурсов, поэтому не стоит использовать их каждый раз при выводе данных, лучше очищать ими входящие данные, например перед записью текста в базу данных. Такая очистка например запускается WordPress при добавлении комментария или записи.

wp_rel_nofollow( $html )

Добавляет rel="nofollow" ко всем элементам <a> в переданном HTML тексте.

wp_kses_allowed_html( $context )

Возвращает массив допустимых HTML элементов для указанного контекста. См. описание…

balanceTags( $html )

force_balance_tags( $html )

Закрывает незакрытые HTML теги, чтобы вывод не вызвал ошибку.
balanceTags() срабатывает только если включена спец настройка в настройках сайта «WordPress должен исправлять некорректный XHTML-код автоматически.». А вот force_balance_tags() срабатывает всегда!

tag_escape( $tag_name )

Очищает название HTML тега. Удаляет все символы кроме a-zA-Z0-9_:. Переводит строку в нижний регистр.

sanitize_html_class( $class, $fallback )

Подготавливает текст для использования его в html атрибуте class: удаляет все неподходящие символы. Удаляет всё кроме A-Za-z0-9_-. Если результат пустой, то в $fallback можно установить значение по умолчанию.

wp_strip_all_tags( $string, $remove_breaks )

Удаляет все HTML теги из строки. script и style удаляются вместе с содержимым.

Разница со strip_tags() — теги <script> и <style> удаляются вместе с содержимым. Например:

strip_tags( '<script>something</script>' );        // something
wp_strip_all_tags( '<script>something</script>' ); // пусто ''

strip_tags()

Удаляет все HTML теги из строки.

Email

is_email( $email )

Проверяет, является ли переданная строка e-mail адресом. Вернет true или false.

sanitize_email( $email )

Очищает e-mail: убирает недопустимые символы из e-mail адреса.

URL (ссылки)

esc_url( $url )

Очищает УРЛ для использования его в тексте, изменяет неправильные и удаляет опасные символы. Не пропускает URL, если в нем указан протокол не из белого списка (http, https, ftp, ftps, mailto, news, irc, gopher, nntp, feed, и telnet).

Используйте эту очистку при выводе любого URL на экран (в тексте, в атрибутах или где-либо еще).

Также, эта функция кодирует некоторые спец. символы, поэтому её рекомендуется использовать при генерации строк для (X)HTML или XML документов. Кодирует амперсанд (&) и одинарные кавычки в их числовые сущности (&#038, &#039).

sanitize_url( $url )

esc_url_raw( $url )

Очищает УРЛ для безопасного использования. В отличии от esc_url(), не очищает для безопасного вывода на экран. Используйте, когда нужно получить НЕкодированный URL, например: в запросах к БД, при редиректах, в HTTP запросах.

sanitize_url() — это алиас esc_url_raw().

urlencode( $url )

PHP функция, которая кодирует URL, так что его можно использовать как параметр запроса. Т.е. заменяет все возможные символы URL (&, /, пробел и т.д.) на их сущности. Чтобы вернуть такой URL в прежнее состояние, используйте urldecode().

Эта функцию используется не для вывода URL на экран, а для использования URL где-то в запросе, чтобы PHP не мог интерпретировать строку как URL. К примеру, если обработать http://example.com/one, то получим http%3A%2F%2Fexample.com%2Fone — это уже не URL, а строка с набором символов…

urlencode_deep( $array )

Обрабатывает все элементы переданного массива функцией urlencode().

XML

XML документы, в отличии от HTML, понимают лишь некоторые спецсимволы: ', &, >, <, ". Поэтому для вывода текста для XML документов, в WordPress есть функция:

ent2ncr( $text )

Конвертирует строковые сущности в их числовые значения: ’ станет ’.

JavaScript

esc_js( $text )

Подготавливает строку для использования в JavaScript. Полезна при использовании однострочного JS кода (в HTML атрибутах, например onclick='…'). Строка должна быть заключена в одинарные кавычки.

Или вот такой пример:

<script>
	var = '<?php echo esc_js( $js ); ?>';
</script>

Файловая система

validate_file( $filename, $allowed_files )

Используется для защиты от атаки «выход за пределы каталога» (directory traversal attacks). Или, когда нужно проверить находится ли файл в белом списке (параметр $allowed_files).

Возвращает: 0 — если проверка пройдена. И вернет число ошибки (> 0), если есть ошибка. Это нестандартный подход, поэтому будьте внимательны при написании кода!

Для проверки функции нужно передавать только абсолютные пути без ../ или ./. Например /etc/hosts пройдет проверку, а ./hosts — не пройдет.

Атака выхода за директорию выглядит примерно так, отправляется такой запрос: http://test.ru/?dir=../../Windows/system.ini и если сервер или код не защищен, то можно получить содержимое файла system.ini.
Такие атаки не частые судя по информации из google и относятся к средней степени риска. Но игнорировать их все же не стоит…

Атаки с разделением ответов HTTP (header splitting attacks) создаются на стороне клиента, а не сервера и поэтому их очень трудно выловить. WordPress иногда добавляет данные отправляемые пользователем в HTTP заголовок, но чтобы избежать такие атаки, передаваемые заголовки проверяются в белом списке и все опасное вырезается.

Для очистки потенциально опасных заголовков в WordPress предусмотрены 2 функции редиректа:

wp_redirect( $location, $status = 302 )

Безопасный способ перенаправить пользователя на любой URL. Функция проверяет чтобы итоговый HTTP запрос не содержал опасных данных.

wp_safe_redirect( $location, $status = 302 )

Еще более надежный способ редиректа, при котором перенаправление возможно только на разрешенные в белом списке хосты.

wp_sanitize_redirect( $location )

Очищает указанный URL для использования при перенаправлениях.

База данных

$wpdb->prepare( $format, $value1, $value2, … )

Очищает запрос: безопасно заменяет заполнители (placeholder) в $format указанными в $value1, $value2, … значениями.
$format — это строка на подобие sprintf(), в которой можно указать только следующие заполнители: %s, %d и %f. Нет необходимости в кавычках для строк (%s). prepare() добавит кавычки сам, т.е. foo=%s станет foo='значение'. Но если кавычки есть, ничего страшного, функция понимает такую конструкцию.

Работает на основе wpdb::_real_escape( $string ) с предварительной обработкой форматирования.

$wpdb->get_var( $wpdb->prepare(
  "SELECT something FROM table WHERE foo = %s and status = %d",
  $_GET['name'],  // 'не ' безопасные строка' (функция сделает очистку сама)
  $_GET['status'] // 'не безопасное число (функция сделает очистку сама)
) );

esc_sql( $sql )

Экранирует строку или массив строк для использования в SQL запросе. Опирается на функцию addslashes().
$wpdb->prepare() предпочтительнее, потому что исправляет некоторые ошибки форматирования (кавычки).
Работает на основе wpdb::_real_escape( $string ).

$wpdb->escape_by_ref( &$text )

Не возвращает данные, т.к. они передаются по ссылке. Данные очищаются «на лету».
Работает на основе wpdb::_real_escape( $string )

$wpdb->esc_like( $text )

Подготавливает строку для использования в LIKE части SQL запроса. Обработанная строка должна быть еще обработана одной из функций очистки!

$link = $wpdb->esc_like( $link ); // подготовим строку для LIKE аргумента
$link = esc_sql( $link );         // очистим переменную
$link = '%' . $link . '%';        // создадим полную переменную поиска LIKE
// $link готова для использования в SQL запросе.

sanitize_sql_orderby( $orderby )

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

sanitize_title_for_query( $title )

Подготавливает строку для использования её в качестве ярлыка (slug) в SQL запросе. Очистка от инъекций делается отдельно. Подразумевается что это название чего-либо: заголовка, имени файла и т.д.

Функции не связанные с типом данных

Остальные функции очистки, которые не вошли в предыдущие списки, потому что подходят для разных типов данных.

isset( $var )

Проверяет существует ли переменная.

empty( $var )

Проверяет не пустая ли переменная. Игнорирует ошибки, если переменной не существует.

in_array( $needle, $haystack, true )

Для проверки, есть ли указанный элемент в указанном массиве.

count( $array )

Для проверки количества элементов в массиве.

sanitize_meta( $meta_key, $meta_value, $meta_type )

Очищает значение мата данных. Сама функция ничего не делает, а примеряет фильтр "sanitize_{$meta_type}_meta_{$meta_key}", через который разные мета данные можно очистить по-разному.

Примечательно то, что эта функция используется во всех функциях при добавлении/обновлении метаданных WordPress: update_*_meta() или add_*_meta(). Т.е. использовать её напрямую обычно нет смысла, но вот использовать хук который она обрабатывает очень удобно при обновлении любых метаданных…

sanitize_term( $term, $taxonomy, $context )

Очищает все поля элемента таксономии с помощью функции sanitize_term_field().

Функция filter_var()

filter_var() — это очень интересная для проверки и очистки данных функция.

Проверяет или очищает значение указанной переменной по указанным параметрам.

Возвращает

Отфильтрованные данные или FALSE, в случае неудачной проверки, фильтрации.

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

$var = filter_var( $var, $filter, $options );

$var(разное) (обязательный)

Переменная, которую нужно очистить, проверить.

$filter(число)

ID фильтра который будет использоваться для проверки, очистки. Такие ID хранятся в виде чисел в предопределенных константах PHP. Их полный список можно посмотреть тут:

• константы для очистки (sanitize)
• константы для проверки (validate).

По умолчанию указана константа FILTER_DEFAULT, значит что никакой фильтр не применяется.
По умолчанию: FILTER_DEFAULT

$options(массив/константа)

Различные параметры или флаги фильтрации. Константой или комбинацией констант через | (ИЛИ). Или может быть массивом, который поддерживает всего 2 ключа: array('options'=>..., 'flags'=>... ).

Все возможные флаги смотрите здесь: флаги, используемые a filter_var.

Пример опций фильтрации, с указанием констант:

// вернуть null при неудачной проверке
filter_var('example.com', FILTER_VALIDATE_URL, FILTER_NULL_ON_FAILURE ); //> null

// или флаги можно указать в элементе массива flags
filter_var('example.com', FILTER_VALIDATE_URL, array('flags'=>FILTER_NULL_ON_FAILURE) ); //> null

Пример опций фильтрации, с указанием массива:

// массив параметров фильтрации
$options = array(
	'options' => array(
		'default' => 'http://example.com/info', // вернется при неудачной проверке
	),
	'flags' => FILTER_FLAG_PATH_REQUIRED, // флаг: Включает содержание пути в URL в качестве необходимого условия.
);
$var = filter_var('http://example.com', FILTER_VALIDATE_URL, $options );

echo $var; //> http://example.com/info
// т.е. вернулось указанное значение по умолчанию,
// потому что флаг говорит, что у URL должен быть путь

По умолчанию: null

Примеры filter_var()

#1 Демонстрация работы

// email
$email = filter_var('bob@example.com', FILTER_VALIDATE_EMAIL); //> bob@example.com
$email = filter_var('bob@example', FILTER_VALIDATE_EMAIL); //> false

// url
$url = filter_var('http://example.com', FILTER_VALIDATE_URL); //> http://example.com
$url = filter_var('example.com', FILTER_VALIDATE_URL); //> false

$url = filter_var('http://example.com/path', FILTER_VALIDATE_URL, FILTER_FLAG_PATH_REQUIRED); //> http://example.com/path
$url = filter_var('http://example.com', FILTER_VALIDATE_URL, FILTER_FLAG_PATH_REQUIRED); //> false

#2 Проверим является ли строка IP адресом

if( filter_var( 'foo', FILTER_VALIDATE_IP ) )
	echo 'это IP';
else
	echo 'это не IP';

// выведет: 'это не IP'

if( filter_var( '123.111.222.123', FILTER_VALIDATE_IP ) )
	echo 'это IP';
else
	echo 'это не IP';

// выведет: 'это IP'

// по-другому можно записать так
filter_var( 'foo', FILTER_VALIDATE_IP ); //> false
filter_var( '123.111.222.123', FILTER_VALIDATE_IP ); //> true

Ваши функции валидации данных

Можно написать свои собственные PHP функции и включить их в тему или плагин.

При написании функции проверки, рекомендуется назвать функции вопросительно, например: is_phone(), is_available(), is_us_zipcode().

В конце функции всегда возвращайте только true или false!

Пример 1

Пример функции PHP, которая проверяет, является ли значение действующим в США индексом (за пределами США, это называется почтовый код).

function is_us_zipcode( $zipcode ) {

	if ( empty( $zipcode ) ) {
		return false;
	}

	// a zip code should never have more than 10 characters
	if ( 10 <= strlen( trim( $content ) ) ) {

		// use a regex to check whether this zip code is correct
		if ( preg_match( '/^d{5}(-?d{4})?$/', $content ) ) {
			return true;
		}

	} else {
		return false;
	}
}

Теперь при получении данных поле можно проверить так:

if( isset($_POST['wporg_zip_code']) && is_us_zip_code($_POST['wporg_zip_code']) ){
	// поле проверено, делаем что-либо
}

Пример 2

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

Этот пример проверяет входящее поле сортировки, указанное в input поле orderby. Вариантов возможных полей сортировки и их можно перечислить — это будет наш белый список для проверки. Проверять этот список будем с помощью php функции in_array().

<?php
$allowed_keys = ['author', 'post_author', 'date', 'post_date'];

// белый список в нижнем регистре (author),
// поэтому изменим данные, если они указанны в верхнем регистре (AUTHOR)
$orderby = strtolower( $_POST['orderby'] );

if( in_array( $orderby, $allowed_keys, true ) ){
	// проверка пройдена изменяем запрос
}

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

В третьем параметре in_array() мы указали true — это означает что тип данных тоже должен совпадать — должна быть строка. Например, если указать в $_POST['orderby'] = true, а подделать запрос так можно, и не указать проверку по типу, то проверка будет пройдена всегда и мы получим доступ к коду внутри проверки:

// пример плохой проверки
if( in_array( true, [ 'date', 'author' ] ) ){
	// этот код будет срабатывать всегда!
}

—

Информация этого руководства взята из официального источника и личного опыта.

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

[toc]

Деактивируйте плагины

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

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

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

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

Временно измените вашу тему

Многие современные темы имеют внутри себя плагины и другие кодовые элементы.

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

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

Чтоб узнать стала ли ваша тема причиной возникновения проблемы, временно переключитесь на WordPress-тему по умолчанию, типа  Twenty Seventeen, и посмотрите, ушла ли ошибка. Если проблема в теме, то обратитесь к разработчику или просто воспользуйтесь другой темой.

Проверьте ваш файл .htaccess

Файл  .htaccess содержит инструкции для сервера. Иногда он может повредится, что вызывает появление сообщений типа “500 Internal Server Error”.

Если вы предполагаете, что ваш файл .htaccess стал причиной возникновения проблем, получите доступ к сайту по FTP и найдите .htaccess в корне вашей директории WordPress. Иногда этот файл скрыт, и вам придется выбрать “show hidden files” (показать скрытые файлы) в вашем FTP-клиенте, чтоб найти его.

Найдя этот файл, переименуйте его во что-то типа “.htaccess-old”, что остановит его использование и перезагрузит сайт

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

Если ваша версия  WordPress устарела, то в случае возникновении проблем, нужно обязательно обновиться. То же самое касается тем и плагинов.

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

Иногда это позволяет решить проблему, если ядровые файлы были повреждены. Вы можете сделать это вручную, скачав последнюю версию WordPress и заменив ее файлами содержимое ваших  папок wp-admin и wp-includes по  FTP. Это не должно затронуть прочее содержимое вашего сайта.

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

Включение режима  Debug

По умолчанию большинство ошибок и предупреждений подавляются самим WordPress, но вы можете отредактировать ваш файл  wp-config.php, изменив в данной строке false на true:

define('WP_DEBUG', false);

Это действие включит режим debug и выведет все ошибки и предупреждения на экран, что возможно наведет вас на правильные мысли, благодаря поиску Google

Увеличьте  лимит PHP памяти

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

Вы можете найти эти настройка в вашем wp-config.php.  Получите доступ к файлу по FTP и добавьте в него следующий код:

define('WP_MEMORY_LIMIT', '64M');

Сохраните файл и перезагрузитесь. Если проблема не решилась, то опять увеличьте лимит до ‘128M’ или ‘256M’.

Пообщайтесь с вашим хостером

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

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

Восстановление из бэкапа

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

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

Кастомные изменения темы испарились или возник сбой в обновленной теме

Если вы вручную редактируете  WordPress-тему, то эти изменения уйдут в случае обновления темы. Дабы правильно отредактировать тему, нужно создать дочернюю тему, которая будет содержать все кастомизации.

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

WordPress-белый экран смерти

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

Вот что мы рекомендуем сделать, чтоб решить проблему:

1. Увеличьте  лимит памяти
2. Отключить плагины
3. Переключитесь  на тему по умолчанию
4. Включите режим debug

Если это не помогло, переустановите WordPress или восстановите его из бэкапа

Не могу попасть в админку  WordPress

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

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

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

Визуальный редактор WordPress не загружается нормально

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

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

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

Также проблема может быть связана с JavaScript,  которые работают неправильно. Чтоб исправить это добавьте следующий текст в ваш файл  wp-config.php:

define('CONCATENATE_SCRIPTS', false);

Картинки не загружаются нормально или возникают ошибки при загрузке картинок

Если вы заметили, что внезапно все картинки дали сбой, или вы больше не можете загружать картинки, используя медиа-загрузчик, то, вероятно, это случилось из-за некорректного файла или  прав доступа к директории. Чтоб проверить права доступа к  файлам, войдите на сайт, используя FTP,  и откройте директорию wp-content.

Выполните правый клик на папке uploads в этой директории и выберете “file permissions”. Права на эту папку и файлы должны быть 755. Убедитесь в том, что вы выбрали опции “recurse into subdirectories” и “apply to directories only”, чтоб права доступа распространились на все файлы внутри папки.

Опять выполните правый клик на той же папке. Теперь вам нужно будет изменить права управления всеми  файлами на 644. Но на этот раз выберете только опцию “apply to files”. Теперь все должно заработать.

Страница ошибки 404

Если вы пытаетесь получить доступ к какому-либо  файлу на вашем сайте, а он выдает вам ошибку 404, то вероятно это баг, переписывающий  URL,  в файле  .htaccess.

Чтоб исправить проблему идем в Настройки  > Постоянные ссылки и выбираем другую структуру постоянных ссылок для вашего сайта. Сохраняем, после чего  выбираем старую структуру постоянных ссылок и сохраняемся вновь. Файл .htaccess перепишется,  и ошибки 404 уйдут.

Ошибка синтаксиса  WordPress

Если  при загрузке сайта, вы видите только белый экран и сообщение типа этого Parse Error: Syntax error, unexpected ‘<‘ in home/admin/public_html/wp-content/theme/functions.php on line 22, это значит, что вы столкнулись с ошибкой кода. Каждый раз, когда мне попадается такая ошибка, это случалось из-за того, что я самостоятельно правил код, пропуская  какой-то небольшой орфографический знак, но возможно у вас что-то стряслось с плагином или темой.

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

Еще по теме:

Не работает плагин! Что делать?
Ошибки WordPress — 15 самых распространенных проблем

· Время на чтение: 12мин · Автор: · Опубликовано 07.07.2022 · Обновлено 28.12.2022

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

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

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

Для вашего удобства, мы собрали топ-7 лучших плагинов для поиска ошибок WP в одну статью. В неё вошли только полезные инструменты, проверенные временем и другими вебмастерами. А их бесплатность позволяет использовать их без ограничений, даже если у вас много проектов.

Health Check & Troubleshooting

Один из самых популярных плагинов для поиска ошибок в ВордПресс. Он регулярно обновляется и используется на более чем 200 тысячах сайтов. Для русскоязычных вебмастеров инструмент особенно удобен, благодаря наличию перевода на русский. Health Check & Troubleshooting имеет открытый исходный код, поэтому:

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

Плагин для WordPress в автоматическом режиме проверит:

• наличие общеизвестных проблем, часто возникающих на большом количестве сайтов;
• есть ли ошибки в конфигурации;
• целостность файлов WP;
• совместимость с будущими обновлениями PHP;
• функционал электронной почты;
• защищенность соединения;
• работоспособность функции JSON;
• работоспособность запланированных событий (например, отложенных публикаций).

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

Debug This

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

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

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

Query Monitor

Как становится понятно из названия, данный инструмент предназначен для мониторинга и отладки запросов разного рода. Например, к базе данных или редактору блоков. Его используют в более чем 100 тысячах проектов на ВордПресс, что подтверждает его полезность. Query Monitor имеет перевод на русский язык, поэтому подойдет даже не знающим английского языка вебмастерам.

В процессе поиска ошибок плагин проверяет и обнаруживает:

• иерархию шаблонов и их составляющих, показывая, есть ли незагруженные или конфликтующие элементы;
• запросы к базе данных, которые будут выведены отфильтрованными по типу и ответственному компоненту (вы будете четко видеть, какие запросы относятся к конкретному плагину или шаблону);
• проблемы с файлами перевода сайта на разные языки;
• доступ обычных посетителей вашей странички на ВордПресс к тем разделам, которые должны быть для них закрыты;
• ошибки PHP, с указанием ответственных компонентов;
• недочеты в настройках сценариев и стилей, с учетом всех зависимостей и их нарушений;
• значения условных функций ВордПресс, таких как is_single() и подобных;

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

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

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

Black Bar

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

К сожалению, с последними версиями ВордПресс инструмент не тестировался. Его корректная работа гарантируется только если у вас WP до 5.1.4 версии. Поэтому он подойдёт не всем вебмастерам. Если у вас более поздний выпуск WordPress — попробовать плагин можно, но не факт, что он поможет вам обнаружить ошибки.

Функции Black Bar:

• отображение появляющихся в процессе загрузки страниц ошибок PHP;
• проверка глобальных переменных, таких как POST, COOKIE, SESSION, GET, SERVER;
• показывает совершенные запросы MySQL и сколько времени было потрачено на их реализацию;
• отладка плагинов и шаблонов ВордПресс через консоль.

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

BulletProof Security

Данный плагин проводит поиск ошибок в плане безопасности вашего проекта на WordPress. Он высоко оценён вебмастерами и часто обновляется. На форуме поддержки разработчики помогают пользователям решать возникающие проблемы. Приятный бонус — перевод BulletProof Security на русский язык, делающий его использование комфортнее для начинающих. Что делает данный инструмент:

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

BulletProof Security имеет 3 темы оформления, позволяет обслуживать как внешний, так и внутренний интерфейс проекта, и вообще очень дружественен к пользователям. Если для вас важна безопасность, тогда данный плагин для WordPress поможет её улучшить, а также найти ошибки, которые потенциально ей вредят.

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

Media Cleaner

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

• засоряют ваш ВордПресс и не используются;
• повреждены;
• работают неправильно.

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

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

Media Cleaner доступен на русском и английском языках. Он тестировался на разных версиях ВордПресс, в том числе и на последних выпусках. Он совместим с любыми шаблонами, плагинами и записями медиафайлов. Если у вас многофункциональный сайт с большим количеством подключенных дополнительных инструментов, тогда для полноценной очистки может потребоваться Pro-версия, цена которой (на 1 год, для 1 сайта) составляет $24.

WP Safe Mode

Инструмент используется для включения в ВордПресс так называемого «безопасного режима». В нём вы сможете отключать и включать определённые плагины и менять темы, чтобы проверить, как работает сайт в видоизменённом варианте. Это дает возможность разобраться, из-за какого именно дополнения возникла та или иная ошибка.

Установить WP Safe Mode можно через FTP, что особенно выручает в ситуациях, когда доступ к сайту был потерян из-за ошибок PHP. К примеру, при возникновении «белого экрана смерти» или пустых экранов. Иногда это единственный способ восстановить работоспособность проекта WordPress, потому что без активации безопасного режима с отключением дополнений, разобраться с проблемой и причинами её появления как-то по-другому невозможно.

Другие достоинства плагина:

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

WP Safe Mode не доступен на русском языке, поэтому у не знающих английский пользователей ВордПресс могут возникнуть незначительные трудности с его применением.

Подведём итоги

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

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

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

Для более верной работы сайта (магазина, в данном случае), проверяем на наличие ошибок в коде с помощью валидатора https://validator.w3.org/.

Например в статьях на этом сайте есть целых 15 ошибок кода.

Посмотреть их можно здесь.

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

Ошибки же, о которых пойдет речь ниже, касаются магазинов на JoomShopping, которыми я занимаюсь чаще и более основательно, чем сайтом rtr24.ru.

Ошибки валидации JoomShopping

У меня ошибки содержались в модулях “Обратный звонок” и в “Фильтре по магазину”.

1. Ошибка The type attribute for the style element is not needed and should be omitted

<style type="text/css">

Это устаревший код, сегодня достаточно писать

<style>

2. Ошибка The type attribute is unnecessary for JavaScript resources

<script type="text/javascript">

Тоже устарел, Вместо него везде можно смело писать

<script >

3. Ошибка в “Обратном звонке”

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

Тогда в дефолтном шаблоне модуля ищем:

<form action="<?php echo JRoute::_( '', true, $params->get('usesecure')); ?>" method="post" name="feedback_form" class="form_items">

Конкретно нас интересует:

<?php echo JRoute::_( '', true, $params->get('usesecure')); ?>

Вместо этого можно написать:

<?php echo JRoute::_(/lubaja-nascha-staija); ?>

Я пишу:

<?=$_SERVER['PHP_SELF'];?>

Теперь заказав звонок, клиент магазина останется на странице с тем же товаром (вдруг он его еще не рассмотрел?).

4. Ошибки в модуле фильра товаров JoomShopping

В папке:

modulesmod_jshopping_unijax_filtertmpldefault

Открываем файлы:

vendor.php
manufacturer.php
label.php
delivery_time.php
characteristic.php
category.php
availability.php

И с помощью “Найти-Заменить” в Notepad++ во всех файлах сразу меняем:

value=""></option>

на:

value="">&nbsp;</option>

5. The itemprop attribute was specified, but the element is not a property of any item

В файле шаблона Joomla index.php

Ищем:

<html lang="<?php echo $this->language; ?>" dir="<?php echo $this->direction; ?>">

И делаем:

<html lang="<?php echo $this->language; ?>" dir="<?php echo $this->direction; ?>" itemscope itemtype="http://schema.org/WebPage">

На этом месте, магазин который я сейчас разрабатываю, начал показывать 0 ошибок в валидаторе.