«Поставити WordPress» вміє й хостинг у два кліки. Але коли хочеться розуміти, що там під капотом, і зробити по-дорослому - то це Apache, який віддає PHP у PHP-FPM (а не старий mod_php), окрема база на MariaDB, і Redis як object cache, щоб сторінки не збирались щоразу з нуля. Зберемо все це руками, крок за кроком - так, щоб потім ти міг це повторити з заплющеними очима.
А як цей самий стек запакувати в Docker або перенести з Apache на nginx - показую окремими нотатками (посилання в кінці). Спочатку варто розуміти, що з чого складається.
Що потрібно зробити?#
Підняти повноцінний WordPress-стек на свіжому Debian: вебсервер Apache з PHP-FPM, базу MariaDB з окремим користувачем, Redis для кешу об’єктів, і сам WordPress - з правильними конфігами й правами.
З чим працюю?#
| |
Debian 13 (PHP тут - версії 8.4). Усе роблю від root; де в тебе інша версія PHP - підстав свою (подивитись: ls /etc/php/).
Далі ті самі кроки по порядку, з готовими конфігами - копіюй і став у себе.
Крок 1. Apache і PHP-FPM#
Ставимо вебсервер, PHP-FPM і набір розширень, які WordPress реально використовує (робота з БД, картинками, текстом, архівами):
| |
mod_php? PHP-FPM - це окремий пул процесів, який не прив’язаний до Apache. Він ефективніший під навантаженням, працює з продуктивним MPM event, і його можна тюнити окремо від вебсервера. Це стандарт де-факто.Вмикаємо модулі Apache, через які він віддаватиме PHP у FPM, і підключаємо конфіг FPM:
| |
Крок 2. Віртуальний хост#
Тепер опишемо сам сайт. Відкриваємо новий конфіг у редакторі:
| |
І вклеюємо:
| |
Ключовий рядок тут - SetHandler "proxy:unix:/run/php/php8.4-fpm.sock|fcgi://localhost": саме він відправляє всі .php у сокет PHP-FPM. AllowOverride All потрібен, щоб працювали «гарні посилання» WordPress через .htaccess.
Вимикаємо дефолтний сайт, вмикаємо наш:
| |
Крок 3. PHP під WordPress#
Дефолтні ліміти PHP для WordPress замалі - картинку не завантажиш. Кладемо свій drop-in, щоб не чіпати основний php.ini:
| |
| |
Перевіряємо конфіг Apache і перечитуємо обидва сервіси:
| |
Крок 4. База даних MariaDB#
WordPress-у потрібна база і окремий користувач - не root. Кодування - utf8mb4 (повноцінний Unicode, разом з емодзі):
| |
wpuser лише на базу wordpress.*, а не на все (*.*). Якщо колись зламають сайт - зловмисник не дотягнеться до інших баз.Крок 5. Redis#
Redis уже встановлено разом з усіма пакетами - лишається переконатись, що він запущений і в автозапуску:
| |
Розширення php-redis ми теж поставили на першому кроці - саме воно дасть WordPress говорити з Redis.
Крок 6. WordPress#
Качати архів і колупати wp-config руками - вчорашній день. Беремо WP-CLI:
| |
Качаємо ядро, створюємо конфіг і ставимо сайт - однією серією команд:
| |
Крок 7. Вмикаємо Redis object cache#
Тепер найсмачніше - підключаємо Redis як кеш об’єктів. Два рядки в конфіг (WP-CLI допише їх сам), плагін-дропін, і вмикаємо:
| |
Нарешті віддаємо файли вебсерверу - усе має належати www-data:
| |
Перевірка#
Переконуємось, що кеш реально підключився:
| |
| |
Connected + Drop-in: Valid - Redis працює, і WordPress складає сторінки з кешу, а не ганяє базу щоразу. А ось і сам сайт у браузері - живий, з нашого стенду:

А як це в Docker?#
Той самий стек - Apache, PHP, MariaDB, Redis - можна підняти кількома рядками docker compose, не торкаючись системи. Як саме - у окремому пості: WordPress у Docker. Коли розумієш, що з чого складається вручну, контейнери стають не магією, а просто зручною упаковкою.
А якщо замість Apache - nginx?#
Вебсервер тут - змінна деталь. Той самий WordPress можна віддавати не Apache, а nginx: база, PHP-FPM і Redis лишаються ті самі, міняється один server-блок замість віртуального хоста. Що саме відрізняється - try_files замість .htaccess і fastcgi_pass замість SetHandler - коротко розібрав окремо: WordPress на nginx.
Весь стек - це Apache з PHP-FPM, окрема база на MariaDB і Redis для кешу. Виглядає як багато кроків, та кожен - одна-дві команди. А на виході - WordPress, зібраний по-дорослому, який не соромно й у прод.


