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

Зачем нужен валидный код и как устранить ошибки валидации

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

Зачем необходима проверка на валидность сайта

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

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

На что влияет валидность сайта

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

Некорректная веб-страница может быть прочитана браузерами по-разному. Это приведет к тому, что ваши посетители, возможно, даже не смогут правильно увидеть контент страницы в своих браузерах. Валидация в дальнейшем позволит исправить почти все основные различия и делает вашу веб-страницу доступной для чтения почти всеми веб-браузерами (чаще всего исключением становится Internet Explorer старых версий). Отсюда и появился термин “кроссбраузерная верстка” – т. е. верстка, которая одинаково хороша (совместима) для всех популярных браузеров.

А как же это повлияет на SEO? Важно понимать, что роботы поисковых систем любят семантические веб-страницы. Семантическая верстка, согласно данным Википедии, – это подход к созданию веб-страниц на языке HTML, основанный на использовании HTML тегов в соответствии с их семантикой (предназначением). Кроме того, структурная семантическая веб-страница позволяет поисковым роботам более точно определять значимость, как отдельных элементов веб-страницы, так и всего текста в целом. По заверению Google, валидный код никак не влияет на ранжирование страниц. Но при этом наличие ошибок в коде способно негативно повлиять на сканирование микроразметки и адаптированностью под мобильные устройства.

Так что, если в SEO-аудите вы встретите рекомендации по устранению ошибок, выявленных в процессе валидации, то лучше их исправить, а как это сделать мы вам расскажем.

Инструменты проверки для вашего сайта

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

Существует множество бесплатных сервисов для проверки сайта, такие как Markup Validation Service W3C, Web Page Analyzer, Browsershots и другие.

Служба проверки HTML разметки W3C, вероятно, является самым простым и популярным инструментом для проверки валидности веб-страницы. Используя этот инструмент, вы можете обнаружить ошибки валидации, начиная от отсутствующих атрибутов ALT для ваших IMG-тегов и заканчивая размещением элементов блок-уровня внутри встроенных элементов (например, <p> внутри <span>).

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

Сервис проверит указанные вами данные на ошибки и сформирует отчет с их перечнем и рекомендациями по исправлению.

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

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

Откуда берутся ошибки

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

Как исправить ошибки, и улучшить валидность сайта

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

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

1. Warning: The type attribute is unnecessary for JavaScript resources.

Предупреждение. Атрибут “type” элемента <script> не является обязательным для JavaScript ресурсов.

Warning: The type attribute for the style element is not needed and should be omitted.

Предупреждение. Атрибут “type” для элемента <style> не нужен и его следует опустить.

Для устранения данных двух предупреждений необходимо удалить атрибут type=”text/javascript” во всех тегах <script>, а также type=”text/css” во всех тегах <style>. В помощь нам приходит простая функция PHP preg_replace в паре с чудесной возможностью фильтрации данных в WordPress. Код выглядит так:

Вставить данный код необходимо в файл functions. php используемой темы. Для этого авторизуемся в административной панели WordPress, выбираем пункт меню “Внешний вид” -> “Редактор” и справа в списке файлов выбираем интересующий нас файл. Код вставляем в самом конце файла. Нажимаем кнопку “Обновить файл”.

Дополнительно удалим данный атрибут в некоторых файлах вашей WordPress-темы.

В меню “Внешний вид” -> “Редактор” выбираем интересующие нас файлы – index. php, header. php, footer. php. Поиск атрибута будем осуществлять с помощью горячих кнопок поиска Ctrl+F, введя в поисковой панели text/javascript. Выявив такую запись заменяем <script type=”text/javascript”> на <script>, т. е. удаляем непонравившийся атрибут type=”text/javascript” и не забываем нажать кнопку “Обновить файл”.

1. Error: The center element is obsolete. Use CSS instead.

Ошибка. Тег <center> устарел. Используйте соответствующие CSS стили.

HTML 5 активно взаимодействует с CSS (язык описания внешнего вида документа, написанного с использованием HTML), поэтому запрет на многие теги и атрибуты, начатый в HTML 4 в пользу стилей, только усилился. Такого рода теги и атрибуты уже не поддерживаются некоторыми браузерами и должны исключаться из кода. Одним из таких тегов является тег <center>, а также атрибут “frameborder” тега <iframe>. При решении данных ошибок нам необходимо будет немного “поколдовать” над нашей Базой данных сайта.

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

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

