Как мы разворачиваем MODX 3.2 для клиентов: сервер, установка, базовая настройка — пошаговый регламент ITfresh

Требования MODX к хостингу: почему по меркам 2026 года они смешные

Меня зовут Евгений Семёнов, я технический директор ITfresh. Мы обслуживаем московские компании до пятидесяти рабочих мест, держим собственные серверы в дата-центре МТС и за последние годы развернули не один десяток сайтов на MODX Revolution. В этой статье — наш внутренний регламент установки MODX 3.2 целиком: от выбора хостинга до передачи сайта контент-менеджеру клиента. Никакой теории — только то, что мы реально делаем руками, с конфигами и командами.

Начнём с приятного: MODX — один из самых нетребовательных движков, с которыми мы работаем. Официально ветке 3.x нужен PHP от 8.1 до 8.5, база MySQL или MariaDB и 256 МБ памяти на процесс PHP. Для сравнения: типовой сайт на WordPress с конструктором страниц и двадцатью плагинами у нас в мониторинге стабильно съедает больше, а какой-нибудь самописный «фреймворк от студии» — непредсказуемо больше. Реальный расход памяти MODX на проде, по нашим графикам, — 40–90 МБ на запрос для обычного корпоративного сайта; в лимит 256 МБ упираются только тяжёлые импорты каталога.

Shared или VPS: как мы выбираем площадку клиенту

Честный факт, который редко озвучивают на пресейле: примерно 80% наших клиентских сайтов на MODX прекрасно живут на самых недорогих тарифах. Движку без плагинного балласта попросту нечем нагрузить сервер. Критерий выбора у нас простой и измеримый — посещаемость и характер нагрузки:

Если сайт — корпоративная визитка или каталог услуг до десяти тысяч посетителей в день, мы спокойно ставим его на shared за триста рублей и не изображаем бурную деятельность с «выделенным сервером». Если же есть магазин, обмен с 1С, формы с файлами и рекламный трафик — берём VPS или размещаем на своих мощностях в ЦОД МТС, где у нас полный контроль над стеком. Отдельная оговорка: ветка MODX 2.x закончила жизненный цикл — последним релизом стала 2.8.7, и новые проекты на ней начинать нельзя ни при каких скидках от подрядчика. Только 3.x, на сегодня — 3.2.

Наш эталонный стек: nginx + PHP-FPM + MariaDB

Когда площадка — наша (VPS или сервер в ЦОД), мы всегда собираем одну и ту же связку: nginx, PHP-FPM ветки 8.3 или 8.5 и MariaDB. MODX 3.2, вышедший 17 февраля 2026 года, официально поддерживает PHP 8.5 — на новые проекты мы ставим именно его, на переносимые со старых хостингов иногда оставляем 8.3 как «проверенную середину». Apache не используем: связка nginx + FPM при том же железе держит заметно больше одновременных запросов, а все нужные MODX правила переписывания адресов укладываются в пять строк конфига.

Конфиг nginx под friendly URLs

MODX из коробки открывает страницы по адресам вида index.php?id=15, а «человеческие» адреса включаются связкой: системная настройка friendly URLs плюс правило переписывания на веб-сервере. Вот наш боевой шаблон виртуального хоста — с отдачей статики мимо PHP и закрытым каталогом ядра:

server {
    listen 443 ssl http2;
    server_name client-site.ru;
    root /var/www/client-site/www;
    index index.php;

    gzip on;
    gzip_types text/css application/javascript image/svg+xml;

    # статика — напрямую, без PHP
    location ~* \.(jpe?g|png|webp|svg|gif|ico|css|js|woff2?)$ {
        expires 30d;
        access_log off;
        try_files $uri =404;
    }

    # ядро и служебные каталоги наружу не отдаём
    location ~ ^/(core|config\.core\.php) { deny all; }

    # friendly URLs MODX
    location / {
        try_files $uri $uri/ @modx;
    }
    location @modx {
        rewrite ^/(.*)$ /index.php?q=$1 last;
    }

    location ~ \.php$ {
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_pass unix:/run/php/client-site.sock;
    }
}

Два принципиальных момента. Первый — блок статики стоит выше остальных: картинки, стили и шрифты nginx отдаёт сам, PHP при этом даже не просыпается, и это главная причина, почему MODX-сайты у нас «летают» на слабом железе. Второй — каталог core закрыт наглухо: в нём лежат кэш, пакеты и конфигурация, снаружи ему делать нечего.

Пул PHP-FPM и opcache: параметры по умолчанию

