Инструкция по выявлению ошибок при кастомизации и обновлении

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

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

Но начну я с рассказа об очень важном и нужном новом модуле, который появился в DIAFAN.CMS после написания данной статьи, в версии 6.0.12.2 - модуле "Лог". Это хоть и полностью технический инструмент, но он будет полезен и обычным пользователям, поскольку вместе с обращением в тех.поддержку и описанием "ничего не работает" теперь можно предоставить файл с записью всех ошибок, произошедших на сайте в последнее время, как явных, так и оставшихся незамеченными. Техническому специалисту этот файл будет "вместо тысячи слов". Итак, по порядку.

Лог ошибок

Этот модуль может быть выключен в Вашей системе или его и вовсе может не быть, если Ваша версия CMS ниже упомянутой выше 6.0.2.12. Так что нужно проверить версию и обновиться и включить модуль или же просто включить. Включается он в разделе "Модули и БД" стандартным способом:

После включения модуль начнёт работу и станет писать ошибки в файл. Файл этот расположен в папке сайта /tmp

А в амин-панели пункт меню модуля после активации будет расположен внизу меню, в разделе "Настройки".

Структура файла ошибок (/tmp/logs/errors.log), состоит из блоков, разбитых по дням и списком ошибок с нумерацией, имевших место в каждый конкретный день:

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

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

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

Как видно из скриншота, зафиксированная ошибка 8-го февраля была выявлена и передана разработчикам, а 10-го числа уже вышло её исправление в составе версии 6.0.2.13. Так что инструмент очень полезный, не забывайте его включать и пользуйтесь.

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

Создание резервной копии

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

Сброс кеша

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

Далее надо в админ-панели в разделе "Параметры сайта" отключить и сбросить кеш и включить режим разработчика.

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

Я предпочитаю работать через FTP, так всё понятнее и нагляднее. Да и дальше всё-равно придётся истользовать FTP.

Затем нужно перейти в подкаталог /cache и удалить там все папки с кешем и все файлы, кроме файла .htaccess. Этот файл удалять нельзя категорически, он отвечает за безопасность.

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

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

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

Следующим шагом к устранению ошибки, если предыдущие действия не возымели успеха, является восстановление базы данных. При установке дополнений, например, в неё могут вноситься изменения. Нужно запустить процесс восстановления в разделе "Модули и БД".

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

Откат и замена обновлений

Как известно, не ошибается тот, кто ничего не делает. Проблема может не только в Вашей теме, но и в одном из установленных обновлений. Чаще всего в последнем. Всё работало, обновились - перестало. Подобные проблемы решаются либо откатом к предыдущему обновлению в разделе "Обновление CMS", либо исправляются в следующем обновлении (патч).

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

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

Это тоже в ряде случаев может помочь. Но как показывает практика, в 90% случаев ошибка исчезает, что прямо указывает на конфликт файлов системы и пользовательской кастомизации. Если ошибка исчезла - идём дальше.

Поиск проблемной темы или дополнения

Проблемная тема ищется путём включения/перемещения/переименования (т.е. обратного процесса) каждой темы последовательно. Начинать нужно с активной темы оформления, отвечающей за дизайн (в случае с Diafan.Cloud это тема "my").

Затем сгенерированная тема (если таковая была) и затем уже темы с дополнениями. Если проблема в теме с дополнением, следует обратиться к его автору. Если автор Diafan - в тех.поддержку. Если проблема возникает при переносе/переименовании темы оформления, то следует искать проблемный файл/код внутри неё.

Поиск проблемного кода

Итак, проблемная тема найдена и активна. Ошибка выводится. Теперь следует работать с этой темой через FTP. Файл ищется путём переименования сначала вложенных каталогов по очереди, а затем, когда вложенные каталоги закончатся, переименованием файлов. Начинать следует с папки /modules в теме.

Если её переименование устраняет ошибку, далее переименовываются каталоги модулей. Начинать следует с модулей /cart и /shop. Проблема чаще всего там. Вот как это выглядит:

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

В этом случае нужно сравнить системный файл, который был загружен с последним обновлением и кастомизированный. Заниматься этим должен специалист. "Метод тыка" может привести к ошибкам в работе, в т.ч. скрытым, о которых узнаете случайно или не узнаете вовсе (перестанут скидки или купоны работать, например). Так что лучше обратиться к специалисту, он возьмёт обновлённый файл, добавит Ваши изменения туда и отладит его работу.

Сравнение файлов

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

• Meld (кроссплатформенная)
• WinMerge (Windows)

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

/custom/design/modules/cart/js/cart.form0.js

/modules/cart/js/cart.form.js

В Meld сравнение файлов выглядит следующим образом:

Синие выделения - это смещения строк в файле. Зелёные - различия. Вот по различиям и нужно отслеживать причину возникновения ошибки.

Частичная кастомизация

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

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

Например, чтобы добавить несколько шаблонов модуля корзины в обработчик action, достаточно создать в папке модуля в теме файл cart.action.custom.php со следующим содержимым:

class Cart_action extends Action{
    after public function recalc(){
        $this->result["data"] = array(
            ".cart-products" => $this->diafan->_tpl->get('products', 'cart', $form),
            ".cart-products-result" => $this->diafan->_tpl->get('price_total', 'cart', $form),
        );
    }
}

При пересчёте корзины данные в этих шаблонах обновятся.

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

Проблема усугубляется тем, что файл в корне (системный) при обновлениях может заменяться и тот файл, который скопировали в кастомную тему уже сам по себе другой версии. Допустим, установили CMS версии 6.0.11.1. Перенесли файл в кастомную тему и внесли в него изменения.

Затем обновили систему до 6.0.11.4. С обновлением пришёл свежий файл cart.action.php. Он уже чем-то отличается от того исходного, который переносили в кастом. Даже там, где код программист не трогал. И специалисту придётся потратить дополнительно время на выяснение этих моментов. Поэтому бездумная кастомизация вредит обновлению CMS и усложняет (порой на порядок) поддержку и доработку сайта в будущем.

Обратите внимание на скриншот ниже:

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

Под №2 идёт более сложный проект, но кастомизация там касается в основном view-шаблонов, CSS и JS файлов модулей. А все сложные функции выполнены в виде аналогичных примеру сверху вставок с использованием префиксов new, replace, before и after. Поэтому работа модулей практически не затрагивается, ориентироваться в изменениях очень просто, т.к. в файлах всего по нескольку строк.

Надеюсь, данное руководство было для Вас полезным! Успехов в устранении ошибок.