Рассмотрим более подробно выше представленные SQL запросы.

Первой строчкой заменяем устаревший тег на контейнер <div> и сразу же задаем класс “ag_center”. Данный стилевой класс позволит нам выровнять содержимое контейнера по центру. Для этого заходим в админ панель WordPress, выбираем пункт меню “Внешний вид” -> “Редактор” -> файл style. css нашей темы. В конец файла добавляем следующие строки кода:

Второй строчкой SQL запроса заменяем закрывающийся тег </center> на закрывающийся </div>. А третьей – производим замену атрибут frameborder=”0” на класс “ag_border_zero” элемента <iframe>.

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

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

1. Error: The width attribute on the th element is obsolete. Use CSS instead.

Ошибка. Атрибут “width” элемента <th> устарел. Используйте соответствующие CSS стили.

Аналогично предыдущей ошибке, атрибут “width” элемента <th> также является устаревшим. Исправить данную ошибку можно двумя способами — заменить width=”10%” на style=”width:10%;”. Либо, чтобы не описывать каждый раз стиль внутри тега, можно выделить стиль во внешнюю таблицу стилей. Т. е. в элемент <th> добавляем а в файл style. css нашей темы. width_ten_percent . Какой способ проще, выбирать вам!

В случае если данная ошибка несет массовый характер в статьях вашего проекта, воспользуемся поиском и заменой атрибута “width” в панели phpMyAdmin следующим SQL запросом:

После чего необходимо добавить стилевой класс width_ten_percent в файле style. css:
.width_ten_percent

Следует отметить, что при массовой замене устаревших атрибутов на стилевые классы в панеле phpMyAdmin, при наличии уже прописанного класса у элемента (например, <img />), может возникнуть другая ошибка – дублирование атрибута “class”. Подобная ситуация обстоит и с атрибутом “style” (например, <img style=”width: 300px” style=”height: 200px”>). Поэтому, нужно быть уверенным в отсутствии ранее указанного другого атрибута “class” / “style”, либо отказаться от редактирования БД SQL запросами в пользу ручной проверки и редактирования каждой отдельной статьи в редакторе админ панели WordPress.
Для примера, рассмотрим добавление дополнительного класса / свойства атрибута “style”, придерживаясь стилевых правил. Добавим дополнительный класс width_ten_percent к уже имеющемуся color_red (class=”color_red”), и получаем: width_ten_percent” (перечисляем имена классов через пробел). Добавим ширину в 10% к уже имеющемуся style=”color: red;”, в итоге у нас должно получиться так: style=”color: red; width: 10%;” (стилевые свойства разделяются между собой точкой с запятой и пробелом).

Также хотелось бы отметить частое ошибочное использование атрибута “width” для элемента <tr>, атрибута “height” для элемента <td>.

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

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

Устаревшие атрибуты	Элемент
charset, coords, shape, methods, name, rev, urn	<a>
nohref	<area>
alink, bgcolor, link, marginbottom, marginheight, marginleft, marginright, margintop, marginwidth, text, vlink	<body>
clear	<br>
name	<embed>
profile	<head>
version	<html>
longdesc	<iframe>
longdesc, lowsrc, name	<img>
usemap	<input>
charset, methods, rev, target, urn	<link>
scheme	<meta>
name	<option>
archive, classid, code, codebase, codetype, declare, standby	<object>
type, valuetype	<param>
event, for, language	<script>
datapagesize	<table>
abbr, axis	<td> и <th>

1. Error: Bad value 300px for attribute width on element img: Expected a digit but saw px instead.

Ошибка. Неприемлемое значение “300px” для ширины атрибута в элементе <img>: Ожидалась цифра, но вместо этого прочитал “px”.

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

В контексте <img width=”300px” /> атрибутом “width” допускается принимать любое целое положительное число. Необходимо установить допустимое значение для правильной разметки, а именно 285, без указания единицы измерения (px).

Выявленные ошибки могут находиться не только в записях, настройках WordPress темы, но и в содержимом HTML кода виджетов сайдбара. В таких случаях для устранения ошибки заходим в меню “Внешний вид” -> “Виджеты” -> Сайдбар слева (справа/подвал) и в настройках виджета находим ошибочно указанный атрибут “width” удалив единицу измерения (px).