Каждому сайту — отдельный пул FPM под отдельным системным пользователем: сайты не видят файлы друг друга, а лимиты считаются честно. Вот значения, которые мы ставим на типовой корпоративный сайт (VPS с 2 ГБ памяти):

; /etc/php/8.5/fpm/pool.d/client-site.conf
[client-site]
user = client-site
group = client-site
listen = /run/php/client-site.sock
listen.owner = www-data
listen.group = www-data
pm = dynamic
pm.max_children = 12
pm.start_servers = 3
pm.min_spare_servers = 2
pm.max_spare_servers = 5
pm.max_requests = 500
php_admin_value[memory_limit] = 256M

; /etc/php/8.5/fpm/conf.d/90-opcache.ini
opcache.enable = 1
opcache.memory_consumption = 192
opcache.max_accelerated_files = 20000
opcache.validate_timestamps = 1
opcache.revalidate_freq = 60

pm.max_children считаем от памяти: 2 ГБ минус базовые сервисы и MariaDB — остаётся около 1,2 ГБ, делим на средний пик процесса ~90 МБ, получаем 12 воркеров с запасом. opcache с проверкой раз в 60 секунд — компромисс: код после правок подхватывается за минуту, а в остальное время исполняется из памяти. В MariaDB на старте трогаем единственный параметр — innodb_buffer_pool_size поднимаем до 256–512 МБ; остального типовому сайту хватает по умолчанию.

Установка MODX Revolution 3.2 по шагам

Сама установка занимает у инженера минут пятнадцать, если сервер подготовлен. Дистрибутив забираем только с официального сайта modx.com — никаких «сборок с готовыми шаблонами» с форумов, это классический способ получить закладку в подарок. Распаковываем архив в корень сайта и первым делом наводим порядок с правами.

Права на каталоги: почему никогда не 777

MODX должен уметь писать в четыре места: кэш, каталог пакетов, каталог выгрузок и файлы компонентов в assets. Всё остальное открыто только на чтение. Наш стандартный блок команд:

cd /var/www/client-site/www
chown -R client-site:client-site .
find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;
# каталоги, куда MODX реально пишет:
chmod -R 775 core/cache core/packages core/export assets/components
chmod 644 config.core.php core/config/config.inc.php

Про chmod 777 скажу жёстко, потому что вижу его на каждом втором сайте, который к нам приезжает «после другого подрядчика»: права 777 означают, что писать в каталог может любой процесс на сервере. На shared-хостинге без изоляции это прямая дорога к заражению через соседний взломанный сайт. Правильная схема — 755/644 плюс 775 на каталоги записи, при условии что PHP-FPM работает от владельца файлов или его группы. Если хостер запускает PHP от имени владельца (так делают почти все современные shared-панели), достаточно и 755.

Веб-инсталлятор и база данных

Дальше открываем /setup/ в браузере. База данных — создаём заранее, обязательно в кодировке utf8mb4 с collation utf8mb4_unicode_ci: это корректные эмодзи, все языки и отсутствие сюрпризов при переносах. Пользователя БД делаем отдельного, с правами только на эту базу. В инсталляторе заполняем подключение, создаём администратора — логин не «admin», пароль из генератора — и проходим проверку окружения: инсталлятор сам покажет, чего не хватает.

После финального экрана каталог setup/ удаляем сразу же, не «потом»: инсталлятор, забытый на боевом сайте, — находка для сканера уязвимостей.

Типовые грабли установки

Три проблемы, которые закрывают 90% обращений «инсталлятор не проходит»:

• Нет расширений PHP. MODX нужны pdo_mysql, gd (или imagick), zip, curl, mbstring, simplexml. Диагностика: php -m | grep -iE 'pdo_mysql|gd|zip'. На Debian/Ubuntu лечится одной командой apt install php8.5-mysql php8.5-gd php8.5-zip.
• Низкий memory_limit. На дешёвых тарифах встречается 128 МБ — установка проходит, а установка пакетов потом падает молча. Проверяем заранее и поднимаем до 256 МБ.
• Права на config. Инсталлятору нужно один раз записать core/config/config.inc.php; если файл создан руками от root — получите ошибку записи. После установки права возвращаются на 644.

Первые 30 минут после установки: чек-лист безопасности и удобства

Свежеустановленный MODX — это ещё не сайт, готовый жить в интернете. У нас есть получасовой регламент, который инженер проходит сразу после удаления инсталлятора, до какой-либо вёрстки.

Переносим админку с /manager

