Развёртывание Joomla 6: регламент ITfresh

Что нужно от хостинга: взгляд аутсорсера

Меня зовут Евгений Семёнов, я технический директор ITfresh. Мы обслуживаем компании до 50 рабочих мест в Москве, держим собственные серверы в дата-центре МТС и за последние годы поставили клиентам не один десяток корпоративных сайтов на Joomla. Когда развёртываний становится много, появляется регламент: документ, по которому любой наш инженер собирает сайт одинаково — от выбора хостинга до подписи клиента в чек-листе сдачи. Эту внутреннюю бумагу я и разворачиваю здесь в статью, с реальными конфигами и граблями, на которые мы уже наступили за вас.

Сначала о версиях, чтобы дальше говорить конкретно. На август 2026 года актуальная ветка — Joomla 6.1.2: security-релиз вышел 7 июля 2026 года одновременно с 5.4.7 LTS и закрыл 12 проблем. Сама линейка 6.1 «Nyota» стала стабильной 14 апреля 2026 года, а 6.2 ожидается примерно 13 октября 2026-го. Новые сайты мы ставим только на шестёрку — у неё впереди весь жизненный цикл, а «пятёрка» уже доживает свой LTS.

Теперь требования. Joomla 6 хочет PHP 8.3.0 или новее (рекомендуется 8.4+), базу MySQL 8.0.13+ или MariaDB 10.4.0+ (рекомендуется 12.0+). Из PHP-модулей обязательны json, simplexml, dom, zlib, gd и mysqlnd либо pdo_mysql; mbstring формально опционален, но мы считаем его обязательным — без него часть строковых операций с кириллицей работает через медленный фолбэк.

Наш эталонный блок php.ini, который уезжает на каждый новый сервер:

; /etc/php/8.4/fpm/conf.d/90-itfresh-joomla.ini
memory_limit = 256M
upload_max_filesize = 64M
post_max_size = 64M
max_execution_time = 120
max_input_vars = 5000
date.timezone = Europe/Moscow

opcache.enable = 1
opcache.memory_consumption = 192
opcache.max_accelerated_files = 20000
opcache.validate_timestamps = 1
opcache.revalidate_freq = 60

Где всё это хостить. Честный ответ: типовому корпоративному сайту хватит shared-хостинга за 300–500 рублей в месяц — Joomla 6 на нём работает. Но клиентам на сопровождении мы почти всегда берём VPS от 2 vCPU и 2 ГБ памяти: там мы управляем версией PHP, OPcache и бэкапами сами, а не ждём ответа поддержки хостера. Разница в 500–800 рублей в месяц окупается первым же инцидентом.

Хостинг мы проверяем до оплаты года вперёд. Порядок простой: берём тестовый период, заливаем одностраничный скрипт с phpinfo(), смотрим версию PHP, список модулей и лимиты, затем убеждаемся, что панель позволяет переключать версии PHP и включать OPcache. Если хостер держит клиентов на PHP 8.1 «потому что стабильно» — уходим сразу: Joomla 6 там просто не запустится.

И отдельный пункт регламента для юрлиц: хостинг берём российский. Формы обратной связи собирают персональные данные, а 152-ФЗ требует, чтобы базы с данными граждан РФ физически находились на территории страны. Плюс практика: зарубежные площадки нестабильно доступны и оплачиваются с приключениями. Наши клиентские сайты живут либо на наших серверах в ЦОД МТС, либо у крупных российских хостеров.

Установка: веб-инсталлятор против CLI

Классика: распаковали и прошли инсталлятор

Стандартный путь знаком каждому, кто хоть раз ставил CMS: скачали дистрибутив с официального сайта, распаковали в корень сайта, открыли домен в браузере — и попали в веб-инсталлятор. В Joomla 6 он состоит из трёх экранов: имя сайта и данные суперпользователя, подключение к базе, финал. Важная мелочь, которую ценят клиенты: русский язык выбирается прямо на первом шаге инсталлятора — сам процесс установки сразу идёт по-русски, доустанавливать для этого ничего не надо (языковой пакет для сайта — отдельная история, о ней ниже).

Базу и пользователя к ней создаём заранее и по правилу «одна база — один пользователь — минимум прав»:

CREATE DATABASE client_j6
  CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'client_j6'@'localhost' IDENTIFIED BY 'длинный-пароль';
GRANT ALL PRIVILEGES ON client_j6.* TO 'client_j6'@'localhost';
FLUSH PRIVILEGES;

Автоматизация: установка одной командой из консоли

Когда сайтов не один и не два, кликать по инсталлятору скучно и чревато опечатками. Начиная с ветки 4.3 у Joomla есть консольная установка — php installation/joomla.php install, и в нашем регламенте типовое развёртывание делается именно ею:

cd /var/www/client/public_html
php installation/joomla.php install \
  --site-name="ООО Пример — корпоративный сайт" \
  --admin-user="Администратор" \
  --admin-username="itf_supervisor" \
  --admin-password="$(openssl rand -base64 18)" \
  --admin-email="webmaster@client.ru" \
  --db-type=mysqli \
  --db-host=localhost \
  --db-name=client_j6 \
  --db-user=client_j6 \
  --db-pass="********" \
  --db-prefix="k9fp2_"

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

Сразу после установки: три обязательных действия

• Удалить каталог installation/. Веб-инсталлятор предлагает это кнопкой, при CLI-установке удаляем руками: rm -rf installation/. Оставленный каталог — классическая дыра, по которой сайт можно переустановить поверх.
• Нестандартный префикс таблиц. Мы всегда задаём свой префикс (в примере выше k9fp2_) вместо предлагаемого — примитивные SQL-инъекции из сканеров бьют по типовым именам таблиц.
• Пройтись по плагинам. Отключаем то, что клиенту не нужно: авторизацию через внешние сервисы, ненужные способы входа, демо-модули шаблона. Каждый включённый плагин — это и код в рантайме, и поверхность атаки.

Русификация и настройка под редакторов

Свежеустановленная Joomla говорит по-английски, и лечится это штатно за две минуты: System → Install → Languages, в списке находим Russian, жмём Install — пакет прилетает с официального сервера расширений. Дальше тонкость, которую я всегда показываю клиентам: язык сайта и язык админки в Joomla назначаются раздельно. В System → Manage → Languages русский включаем как язык по умолчанию для Site, а для Administrator решаем по ситуации: редакторам ставим русский, а себе инженеры часто оставляют английский — по нему проще гуглить сообщения об ошибках.

Следом настраиваем редактор под контент-менеджеров. Штатный TinyMCE в Joomla имеет три набора кнопок (Set 0–2), которые привязываются к группам пользователей. Редакторам мы отдаём урезанный набор: заголовки, списки, ссылки, картинки, таблицы. Убираем кнопки исходного кода, вставки медиа по URL и смены шрифтов/цветов — иначе через месяц на сайте будет зоопарк из Comic Sans и вставленного из Word мусора. Это делается в настройках плагина Editor — TinyMCE перетаскиванием кнопок между наборами, без единой строки кода.

Остальная базовая гигиена из регламента:

• Часовой пояс — Europe/Moscow в глобальной конфигурации, иначе даты публикации материалов «уезжают» относительно ожиданий редакции;
• метаданные сайта — описание сайта заполняем, «автора» в метатегах отключаем;
• robots — до запуска сайт держим в noindex, при сдаче переключаем на index, follow и проверяем, что в robots.txt не остался тестовый Disallow: /;
• формат ввода — редакторам включаем «Сохранять историю версий» на материалах: откат кривой правки занимает секунды вместо восстановления из бэкапа.

Веб-сервер и ЧПУ

Apache: SEF и mod_rewrite

Человекопонятные адреса включаются в два движения. В глобальной конфигурации включаем Search Engine Friendly URLs и Use URL Rewriting, а в корне сайта переименовываем поставляемый в дистрибутиве htaccess.txt в .htaccess — в нём уже лежат готовые правила mod_rewrite. Если пропустить переименование, включённый rewriting даст 404 на всех страницах кроме главной — это, наверное, самый частый вопрос новичков про Joomla вообще.

В тот же .htaccess мы дописываем несколько защитных директив: запрет листинга каталогов, запрет прямого доступа к configuration.php и XML-манифестам, базовые заголовки безопасности:

Options -Indexes
<FilesMatch "^(configuration\.php|.*\.xml)$">
  Require all denied
</FilesMatch>
Header always set X-Content-Type-Options "nosniff"
Header always set Referrer-Policy "strict-origin-when-cross-origin"

nginx: рабочий server-блок

На своих VPS мы ставим nginx + PHP-FPM: он экономнее по памяти и предсказуемее под нагрузкой. .htaccess в nginx не работает, поэтому вся логика — в server-блоке. Вот выжимка нашего боевого конфига:

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

    ssl_certificate     /etc/letsencrypt/live/client.ru/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/client.ru/privkey.pem;

    # SEF: всё, чего нет на диске, — в index.php
    location / {
        try_files $uri $uri/ /index.php?$args;
    }

    # Запрет исполнения PHP в каталогах загрузок и кэша
    location ~* ^/(images|cache|media|tmp|logs)/.*\.php$ {
        return 403;
    }

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

    location ~* \.(css|js|jpe?g|png|webp|svg|ico|woff2?)$ {
        expires 30d;
        add_header Cache-Control "public";
    }

    location ~ /\.(?!well-known) { deny all; }
}

Две строки здесь важнее остальных. try_files делает ЧПУ без всяких rewrite-правил. А location с запретом PHP в /images и /cache — страховка от самого популярного сценария взлома CMS: злоумышленник заливает шелл под видом картинки через дырявое расширение, и без этого запрета сервер его исполнит.

HTTPS: Let's Encrypt и force_ssl

Сертификат получаем certbot'ом (certbot certonly --webroot -w /var/www/client/public_html -d client.ru -d www.client.ru), продление он вешает в systemd-таймер сам. После этого принудительный HTTPS включаем на стороне Joomla — в configuration.php параметр public $force_ssl = 2; (2 — весь сайт, 1 — только админка). Плюс 301-редирект с 80-го порта на уровне nginx, чтобы поисковики склеили версии.

ACL и структура контента: не «все под одним админом»

Самая недооценённая часть развёртывания. Технически сайт работает и с одной учёткой Super User на всех, но через полгода вы не ответите на вопрос «кто удалил страницу с реквизитами». Поэтому структуру контента и права мы закладываем при сдаче, по оргструктуре клиента.

Категории материалов повторяют зоны ответственности отделов: «Новости» ведёт маркетинг, «Вакансии» — HR, «Продукция» — продуктовый отдел. Под каждую зону создаётся группа пользователей, унаследованная от штатной Author или Editor, и через Permissions на категории ей выдаётся право создавать и править материалы только в своей ветке. Наследование прав в Joomla идёт сверху вниз (глобальная конфигурация → компонент → категория → материал), поэтому правило у нас такое: на верхних уровнях всё Inherited, явные Allow — точечно на категориях. Тогда картина прав читается за минуту, а не разгадывается как ребус.

В Joomla 6.1 появился визуальный редактор workflow — и для компаний с согласованием публикаций это находка. Мы собираем клиенту простую цепочку: редактор пишет материал в статусе «черновик», руководитель отдела переводит его в «на согласовании», публикует только маркетинг или пресс-служба. Раньше такое городили на сторонних расширениях, теперь схема переходов рисуется мышкой в ядре.

Почта и формы без Google

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

Первое: никакого PHP mail(). В глобальной конфигурации переключаем отправку на SMTP с авторизацией через нормальный почтовый сервер: для клиентов на нашем сопровождении это наши почтовые серверы, у остальных — Яндекс 360 или VK WorkSpace. Порт 465 (SSL) либо 587 (STARTTLS), отправитель — реальный ящик вида site@client.ru, который существует и мониторится.

Второе: DNS. В SPF-запись домена добавляем сервер, с которого шлёт сайт, подписываем исходящее DKIM и заводим DMARC хотя бы в режиме p=none. Без этого письма с формы стабильно падают в спам у половины получателей, и клиент уверен, что «сайт сломан». Проверяем доставку не «на глазок», а отправкой тестовой заявки на ящики в двух-трёх разных почтовых сервисах и просмотром заголовков: SPF pass, DKIM pass.