Дополнительно встречается ошибочное указание параметра атрибута “height” элемента <img>.

Использование имени стилевого идентификатора (id=“имя”) более одного раза на одной странице.

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

1. Имя класса и идентификатора должны обязательно начинаться с латинского символа (A–Z, a–z).

Имя класса и идентификатор должен обязательно начинаться с латинского символа (A–Z, a–z). Может содержать цифры (0–9), символ дефиса (-) и подчеркивания (_), но не в начале слова. Использование русских букв в именах идентификатора недопустимо.

1. Ошибочное использование тега noindex по синтаксису.

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

<noindex>Текст или код, который нужно исключить из индексации</noindex>

Для того, чтобы сделать код с noindex валидным, рекомендуется использовать следующую конструкцию:

1. Error: No p element in scope but a p end tag seen.

Отсутствует открывающий или закрывающий тег.

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

1. Error: Element p not allowed as child of element span in this context. (Suppressing further errors from this subtree.)

Блочные элементы внутри строчных.

Согласно спецификации блочный элемент запрещено вставлять внутрь строчного. Например, <span><p>Lorem ipsum…</p></span> не пройдёт валидацию, правильно вложить теги наоборот — <p><span>Lorem ipsum…</span></p>.

Наиболее часто используемыми блочными элементами являются:

Встроенные (строчные) элементы:

1. Error: An img element must have an alt attribute, except under certain conditions. For details, consult guidance on providing text alternatives for images.

Отсутствует атрибут “alt” у изображения.

Каждое изображение (даже если оно служит для дизайнерских целей) в документе HTML должно иметь атрибут “alt” с описанием содержания картинки. Данный атрибут индексируется поисковыми роботами и используется ими для определения содержимого обнаруженных картинок. А это, в свою очередь, важно как для улучшения релевантности веб-страниц, так и для привлечения на сайт дополнительного трафика из «поиска по картинкам».

Памятка для контент-менеджеров

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

Завершение

Результатом кропотливой работы над ошибками мы должны увидеть следующее: Проверка документа завершена. Каких-либо ошибок и предупреждений не выявлено (“Document checking completed. No errors or warnings to show.”).

Что вы думаете о важности валидации? С какими ошибками сталкивались Вы и как их решали? Добавьте к этой статье свои комментарии!

PHP для начинающих. Обработка ошибок

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

Чтобы ни одна ошибка не ушла незамеченной потребуется включить отслеживание всех ошибок с помощью функции error_reporting(), а с помощью директивы display_errors включить их отображение:

Фатальные ошибки

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

E_PARSE

Это ошибка появляется, когда вы допускаете грубую ошибку синтаксиса и интерпретатор PHP не понимает, что вы от него хотите, например если не закрыли фигурную или круглую скобочку:

Или написали на непонятном языке:

Лишние скобочки тоже встречаются, и не так важно круглые либо фигурные:

Отмечу один важный момент — код файла, в котором вы допустили parse error не будет выполнен, следовательно, если вы попытаетесь включить отображение ошибок в том же файле, где возникла ошибка парсера то это не сработает:

E_ERROR

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

Не был найден подключаемый файл:

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

При попытке вызвать несуществующий метод класса:

Отсутствия свободной памяти (больше, чем прописано в директиве memory_limit) или ещё чего-нить подобного:

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

Не фатальные

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

E_WARNING

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

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

Их очень много, и перечислять все не имеет смысла…

E_NOTICE

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

Когда обращаются к неопределенной переменной:

Когда обращаются к несуществующему элементу массива:

Когда обращаются к несуществующей константе:

Когда не конвертируют типы данных:

Для избежания подобных ошибок — будьте внимательней, и если вам IDE подсказывает о чём-то — не игнорируйте её:

E_STRICT

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

E_DEPRECATED

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

В моём редакторе подобные функции будут зачёркнуты:

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

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

• E_USER_ERROR — критическая ошибка
• E_USER_WARNING — не критическая ошибка
• E_USER_NOTICE — сообщения которые не являются ошибками

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

• если display_errors = on , то в случае ошибки браузер получит html c текстом ошибки и кодом 200
• если же display_errors = off , то для фатальных ошибок код ответа будет 500 и результат не будет возвращён пользователю, для остальных ошибок — код будет работать неправильно, но никому об этом не расскажет