Адрес панели управления по умолчанию знают все боты интернета, и логи любого MODX-сайта полны перебором паролей на /manager/. Мы всегда переименовываем каталог менеджера во что-нибудь неочевидное (mgr-fresh24, свой вариант на каждый проект) и правим два конфига: константу MODX_MANAGER_URL в core/config/config.inc.php и файл manager/config.core.php внутри переименованного каталога. После этого /manager/ отдаёт 404, а поток автоматических попыток входа падает до нуля — проверено логами fail2ban на десятках сайтов. Дополнительно на своих серверах закрываем новый адрес на уровне nginx списком IP офиса и VPN.

Включаем русский язык — он уже в ядре

Приятная особенность MODX: русский лексикон входит в ядро, никаких языковых пакетов ставить не нужно. В системных настройках меняем manager_language и cultureKey на ru — и весь менеджер, включая системные сообщения, становится русским. Контент-менеджер клиента с первого дня работает в родном интерфейсе, что сильно упрощает обучение в конце проекта.

Базовые системные настройки

Дальше проходим по короткому списку настроек, который у нас оформлен внутренним чек-листом:

• friendly_urls = Да, use_alias_path = Да — человекочитаемые адреса с учётом вложенности разделов (правило в nginx уже стоит из раздела выше);
• container_suffix — пустой или «/», чтобы разделы открывались без «.html»;
• сессии — время жизни авторизации менеджера сокращаем со стандартного до рабочего дня;
• кэш — убеждаемся, что включён стандартный файловый кэш; на старте его достаточно всем;
• site_status — сайт держим выключенным (заглушка) до момента приёмки, чтобы поисковики не съели черновой контент;
• robots и sitemap — закрываем индексацию на время разработки, а карту сайта генерируем компонентом уже перед запуском.

Отдельной строкой — резервная копия «нулевого дня»: сразу после базовой настройки снимаем дамп базы и архив файлов. Это точка, к которой можно откатиться, если в процессе вёрстки что-то пойдёт не так, и она не раз экономила нам часы работы.

Стартовый набор компонентов: наш «джентльменский набор» вместо плагинного зоопарка

Философия MODX противоположна вордпрессовской: не «поставим плагин на всё», а «поставим только то, что решает задачу проекта». На типовом нашем сайте стоит шесть-восемь дополнений — против 25+ плагинов у среднего WordPress, который к нам приезжает на аудит. Каждое дополнение в списке ниже обосновано конкретной задачей, ставится из официальных каталогов extras.modx.com и modstore.pro и живёт под присмотром активных разработчиков.

Если проекту нужен магазин, к набору добавляется miniShop2 — зрелое решение для каталога и корзины; актуальная ветка 4.4.x полноценно работает на MODX 3. Но добавляем его именно тогда, когда есть товары и продажи, а не «на вырост»: неиспользуемый магазинный функционал — это лишний код, лишние обновления и лишние вопросы на аудите безопасности.

Число шесть-восемь — не догма, а следствие принципа: перед установкой любого дополнения инженер обязан ответить, какую задачу клиента оно решает и что будет, если его не ставить. Не смог ответить — не ставим. Именно поэтому наши MODX-сайты спустя три года выглядят в панели так же опрятно, как в день сдачи, и обновляются за минуты, а не за вечер с молитвой.

Структура шаблонов под клиентский макет

Установка и компоненты — это фундамент; дальше начинается то, ради чего клиент вообще выбрал MODX: уникальный макет, свёрстанный пиксель в пиксель. Расскажу, как мы режем дизайн, на примере реального сайта услуг — медицинского центра с разделами «Услуги», «Врачи» и «Цены».

Шаблоны и чанки: минимум сущностей

Правило простое: шаблонов — по числу принципиально разных типов страниц, а не по числу страниц. У медцентра их вышло пять: главная, текстовая страница, список услуг, карточка услуги, карточка врача. Всё повторяющееся — шапка, подвал, хлебные крошки, блок «записаться на приём» — вынесено в чанки и подключается одной строкой [[$header]]. Когда клиент через полгода попросил добавить телефон филиала в шапку, правка заняла одну минуту в одном чанке — и применилась на всех двухстах страницах.

TV-параметры для нестандартных полей

У страницы MODX из коробки есть заголовок, описание и текст. Всё специфичное для проекта делается TV-параметрами — дополнительными полями, которые привязываются к шаблону. У карточки врача это стаж, специализация, фото и график приёма; у услуги — цена, длительность и флажок «акция». В MODX 3.x работа с TV в менеджере стала заметно удобнее, и контент-менеджер видит их как обычные аккуратные поля формы, а не как «страшные настройки для программиста». Важный принцип: тип поля выбираем строгий — число для цены, дата для даты, список для категорий. Это защищает от творчества вида «от 1500 руб. (уточняйте!!)» в поле, из которого потом надо считать сортировку.