Третье: защита форм. Годами стандартом была reCAPTCHA, но для российских сайтов это теперь плохой вариант: скрипты Google грузятся через раз, а персональные данные посетителей утекают на внешний сервис. В Joomla 6.1 появилась встроенная proof-of-work капча без внешних API: браузер посетителя решает вычислительную задачку, человек не вводит ничего вообще. Включается в два шага — активируем плагин Captcha в менеджере плагинов и назначаем его капчей по умолчанию в глобальной конфигурации. По нашей практике на типовых корпоративных сайтах она отсеивает автоматический спам не хуже сторонних сервисов, при этом форма не зависит ни от одного внешнего домена.

Производительность из коробки

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

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

System — Page Cache. Отдельный плагин, который кэширует страницы целиком для гостей. Включаем его после окончания работ над сайтом (на этапе стройки он мешает видеть правки) — и это самый заметный по эффекту переключатель во всей CMS.

Gzip. Сжатие страниц включаем на уровне nginx (gzip on для text/html, css, js), а не галочкой в Joomla — серверу это дешевле.

Что это даёт в цифрах. Типовой корпоративный сайт на нашем VPS (2 vCPU, 2 ГБ, PHP 8.4 + OPcache, MariaDB): до настройки TTFB главной держался около 400–450 мс, после включения Conservative-кэша и Page Cache — 120–160 мс на прогретой странице; мобильный Lighthouse Performance у того же сайта вырос с 70–75 до низких 90-х. Это замеры по нашим внутренним прогонам, ваш результат зависит от шаблона и картинок, но порядок эффекта именно такой: штатный кэш ускоряет отдачу страниц в разы, бесплатно.

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

Чек-лист сдачи сайта клиенту

Финал регламента — сдача. Типовой корпоративный сайт без разработки дизайна мы разворачиваем за 2–4 рабочих дня: день на сервер и установку, день на структуру, права и почту, остальное — наполнение и полировка. Перед передачей инженер проходит по чек-листу из 20 пунктов, и пока все не закрыты, сайт клиенту не отдаётся.

1. Учётка суперпользователя переименована (не admin), пароль из генератора, включена 2FA.
2. Каталог installation/ удалён, тестовые и демо-материалы вычищены.
3. Префикс таблиц нестандартный, пользователь БД имеет права только на свою базу.
4. Права на файлы: 644/755, configuration.php — 444, владелец — пользователь FPM-пула.
5. PHP 8.4, OPcache включён и виден в phpinfo.
6. Версия Joomla — актуальная (сейчас 6.1.2), автопроверка обновлений работает.
7. HTTPS: сертификат валиден, автопродление проверено, force_ssl = 2, редирект с http и с www настроен.
8. SEF включён, .htaccess/nginx-конфиг на месте, нет дублей главной по разным адресам.
9. PHP запрещён к исполнению в /images, /cache, /tmp, /logs.
10. Русский язык установлен для сайта и админки, часовой пояс Europe/Moscow.
11. Структура категорий соответствует оргструктуре, группы и права проверены входом под тестовым редактором.
12. Workflow согласования публикаций настроен и прогнан на тестовом материале.
13. TinyMCE у редакторов — урезанный набор кнопок, версии материалов включены.
14. Почта через SMTP, SPF/DKIM/DMARC в DNS, тестовая заявка с формы дошла на два разных почтовых сервиса.
15. Встроенная капча включена на всех публичных формах.
16. Кэш Conservative + Page Cache включены, gzip на веб-сервере работает.
17. TTFB и Lighthouse замерены и зафиксированы в паспорте сайта.
18. robots.txt боевой, sitemap отдаётся, сайт открыт к индексации, счётчик аналитики стоит.
19. Бэкап настроен и восстановление проверено: ежедневный дамп базы + файлы, тестовое развёртывание копии выполнено на резервной площадке.
20. Мониторинг доступности и срока сертификата заведён в нашу систему, алерты приходят.

Передача доступов — только через менеджер паролей или зашифрованное хранилище, ни в коем случае не письмом «логин-пароль в одной строке». Клиент получает: доступ к хостингу/VPS, свою учётку Super User, паспорта сайта с версиями и замерами, и памятку редактора на две страницы — как создать материал, как загрузить картинку, что делать нельзя. Памятка снимает 80% обращений первой недели.

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