Приручение

Для работы с ошибками в PHP существует 3 функции:

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

• $errno — первый аргумент содержит тип ошибки в виде целого числа
• $errstr — второй аргумент содержит сообщение об ошибке
• $errfile — необязательный третий аргумент содержит имя файла, в котором произошла ошибка
• $errline — необязательный четвертый аргумент содержит номер строки, в которой произошла ошибка
• $errcontext — необязательный пятый аргумент содержит массив всех переменных, существующих в области видимости, где произошла ошибка

С обработчиком, который написан выше есть одна существенная проблема — он не ловит фатальные ошибки, и при таких ошибках вместо сайта пользователи увидят лишь пустую страницу, либо, что ещё хуже, сообщение об ошибке. Дабы не допустить подобного сценария следует воспользоваться функцией register_shutdown_function() и с её помощью зарегистрировать функцию, которая всегда будет выполняться по окончанию работы скрипта:

Данная функция будет срабатывать всегда!

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

О прожорливости

Проведём простой тест, и выясним — сколько драгоценных ресурсов кушает самая тривиальная ошибка:

В результате запуска данного скрипта у меня получился вот такой результат:

Теперь добавим ошибку в цикле:

Результат ожидаемо хуже, и на порядок (даже на два порядка!):

Вывод однозначен — ошибки в коде приводят к лишней прожорливости скриптов — так что во время разработки и тестирования приложения включайте отображение всех ошибок!

Где собака зарыта

В PHP есть спец символ «@» — оператор подавления ошибок, его используют дабы не писать обработку ошибок, а положится на корректное поведение PHP в случае чего:

При этом обработчик ошибок указанный в set_error_handler() всё равно будет вызван, а факт того, что к ошибке было применено подавление можно отследить вызвав функцию error_reporting() внутри обработчика, в этом случае она вернёт 0 .

Исключения

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

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

Исключение — это объект класса Exception либо одного из многих его наследников, содержит текст ошибки, статус, а также может содержать ссылку на другое исключение которое стало первопричиной данного. Модель исключений в PHP схожа с используемыми в других языках программирования. Исключение можно инициировать (как говорят, «бросить») при помощи оператора throw , и можно перехватить («поймать») оператором catch . Код генерирующий исключение, должен быть окружен блоком try , для того чтобы можно было перехватить исключение. Каждый блок try должен иметь как минимум один соответствующий ему блок catch или finally :

В каких случаях стоит применять исключения:

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

Соответственно ловить данные исключения будем примерно так:

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

Теперь, если использовать эти исключения то можно получить следующий код:

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

Так, а что будет если не поймать исключение? Вы получите «Fatal Error: Uncaught exception . ». Неприятно.

Чтобы избежать подобной ситуации следует использовать функцию set_exception_handler() и установить обработчик для исключений, которые брошены вне блока try-catch и не были обработаны. После вызова такого обработчика выполнение скрипта будет остановлено:

Ещё расскажу про конструкцию с использованием блока finally — этот блок будет выполнен вне зависимости от того, было выброшено исключение или нет:

Для понимания того, что это нам даёт приведу следующий пример использования блока finally :

Т. е. запомните — блок finally будет выполнен даже в том случае, если вы в блоке catch пробрасываете исключение выше (собственно именно так он и задумывался).

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

PHP7 — всё не так, как было раньше

Так, вот вы сейчас всю информацию выше усвоили и теперь я буду грузить вас нововведениями в PHP7, т. е. я буду рассказывать о том, с чем вы будете сталкиваться работая над современным PHP проектом. Ранее я вам рассказывал и показывал на примерах какой костыль нужно соорудить, чтобы отлавливать критические ошибки, так вот — в PHP7 это решили исправить, но? как обычно? завязались на обратную совместимость кода, и получили хоть и универсальное решение, но оно далеко от идеала. А теперь по пунктам об изменениях:

1. при возникновении фатальных ошибок типа E_ERROR или фатальных ошибок с возможностью обработки E_RECOVERABLE_ERROR PHP выбрасывает исключение
2. эти исключения не наследуют класс Exception (помните я говорил об обратной совместимости, это всё ради неё)
3. эти исключения наследуют класс Error
4. оба класса Exception и Error реализуют интерфейс Throwable
5. вы не можете реализовать интерфейс Throwable в своём коде

