На первый взгляд задача выглядит просто: скопировать файлы и импортировать базу данных. На практике после такого копирования сайт может открыть пустую страницу, вернуть ошибку 500, потерять стили, перестать заходить в MODX Manager или продолжить обращаться к каталогам старого сервера.
Причина в том, что перенос MODX затрагивает не только файлы сайта. Нужно сохранить базу данных, проверить абсолютные пути, настройки веб-сервера, PHP, права доступа, домен и конфигурацию самой CMS.
Разберём, что проверить при переносе существующего сайта MODX и почему безопаснее сначала добиться полного запуска копии на новом сервере, а уже затем переключать рабочий домен.
Что входит в перенос сайта MODX
Обычно необходимо перенести несколько связанных частей:
- файлы сайта;
- каталог
core; - базу данных;
- изображения и загруженные файлы;
- установленные Extras;
- собственные сниппеты, плагины и компоненты;
- конфигурацию MODX;
- правила веб-сервера;
- SSL и доменные настройки;
- cron-задачи и внешние интеграции, если они используются.
Если перенести только публичные файлы из корня сайта, этого недостаточно. Значительная часть конфигурации и данных MODX находится за пределами обычных HTML-шаблонов.
Поэтому перед началом полезно определить, как именно устроен конкретный проект.
Сначала нужно проверить новый сервер
До копирования рабочего сайта стоит убедиться, что новое окружение вообще совместимо с его версией MODX.
Для актуальной ветки MODX 3.2+ требуется PHP 8.1 или новее. В современной документации MODX минимальной поддерживаемой версией MySQL указана 5.7, а в качестве рекомендуемого окружения — MySQL 8.0+ или MariaDB 10.6+. Требуются также стандартные PHP-расширения, включая curl, pdo, pdo_mysql, dom, gd, json, simplexml, xml, zip и другие.
Но перенос старого проекта нельзя планировать только по требованиям последней версии MODX.
Например, сайт на MODX 2.x может содержать старые Extras и собственный PHP-код, рассчитанный на другую версию PHP. Поэтому сначала проверяют фактическую версию CMS и компонентов, а уже после этого выбирают PHP на новом сервере.
Иначе можно получить ситуацию, когда сама CMS формально совместима с окружением, но один старый плагин или сниппет останавливает весь сайт.
Сделайте полную копию файлов и базы
Перед переносом нужна рабочая резервная копия исходного сайта.
Она должна включать как минимум:
- все файлы проекта;
- базу данных;
- содержимое
assets; - конфигурационные файлы;
- custom-код;
- используемые серверные правила.
Экспорт базы лучше выполнять способом, который надёжно работает с её фактическим размером. Официальная документация MODX отдельно отмечает возможность использовать mysqldump и обращает внимание, что веб-инструменты вроде phpMyAdmin ограничены ресурсами PHP и на больших базах могут быть менее удобны.
Важно проверить не только наличие файла дампа, но и то, что экспорт действительно завершился без ошибки.
Повреждённая или обрезанная SQL-копия обнаруживается уже после переключения сайта — в самый неудобный момент.
Перенос файлов MODX
На новый сервер переносится вся структура проекта, а не только файлы темы или содержимое assets.
Для обычной установки MODX среди ключевых каталогов находятся:
core;manager;connectors;assets;
а также корневые PHP-файлы и конфигурация проекта.
В актуальной MODX 3 архитектура установки имеет дополнительные ограничения: например, core больше нельзя произвольно переименовывать или переносить в нестандартное место так, как это допускали некоторые старые конфигурации. Поэтому при миграции старого проекта особенно важно понимать его исходную структуру, а не автоматически применять настройки свежей установки.
После копирования файлов необходимо проверить владельца файлов, права каталогов и возможность PHP работать с теми директориями, куда MODX должен записывать данные.
Перенос базы данных MODX
После файлов переносится база данных.
На новом сервере создаётся база и пользователь с необходимыми правами, после чего импортируется дамп рабочего сайта.
Здесь часто возникают четыре типа проблем:
- используется неправильное имя базы;
- указан другой пользователь или пароль;
- отличается адрес MySQL-сервера;
- импорт завершился не полностью.
Если MODX после переноса сообщает об ошибке соединения с базой, первым делом нужно проверить именно новую конфигурацию подключения и доступность базы с сервера сайта.
Не стоит сразу изменять файлы ядра или переустанавливать MODX.
Конфигурация core/config/config.inc.php
Один из ключевых этапов переноса — проверка основного конфигурационного файла:
core/config/config.inc.php
Официальная инструкция MODX указывает, что после размещения сайта на новом сервере в нём необходимо проверить абсолютные пути к core, processors, connectors, manager, корню проекта и assets.
Например, на старом сервере сайт мог находиться в каталоге:
/home/olduser/public_html/
а на новом:
/var/www/example/current/
Файлы уже находятся в правильном месте, но MODX продолжает использовать старый абсолютный путь.
В результате возможны:
- белый экран;
- PHP warning или fatal error;
- неработающий Manager;
- отсутствие компонентов;
- ошибки подключения файлов.
Поэтому после переноса пути нужно проверять по фактической структуре нового сервера.
Проверьте config.core.php
Кроме основного config.inc.php, MODX использует дополнительные конфигурационные файлы, содержащие путь к core.
Официальный гайд по переносу отдельно указывает:
/config.core.php;/connectors/config.core.php;/manager/config.core.php.
Если абсолютный путь изменился, старое значение в одном из этих файлов способно привести к ситуации, когда главная страница работает, а Manager или connectors — нет.
Поэтому проверять нужно всю связку конфигурации, а не только первый найденный файл.
Путь workspaces в базе данных
В некоторых конфигурациях старый путь к core сохраняется также в таблице workspaces.
Документация MODX рекомендует проверить значение path для workspace и при необходимости привести его к фактическому расположению core на новом сервере.
Это особенно важно, если структура каталогов изменилась значительно.
Редактировать базу вслепую не следует: сначала нужно посмотреть текущее значение и убедиться, что оно действительно содержит путь старого сервера.
ЧПУ и конфигурация веб-сервера
После переноса обычная главная страница может открываться, а остальные URL возвращать 404.
В таком случае проблема часто находится не в ресурсах MODX, а в rewrite-настройках Apache или nginx.
При переносе необходимо проверить:
.htaccess, если используется Apache;- nginx-конфигурацию;
- Friendly URLs;
- base URL;
- доменные редиректы;
- правила HTTPS;
- старые абсолютные ссылки.
Официальный гайд MODX отдельно рекомендует проверять .htaccess, особенно если одновременно меняется доменное имя.
Если сайт переносится между Apache и nginx, старый .htaccess вообще не становится автоматически конфигурацией nginx — правила необходимо реализовать средствами нового веб-сервера.
Перенос на другой домен
Если вместе с сервером меняется домен, задача становится шире обычного копирования.
Нужно проверить:
- новый virtual host;
- DNS;
- SSL-сертификат;
- системные настройки MODX;
site_url;- контексты, если они используются;
- ссылки в шаблонах и чанках;
- email-настройки;
- webhook и API URLs;
- внешние сервисы;
- правила редиректов.
Особое внимание требуется внешним интеграциям.
Например, CRM или платёжная система может принимать запросы только с прежнего адреса, а webhook продолжит отправляться на старый домен даже после успешного переноса самого сайта.
Кэш MODX после переноса
MODX кэширует значительный объём конфигурационной информации.
После переноса старые пути или настройки могут остаться в кэше, из-за чего возникает странная картина: конфигурационные файлы уже исправлены, но Manager продолжает искать контроллер по каталогу старого сервера.
Официальная документация рекомендует очищать кэш после переноса; при оставшихся старых session/cache данных это особенно важно для восстановления корректной работы Manager.
При этом очистка кэша — не замена исправлению конфигурации.
Если путь действительно неправильный, удаление кэша лишь временно изменит симптомы или не поможет вовсе.
Что проверить в MODX Manager
После запуска нового экземпляра нужно войти в административную панель и проверить не только сам факт авторизации.
Стоит открыть:
- дерево ресурсов;
- несколько обычных страниц;
- системные настройки;
- установленные Extras;
- страницы компонентов;
- Media Browser;
- формы и динамические элементы.
Если Manager открывается, но отдельный компонент выдаёт ошибку, причиной может быть его собственный абсолютный путь, несовместимая версия PHP или отсутствующее расширение.
Формы и почта после переноса
Формы — один из сценариев, который легко пропустить при технической проверке.
Страница открылась, Manager работает, но заявки перестали приходить.
После переноса следует проверить:
- отправку формы;
- FormIt hooks;
- PHP mail или SMTP;
- данные SMTP-сервера;
- DNS-записи почты, если менялся домен;
- firewall нового сервера;
- API внешней CRM.
Новый хостинг или VPS может иметь другие ограничения исходящих соединений, поэтому работа формы на старом сервере не гарантирует работу почтовой части на новом.
miniShop2 и интернет-магазин
Если сайт использует miniShop2, одной проверки каталога недостаточно.
Нужно пройти как минимум:
каталог → карточка товара → корзина → оформление заказа.
Также проверяются:
- способы доставки;
- платёжные модули;
- письма;
- callbacks;
- webhook;
- cron;
- интеграции с учётными системами.
Реальную оплату в production проводят только тогда, когда это действительно предусмотрено планом проверки.
До переключения домена большинство сценариев можно проверить на тестовой копии.
Cron и фоновые задачи
Cron часто вообще не входит в файлы сайта и поэтому не переносится вместе с проектом.
Если MODX или установленные компоненты используют планировщик для:
- импорта;
- синхронизации;
- очистки;
- обновления данных;
- отправки сообщений;
- обмена с внешними системами;
задачи нужно отдельно перенести или создать на новом сервере.
Иначе сайт может выглядеть полностью рабочим сразу после миграции, а через несколько часов обнаружится, что перестал обновляться каталог или уходить автоматические уведомления.
Права файлов и пользователь веб-сервера
Другой распространённый класс проблем — права доступа.
На старом сервере PHP мог выполняться от одного пользователя, а на новом — от другого.
В результате MODX читает файлы, но не может:
- записывать кэш;
- устанавливать пакет;
- создавать файл;
- загружать изображение;
- обновлять конфигурацию.
Исправление не должно сводиться к выдаче максимальных прав всем каталогам.
Сначала определяется пользователь PHP/web-сервера и требуемые writable directories, после чего выставляются минимально необходимые права.
Нужно ли обновлять MODX во время переноса
Не обязательно.
Перенос сайта и обновление MODX — две разные операции.
Если одновременно поменять:
- сервер;
- PHP;
- версию MODX;
- версию Extras;
- конфигурацию веб-сервера;
а затем получить ошибку, установить её источник становится значительно сложнее.
Поэтому для старого рабочего проекта часто безопаснее сначала воспроизвести его работу на новом сервере максимально близко к исходному состоянию.
После успешного переноса можно отдельно планировать обновление.
Особенно это важно при переходе с MODX 2.x на современную ветку 3.x: официальная документация перечисляет ряд breaking changes в классах, processors, xPDO и других частях API.
Как безопасно переключить рабочий сайт
Хороший перенос заканчивается не загрузкой последнего файла, а контролируемым переключением.
Практический порядок выглядит так.
1. Подготовить новый сервер
Установить нужное окружение, создать базу, настроить веб-сервер и SSL.
2. Развернуть копию сайта
Перенести файлы и БД, исправить конфигурацию и получить рабочую копию.
3. Проверить основные сценарии
Проверить:
- главную;
- внутренние страницы;
- Manager;
- формы;
- поиск;
- каталог;
- корзину и заказ, если они есть;
- интеграции;
- мобильную версию.
4. Синхронизировать изменившиеся данные
Если старый сайт продолжал принимать заказы, заявки или новый контент во время подготовки переноса, нужно учесть изменения, появившиеся после первоначального дампа.
Особенно это важно для интернет-магазинов.
5. Переключить домен
После проверки изменяются DNS или конфигурация маршрутизации в зависимости от выбранной схемы.
6. Повторно проверить production
После переключения снова проверяются реальные страницы, HTTPS, формы, Manager, логирование и внешние сервисы.
Сайт нельзя считать перенесённым только потому, что главная страница вернула HTTP 200.
Что не стоит делать при переносе MODX
Есть несколько действий, которые часто увеличивают риск:
- одновременно переносить и бесконтрольно обновлять всё окружение;
- исправлять ошибки непосредственно на единственной рабочей копии;
- переключать DNS до проверки нового сервера;
- переносить только файлы без базы;
- забывать о cron и webhook;
- считать работающую главную страницу достаточной проверкой;
- удалять старый сервер сразу после переключения.
Старую рабочую среду разумно сохранить до тех пор, пока новая версия сайта не прошла необходимые проверки и не стала очевидно стабильной.
Что подготовить для переноса MODX
Для оценки задачи обычно нужны:
- адрес сайта;
- текущая версия MODX;
- текущий и новый сервер или хостинг;
- информация о смене домена;
- наличие магазина;
- используемые интеграции;
- желаемое время переключения.
Для самого переноса затем потребуются соответствующие доступы к серверу, файлам, базе и MODX Manager.
Передавать лишние доступы, которые к задаче не относятся, не требуется.
Когда перенос лучше поручить как отдельную задачу
Если сайт простой и практически не менялся, перенос может пройти достаточно прямолинейно.
Но отдельная техническая миграция особенно оправдана, когда используются:
- старый MODX;
- custom PHP;
- miniShop2;
- несколько контекстов;
- нестандартное размещение
core; - собственные компоненты;
- CRM/API;
- cron;
- большой объём данных;
- серверные настройки nginx/Apache;
- одновременно меняются PHP или база данных.
В таких случаях основная задача не в копировании файлов, а в сохранении работоспособности всего проекта после смены окружения.
FAQ
Можно ли перенести сайт MODX на другой хостинг?
Да. Нужно перенести файлы и базу, проверить конфигурационные пути, подключение к базе, веб-сервер, права и основные функции сайта на новом окружении.
Почему после переноса MODX появляется ошибка 500?
Причиной может быть несовместимая версия PHP, неправильный абсолютный путь, ошибка custom-кода или Extra, права файлов либо конфигурация веб-сервера. Нужна диагностика конкретной ошибки по логам.
Почему после переноса не открывается MODX Manager?
Нужно проверить пути core, конфигурационные файлы Manager, кэш, права и совместимость окружения. Старый абсолютный путь может сохраниться даже после правильного копирования файлов.
Нужно ли менять core/config/config.inc.php при переносе?
Если на новом сервере изменились абсолютные пути или реквизиты базы данных — да, соответствующие параметры конфигурации необходимо привести к новой среде. Официальный гайд MODX отдельно включает этот шаг в процедуру переноса.
Нужно ли сразу обновлять MODX после переноса?
Нет. Перенос и обновление разумно рассматривать как отдельные операции. Для старого проекта сначала полезно добиться стабильной работы на новом сервере, а затем отдельно оценить обновление MODX и Extras.
Что делать со старым сервером после переноса?
Не удалять его сразу после переключения. Сначала нужно убедиться, что новый production корректно обслуживает страницы, формы, Manager, интеграции и другие критичные сценарии.
Нужен перенос сайта на MODX?
Поможем перенести существующий сайт на MODX на новый сервер или хостинг и проверить пути, базу, Manager, формы и интеграции.
↑ К оглавлению