Модуль Joomla перед продакшеном: чек-лист проверки

Модуль Joomla, который открывается на тестовом сайте, ещё не готов к продакшену. Перед публикацией проверьте не только вывод в шаблоне, но и установку из чистого архива, права доступа, кеширование, обновление, удаление и поведение при PHP-ошибке. Ниже — практический чек-лист для Joomla 5.x: он рассчитан на разработчика или вебмастера, который выпускает собственный модуль, а не просто меняет его настройки.

Сначала зафиксируйте условия релиза

Запишите версию Joomla, минимальную и максимальную поддерживаемую версию PHP, тип модуля — сайт или панель администратора — и способ установки. Если модуль должен работать и на Joomla 4.x, это нужно подтвердить отдельным прогоном: совместимость нельзя выводить только из того, что модуль открылся на Joomla 5.x.

Зафиксируйте также зависимости: расширения Joomla, библиотеку, внешний API, cron-задачу, таблицы базы данных и переменные окружения. Если зависимость не нужна модулю напрямую, не добавляйте её в пакет «на всякий случай». Чем больше внешних условий, тем сложнее перенос и откат.

Чек-лист перед сборкой архива

1. Проверьте структуру каталога. В архиве не должно быть лишнего внешнего уровня вроде release/mod_example/, если установщик ожидает файлы модуля в корне пакета. Названия файлов и каталогов должны совпадать с тем, что указано в манифесте. Проверка: распакуйте ZIP во временный каталог и найдите манифест на ожидаемом уровне.
2. Проверьте манифест. В нём должны быть корректные имя расширения, тип, версия, описание, файлы модуля и языковые файлы, если они используются. Отдельно проверьте, что все перечисленные файлы действительно попали в архив. Проверка: установка на чистую Joomla не должна завершаться ошибкой о пропущенном файле или некорректном XML.
3. Проверьте пространства имён и классы. Для Joomla 5.x имена классов, пути к файлам и правила автозагрузки должны соответствовать выбранной структуре расширения. Не оставляйте старые имена из прототипа: такой конфликт часто проявляется только после включения второго экземпляра модуля. Проверка: включите режим отладки на тестовом сайте и убедитесь, что нет ошибок загрузки класса.
4. Уберите отладочный вывод. Удалите var_dump, print_r, временные записи в лог и тестовые URL. Не оставляйте в настройках модулю ключи API, пароли и токены — даже нерабочие. Проверка: поиск по архиву не должен находить отладочные вызовы и секреты.
5. Проверьте права на файлы. Модуль не должен записывать данные в свой каталог расширения без явной причины. Если ему нужен кеш или временный файл, используйте штатные каталоги Joomla и учитывайте ограничения хостинга. Проверка: сайт должен работать с запретом записи в каталог модуля.
6. Проверьте локализацию. Все видимые строки должны проходить через языковые константы, а файл языка — загружаться из правильного места. Текст константы не должен зависеть от регистра или случайного пробела в имени. Проверка: переключите язык сайта и откройте страницу с модулем без очистки исходного кода.
7. Проверьте настройки экземпляра. Создайте два экземпляра модуля с разными параметрами: например, разными источниками данных или позициями. Проверка: настройки одного экземпляра не должны менять вывод другого.
8. Проверьте меню и права доступа. Откройте модуль для групп с разными уровнями доступа и назначьте ему разные пункты меню. Проверка: модуль виден только там, где разрешён его показ, а закрытый материал не появляется в HTML для неавторизованного пользователя.
9. Проверьте пустые и ошибочные данные. Обработайте пустой ответ API, некорректный JSON, тайм-аут, отсутствие изображения и удалённую запись. Проверка: вместо белого экрана или предупреждений посетитель видит безопасный запасной вариант, а подробность ошибки попадает только в серверный лог.
10. Проверьте HTML и доступность. Один экземпляр модуля не должен создавать дублирующиеся идентификаторы. Заголовки, ссылки, альтернативный текст изображений и фокус клавиатуры должны оставаться корректными в конкретном шаблоне. Проверка: прогоните страницу через валидатор и откройте её с клавиатуры без мыши.

Что проверить на тестовом сайте

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

Готовность модуля — это не «он показывает блок». Это способность безопасно установиться, обновиться, пережить плохие данные и предсказуемо удалиться.

Кеширование и внешние запросы

Кеш — одна из самых частых причин, по которой модуль «работает у разработчика», но показывает посетителям устаревшие или чужие данные. Определите, можно ли кешировать результат для всех пользователей. Если вывод зависит от авторизации, языка, региона, cookie или параметров запроса, общий кеш может привести к утечке данных.

Для внешнего API задайте ограничение времени ожидания и обработайте неуспешный ответ. Не делайте сетевой запрос без необходимости на каждой загрузке страницы: он увеличивает время ответа и связывает доступность сайта с чужим сервисом. Если данные можно обновлять отдельно, вынесите обновление в задачу планировщика или другой контролируемый процесс. Инвалидация кеша — отдельная тема; здесь важно хотя бы не публиковать модуль с бесконечным временем ожидания.

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

Безопасность: что сломать специально

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

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

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

Где чек-лист ломается

Обновление с предыдущей версии

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

Другой шаблон и другой сервер

Модуль, проверенный на одном шаблоне, может конфликтовать с CSS, JavaScript или переопределением разметки другого. Проверьте хотя бы стандартный шаблон Joomla и тот, который используется на продакшене. На сервере отдельно проверьте версию PHP, права файлов, лимит памяти, HTTPS-сертификат и доступ к внешнему API.

Встроенный JavaScript и CSS

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

Финальный прогон перед публикацией

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

1. установите архив на копию сайта;
2. создайте экземпляр и назначьте ему позицию и пункт меню;
3. проверьте гостя, зарегистрированного пользователя и администратора;
4. откройте страницу с включённым и выключенным кешем;
5. обновите модуль поверх установленной версии;
6. удалите модуль и проверьте состояние сайта после удаления;
7. сохраните журнал ошибок, версию архива и список изменённых файлов.

После публикации смотрите не только на доступность страницы. Отслеживайте PHP-ошибки, время ответа страницы, ошибки внешнего API, количество пустых ответов и жалобы на устаревшие данные. Следующим шагом настройте автоматическую проверку XML-манифеста, сборку ZIP из чистого каталога и установочный тест на копии Joomla 5.x — это дешевле, чем искать поломку после обновления продакшена.

Примечание. Манифест — XML-файл, в котором Joomla получает описание расширения: его тип, версию, файлы, языковые ресурсы и сценарии установки или удаления.