Сложно? Теперь на примерах, возьмём те, что были выше и слегка модернизируем:

В результате ошибку поймаем и выведем:

Как видите — поймали исключение ParseError, которое является наследником исключения Error , который реализует интерфейс Throwable , в доме который построил Джек. Ещё есть множество других исключений, но не буду мучать — для наглядности приведу иерархию исключений:

И чуть-чуть деталей:

TypeError — для ошибок, когда тип аргументов функции не совпадает с передаваемым типом:

ArithmeticError — могут возникнуть при математических операциях, к примеру когда результат вычисления превышает лимит выделенный для целого числа:

AssertionError — редкий зверь, появляется когда условие заданное в assert() не выполняется:

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

Единообразие

— Там ошибки, тут исключения, а можно это всё как-то до кучи сгрести?

Да запросто, у нас же есть set_error_handler() и никто нам не запретит внутри оного обработчика бросить исключение:

Но данный подход с PHP7 избыточен, со всем теперь справляется Throwable :

Отладка

Иногда, для отладки кода, нужно отследить что происходило с переменной или объектом на определённом этапе, для этих целей есть функция debug_backtrace() и debug_print_backtrace() которые вернут историю вызовов функций/методов в обратном порядке:

В результате выполнения функции debug_print_backtrace() будет выведен список вызовов приведших нас к данной точке:

Проверить код на наличие синтаксических ошибок можно с помощью функции php_check_syntax() или же команды php — l [путь к файлу] , но я не встречал использования оных.

Assert

Первый случай — это когда вам надо написать TODO прямо в коде, да так, чтобы точно не забыть реализовать заданный функционал:

В результате выполнения данного кода получим E_WARNING :

PHP7 можно переключить в режим exception, и вместо ошибки будет всегда появляться исключение AssertionError :

В результате ожидаемо получаем исключение AssertionError .

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

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

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

Если у вас есть живой опыт использования assert() — поделитесь со мной, буду благодарен. И да, вот вам ещё занимательно чтива по этой теме — PHP Assertions, с таким же вопросом в конце

Техническая оптимизация. Проверка сайта на ошибки

Содержание
1. Проверка ошибок в коде сайта
2. Проверка стабильности работы сайта
3. Проверка отображения сайта на различных устройствах
4. Возможности Google и Яндекс вебмастер
5. Проверка контента сайта
6. Программы для проверки сайта на ошибки

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

1. Проверка ошибок в коде сайта

Для проверки ошибок в коде сайта можно использовать сервис https://validator. w3.org/. Данный сервис позволяет проверять страницы сайтов, просто скопированные куски кода, а также загруженные файлы. Поисковая система Яндекс, например, рекомендует вебмастерам и разработчикам проверять свои сайты именно в этом сервисе. Сайт не содержащий грубых ошибок будет правильнее восприниматься всеми браузерами. Также не стоит забывать про оптимизацию кода на сайте. Оптимизированный код сайта обеспечит:

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

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