pdoResources вместо самописных циклов

Все списки — услуги в разделе, врачи на главной, последние новости — выводим сниппетом pdoResources из состава pdoTools, а не самописными выборками. Причины прагматичные: он быстрый (одна оптимизированная выборка вместо запроса на каждый ресурс), гибкий (сортировки, фильтры по TV, лимиты — параметрами), и его знает любой MODX-разработчик, который придёт на проект после нас. Типовой вывод раздела услуг выглядит так: [[!pdoResources? &parents=`12` &tpl=`serviceCard` &includeTVs=`price,duration` &sortby=`menuindex`]] — карточка описана чанком, данные подтягиваются с TV-полями, и никакого PHP в шаблоне нет вообще. Самописный код в проекте появляется только там, где готовых средств действительно не хватает, и оформляется отдельным сниппетом с комментариями — это вопрос передаваемости проекта, о которой дальше.

Передача сайта клиенту: обучение контент-менеджера за одну встречу

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

Программа обучения

Встреча идёт по сценарию «показали — повторил сам»:

1. Дерево ресурсов. Объясняем главную метафору: сайт — это папки и документы, как на диске. Раздел — папка, страница — документ. Пять минут, и структура перестаёт пугать.
2. Правка существующей страницы. Открыли, поменяли текст в визуальном редакторе, вставили фото, сохранили, посмотрели на сайте. Менеджер повторяет на другой странице сам.
3. Создание новой страницы. Правой кнопкой на разделе — «создать дочерний ресурс», заполнить поля, включая TV (цену, фото), опубликовать.
4. Черновики и снятие с публикации. Как подготовить страницу заранее и включить в нужный день.

Ограничение прав: менеджер не может сломать сайт

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

Памятка-шпаргалка

После встречи клиент получает PDF на две страницы: адрес входа в панель (тот самый нестандартный, из раздела про безопасность), пошаговые скриншоты типовых операций и короткий список «что делать, если»: страница не появилась на сайте — проверьте галочку публикации; поменяли текст, а на сайте старый — подождите минуту или нажмите «очистить кэш»; что-то пошло не так — не чинить самостоятельно, написать нам. Смешно, но именно эта шпаргалка сокращает поток обращений в поддержку в разы: людям нужен не хелпдеск, а уверенность.

Что дальше: договор поддержки и чек-лист готовности к продакшену

Запуск — это середина жизни проекта, а не финал. После сдачи сайт переходит на наш договор сопровождения, и вот что мы в него включаем для MODX-проектов: регулярные обновления ядра и компонентов (с проверкой на копии, а не на бою), ежедневные бэкапы базы и файлов с хранением вне площадки, мониторинг доступности и времени ответа в нашей системе наблюдения, продление домена и сертификатов, а также несколько часов работ контент-инженера в месяц — мелкие правки без счетов за каждый чих. Подробно про эксплуатацию — бэкапы, обновления, защиту — я написал отдельную статью, ссылка в конце.

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

1. MODX обновлён до актуального релиза ветки 3.2, компоненты — до совместимых версий.
2. Каталог setup/ удалён, менеджер перенесён с /manager на нестандартный адрес.
3. Права на файлы 644/755, на каталоги записи — 775; нигде нет 777.
4. HTTPS включён, сертификат автопродлевается, HTTP редиректит на HTTPS.
5. Friendly URLs работают, старые адреса (если был перенос) отдают 301-редиректы.
6. Бэкап настроен и — главное — проверен тестовым восстановлением на другой машине.
7. Формы отправляются, письма доходят (проверены SPF/DKIM домена), антиспам-хук стоит.
8. Учётка администратора переименована, пароли в сейфе, у менеджера — ограниченные права.
9. Кэш включён, статика отдаётся с заголовками кэширования, страницы открываются быстрее двух секунд на мобильном.
10. Метатеги заполнены, sitemap генерируется, robots.txt открывает индексацию.
11. Ошибочная страница 404 оформлена и возвращает корректный код ответа.
12. Сайт добавлен в мониторинг, алерты приходят инженеру, а не в никуда.

Двенадцать галочек — и только тогда site_status переключается в «работает». Такой регламент скучен ровно до первого сэкономленного инцидента: сайт, поставленный по чек-листу, годами не напоминает о себе ничем, кроме заявок от клиентов. Собственно, в этом и была цель.