Рефакторинг сайта на DLE с правками ядра: как устроено внутри

После правки ядра DataLife Engine обновление перестаёт быть обычной заменой файлов: новая версия может затереть изменения в engine/, а сайт — потерять авторизацию, вывод материалов или обработку форм. В этом разборе для DLE 17.x показано, как запрос проходит через ядро, почему локальные патчи плохо переживают апдейты и что проверять перед переносом проекта на новую версию.

Что именно происходит после запроса

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

Дальше DLE определяет тип страницы: главная, материал, категория, поиск, профиль, комментарии или административный раздел. В зависимости от маршрута подключается нужный обработчик из каталога engine/modules/. Результат проходит через шаблон из каталога templates/, после чего формируется HTML-ответ.

Точные имена файлов и порядок подключений зависят от версии и конкретного модуля. Перед рефакторингом зафиксируйте версию DLE, PHP, список установленных дополнений и содержимое каталога engine/. Для этой статьи используется DLE 17.x; перенос описанных решений на другую ветку требует сверки с её дистрибутивом и документацией.

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

Где проходит граница между сайтом и ядром

Файлы, которые отвечают за общий жизненный цикл

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

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

Модули и шаблоны

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

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

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

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

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

Особенно опасны изменения, которые:

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

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

Три стратегии рефакторинга

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

Как разбирать существующий патч

1. Составьте карту изменений. Получите список файлов, которые отличаются от чистого дистрибутива той же версии DLE. Сравнивайте не с текущей папкой из резервной копии, а с оригинальным архивом конкретного релиза. Результат — перечень файлов и короткое описание каждого изменения.
2. Найдите точку входа. Для каждого патча запишите, какой запрос его вызывает: открытие материала, отправка комментария, вход пользователя, поиск или административное действие. Если это неизвестно, поставьте временное журналирование на тестовой копии и проследите последовательность вызовов, не включая вывод чувствительных данных.
3. Отделите данные от представления. SQL, проверки доступа и преобразование входных параметров должны оставаться на серверной стороне; HTML и классы отображения — в шаблоне. Такое разделение уменьшает площадь конфликта с обновлением.
4. Опишите зависимости. Зафиксируйте используемые таблицы, поля, настройки, глобальные переменные, версии PHP и сторонние дополнения. Не полагайтесь на имя переменной: проверьте, где она создаётся и может ли быть не определена.
5. Сделайте повторяемую проверку. На копии сайта проверьте гостя, обычного пользователя, администратора, мобильный шаблон, ошибочный ввод, пустой результат и повторную отправку формы. Успешным считается не только отсутствие ошибки PHP, но и правильный ответ для каждой роли.

Что обычно ломается первым

Обновление затирает файл

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

Появляется белая страница или HTTP 500

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

Работает у администратора, но не у пользователя

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

Форма отправляется дважды

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

Кеш показывает старые данные

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

Где подход ломается

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

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

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

Что измерять до и после

Без замеров нельзя честно утверждать, что рефакторинг ускорил сайт. Зафиксируйте на тестовой копии версию PHP, тип хостинга, объём базы и набор включённых дополнений. Для одинакового URL измерьте время ответа, HTTP-код, количество запросов к базе, размер ответа и долю ошибок.

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

Что делать дальше

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

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

Сноска. Контракт — ожидаемое соглашение между частями программы: какие данные получает функция или модуль, что возвращает и какие ошибки может产生ить. Если патч нарушает этот контракт, сбой часто появляется в другом участке DLE.