Дополнительным инструментом для проверки ошибок в коде сайта послужит CSS валидатор (https://jigsaw. w3.org/css-validator/). Поскольку поисковые системы сегодня индексируют и скрипты и стили, крайне важно, чтобы файлы. css содержали как можно меньше ошибок.

Еще сервисы для поиска технических ошибок

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

Для того, чтобы проверить коды ответа сервера, настройку редиректов, заголовок Last-Modified используем данный сервис — https://www. rexswain. com/httpview. html.

А вот еще один сервис https://urivalet. com/, который имеет более широкий функционал. Он также позволяет проверить коды ответа сервера, просчитывает скорость загрузки страницы, получить данные о внутренних и внешних ссылках страницы. Еще сайт urivalet. com позволяет просмотреть страницу глазами поискового робота.

2. Стабильность работы сайта

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

3. Проверка отображения сайта на мобильных устройствах

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

Детальный валидатор, указывающий на ошибки вашей адаптивной версии — https://validator. w3.org/mobile/.

Сервис-эмулятором просмотра сайта с различных мобильных устройств – https://www. mobilephoneemulator. com/.

4. Анализ сайта на ошибки в Google и Яндекс Вебмастер

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

1. Информирование о появлении ошибок на сайте, либо о применении санкций.

2. Возможность настроить отображение сайта в поиске: миркоразметка, HTML.

3. Данные о внешних и внутренних ссылка сайта.

4. Сервис предоставляет данные о видимости сайта в поиске: показы, клики, CTR.

5. Сервис показывает информацию о количестве проиндексированных страниц сайта.

6. Возможность просмотра страницы как Google bot, настроить сканирование сайта при помощи файлов: robots. txt и sitemap. xml.

7. Проверка и оповещение о наличии на сайте вирусов.

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

5. Проверка контента сайта

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

Анализ страниц сайта на наличие орфографических ошибок

Проверить страницы сайта на содержание в них орфографических ошибок поможет инструмент из панели вебмастеров Яндекс — https://webmaster. yandex. ua/spellcheck. xml

Подобный инструмент есть также на сайте студии Артемия Лебедева — https://www. artlebedev. ru/tools/orfograf/.

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

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

В SEO много говорят про уникальность текста. Проверить насколько уникален текст на странице вашего сайта можно здесь:

• https://www. content-watch. ru/
• https://advego. ru/plagiatus/
• https://www. etxt. ru/antiplagiat/

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

6. Программы для анализа сайта на ошибки

Программа для поиска битых ссылок

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

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

Xenu’s Link Sleuth

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

Xenu поможет в в поиске:

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

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

Netpeak Spider

Netpeak Spider – это еще одна бесплатная программа в Ваш список. Она станет незаменимой для составления технического аудита сайта.

Что может Netpeak Spider?

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

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

Программа для анализа доноров Fast Trust

Каждый сеошник регулярно занимается анализом ссылочной массы сайта. Алгоритмы постоянно ужесточают свои требования к ссылочному профилю ресурса, анализ приходится делать тщательней, иногда используя и по несколько сервисов. Это рутинная работа и весьма трудоемкая. Fast Trust – десктопная програмка (платная), которая позволяет быстро проанализировать все ссылки Вашего ресурса и оценить их качество. Программа использует актуальные данные самых популярных сервисов и оценивает качество Ваших доноров. Все это красиво экспортируется в таблицу.

Отсюда Fast Trust берет свои данные

А вот так выглядит интерфейс программы.

Заключение

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

Оцени пост!

Статьи по теме

17/08/2016Как проверить сайт на наличие битых ссылокКак известно, позиции сайта очень сильно зависят от качества сайта. В свою очередь на качество сайта сильно […]Posted in Продвижение сайтов, Оптимизация сайта09/01/2017Итоги продвижения и развития блога в 2016 годуВсем привет! 2016 год оказался очень успешным в плане развития блога. Именно в этом году я покорил 1000 […]Posted in Новости, Продвижение сайтов, Интернет бизнес, Веб-аналитика18/08/2016Google Phantom 4По мнению зарубежных экспертов, не так давно, в конце июня, произошло значительное обновление одного из […]Posted in Новости, Продвижение сайтов, Оптимизация сайта

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

Обратные ссылки можно посмотреть в панели вебмастера Google Webmaster Tool.

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

Здравствуйте.
У меня сейчас сайт https://artlavca. ru/ это старый сайт с новым контентом (раньше это был художественный сайт-теперь кулинарный).
Яндекс-вебмастер показывает какие-то ошибки со склейками или с зеркалами-мне совершенно не понятно, а мне нужно чтобы все было нормально перед раскручиванием сайта, а то окажется, что я его не раскручиваю, а “закручиваю в другую сторону”. Подскажите пожалуйста, что там неправильного с зеркалами и со склейками или наоборот-все нормально?

Скриншот с Яндекс-вебмастер сообщает:.

“artlavca. ru Сайт является неглавным зеркалом и не участвует в поиске.”

Файл robots. txt на сервере:

User-Agent: *
Disallow: */index. php
Disallow: /bitrix/
Disallow: /*?utm_source=
Allow: /bitrix/components/
Allow: /bitrix/cache/
Allow: /bitrix/js/
Allow: /bitrix/templates/
Allow: /bitrix/panel/
Host: https://www. artlavca. ru
Sitemap: https://www. artlavca. ru/sitemap. xml

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

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

Большое спасибо много интересного для себя узнал

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