Многоязычный сайт на MODX: чек-лист перед продакшеном

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

Что выбрать до проверки

Сначала зафиксируйте архитектуру. На MODX чаще всего используют отдельный контекст для каждого языка и связывают ресурсы между собой через Babel или другое дополнение. Такой вариант удобен для разных доменов, поддоменов и независимых настроек контекстов. Второй путь — один контекст с языковыми полями, TV-параметрами или логикой в чанках и сниппетах. Он проще для небольшого каталога, но быстро усложняется при разных URL, правах и SEO-настройках.

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

[1] Контекст MODX — отдельная область настроек и выполнения сайта. У него могут быть собственные домен, культура, права, системные настройки и дерево ресурсов.

Чек-лист перед публикацией

1. Зафиксируйте версии и окружение

Запишите версию MODX Revolution 3.x, PHP, базы данных и каждого дополнения, которое участвует в языковой логике. Особенно важны Babel, обработчики URL, формы, SEO-инструменты и пакеты, которые меняют выбор контекста. Не обновляйте дополнения непосредственно перед запуском без отдельной проверки: небольшое изменение может повлиять на плейсхолдеры, права или генерацию ссылок.

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

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

2. Проверьте контексты и языковые настройки

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

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

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

3. Проверьте связи переводов

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

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

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

4. Проверьте URL, редиректы и канонические адреса

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

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

Проверка: для каждой пары языковых страниц нет цепочки из нескольких редиректов, а окончательный ответ имеет ожидаемый код 200 или 404.

5. Проверьте меню, хлебные крошки и внутренние ссылки

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

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

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

6. Проверьте словари и системные сообщения

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

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

7. Пройдите формы и почту

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

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

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

8. Проверьте кеш, очистку и публикацию

Один из опасных дефектов — кеширование страницы одного языка с последующей выдачей её посетителю другого языка. Тестируйте сайт в новом приватном окне, после очистки кеша MODX и после повторного посещения уже открытой страницы. Если используется серверный, CDN- или прокси-кеш, проверяйте и его правила.

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

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

9. Проверьте права и резервное копирование

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

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

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

Что ломается чаще всего

• Переключатель ведёт на главную. Обычно текущий ресурс не связан с переводом или шаблон получает неверный идентификатор контекста.
• Страница иногда открывается не на том языке. Ищите конфликт кешей, доменных настроек и определения текущего контекста.
• Меню показывает только один язык. Проверьте фильтр контекста и права на ресурсы, а не только шаблон меню.
• После смены алиаса появился 404. Проверьте связанный перевод, опубликованность ресурса и правила генерации URL.
• Текст в письме остался на языке по умолчанию. Форма может выполняться в одном контексте, а шаблон письма — использовать глобальный словарь.

Когда проверка считается завершённой

Соберите матрицу: язык, тип страницы, сценарий, ожидаемый URL, код ответа и результат. Включите в неё главную, раздел, запись, карточку, поиск, форму, 404, страницу согласия и мобильное меню. Каждый пункт должен быть проверен с чистой сессией и после очистки кеша.

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

Что делать после запуска

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

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