Рефакторинг старого сайта на Joomla: что внутри меняют

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

Сначала определите, что именно у вас старое

Под «старой Joomla» могут скрываться разные системы: сайт на Joomla 3, проект на Joomla 4 с самописными расширениями или новая версия CMS со старым шаблоном и накопившимися переопределениями. Это не одно и то же. У Joomla 3 и Joomla 4/5 отличаются требования к совместимости расширений и способы организации кода, поэтому универсальный план «обновить всё и проверить» рискован.

Дальше речь о разборе проекта на Joomla 4 или 5: о том, как устроены его границы и что проверять перед изменениями. Это не инструкция по переходу с Joomla 3 и не обзор всех возможностей CMS. Если сайт работает на Joomla 3, совместимость нужно оценивать отдельно по документации выбранной версии и расширений.

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

Границы проекта: ядро, расширения, шаблон

В Joomla важно не смешивать код самой CMS с тем, что сайт добавляет поверх неё. Ядро можно обновлять независимо от многих проектных решений, а расширения и шаблон могут иметь собственные версии, настройки и зависимости. Если правка сделана прямо в файлах ядра, обновление CMS способно её затереть. Это не просто неудобство: такой патч делает следующее обновление проверкой на удачу.

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

• Ядро Joomla. Не меняйте его файлы ради проектной логики. Ищите поддерживаемый механизм расширения или локальную замену, которую можно сопровождать отдельно.
• Компоненты. Часто отвечают за отдельные разделы и основной сценарий работы с данными. Проверьте маршруты, формы, сохранение записей и права доступа.
• Плагины. Могут реагировать на события и менять поведение других частей сайта. При разборе ищите не только вызовы из шаблона, но и события, на которые подписываются плагины.
• Шаблон и переопределения. Меняют отображение, но могут содержать и логику представления. Сравните переопределённые файлы с исходными, иначе обновление шаблона может принести уже исправленный код, который сайт продолжит обходить.

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

Как движется запрос

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

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

В собственных расширениях Joomla 4/5 использует пространства имён и сервисный контейнер; устройство конкретного расширения зависит от его версии и способа установки. Не переносите механически старый код на новый: совпадение имён файлов не означает совместимость API. Сверяйте точку входа, регистрацию сервисов и события с документацией именно той версии Joomla, под которую пишете.

Самая дорогая часть старого проекта — не старый код, а неизвестные связи между ним. Пока вы не знаете, кто вызывает компонент и что меняет результат, «маленькая чистка» остаётся рискованным изменением поведения.

Что измерить до правок

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

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

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

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

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

Граничные случаи

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

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

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

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

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

Смежная тема — перенос сайта с Joomla 3 на более новую версию: здесь разбирается только устройство проекта на Joomla 4/5 и безопасное изменение его частей.