Перенос CMS — не первый шаг

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

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

ОбластьЧто фиксируем
MODX/PHP/DBверсии и совместимость
Extrasверсия, источник, критичность
Pluginsсобытия и побочные эффекты
Snippetsкеширование, SQL/API, качество кода
Templates/Chunksдубли, hardcode, наследование
Custom componentsnamespace, processors, models, migrations
SEOURL, redirects, canonical, sitemap
ИнтеграцииCRM, оплаты, почта, API

Быстро посмотреть журнал MODX

BASH
tail -n 120 /path/to/site/core/cache/logs/error.log

find /path/to/site -type f -name '*.php' -mtime -30   -printf '%TY-%Tm-%Td %TH:%TM %p\n' 2>/dev/null   | sort -r | head -n 100

Когда доработка обычно рациональнее миграции

  • ядро MODX и база работают стабильно;
  • основной функционал реализован через поддерживаемые Extras или понятный custom code;
  • проблемы локальны: дизайн, скорость, интеграция, checkout, SEO;
  • URL и контент уже дают поисковый трафик;
  • нет критичной зависимости от неподдерживаемой инфраструктуры.

Когда миграцию стоит считать отдельным вариантом

Если проект невозможно обновлять, ключевая бизнес-логика размазана по core, отсутствуют исходники и backup, а каждая правка ломает соседние функции, стоимость постоянного ремонта может превысить перенос. Это определяется аудитом, а не возрастом CMS.

Как принимать чужой MODX-проект в работу

  1. снять backup файлов и БД;
  2. зафиксировать версии и системные настройки;
  3. собрать карту Extras/custom components;
  4. проверить error.log и проблемные processors;
  5. создать staging;
  6. выполнять изменения небольшими независимыми этапами с rollback.

Связанные инструкции