Плагін WordPress вимагає новішої версії PHP: що робити, якщо хостинг застарілий

Ви натиснули «Оновити» для плагіна, а сайт відповів білим екраном, фатальною помилкою або класичним «Цей плагін вимагає PHP 8.1, у вас 7.4.» Автор плагіна не драматизує; він просто дотримується базової гігієни. Ваш хостинг же живе в минулому, наче з кнопковим телефоном і стійкою упевненістю в тому, що CD — найкраще.

Це одна з тих проблем, що здаються «WordPress-проблемами», але фактично це системна інженерія: сумісність рантайму, частота патчів, радіус впливу, відкат і те, що робити, коли ви не контролюєте середовище. Підходимо до цього як до задачі продакшену, а не хобі-сайту.

Швидкий план діагностики

Якщо у вас мало часу і сайт недоступний (або ви в один клік від цього), не «шарьтеся». Виконайте це по порядку. Це швидко виявляє вузьке місце і запобігає самостійно спричиненому простою.

1) Підтвердіть, який PHP фактично працює (не те, що каже контрольна панель)

• Перевірте в адмінці WordPress: Інструменти → Site Health → Info → Server.
• Або запустіть CLI-перевірку на хості. Див. розділ з командами нижче.

Рішення: Якщо PHP нижчий за мінімум плагіна, зупиніться і сплануйте шлях оновлення. Не намагайтеся примусово інсталювати плагін «так чи інакше». Саме так ви дізнаєтесь про фатальні помилки.

2) Визначте, звідки береться PHP (Apache mod_php vs PHP-FPM vs handler)

• Shared hosting: зазвичай є «PHP selector» на сайт, але іноді це глобальний дефолт.
• VPS: може бути кілька пулів PHP-FPM, кожен на різній версії.

Рішення: Якщо ви можете запустити кілька версій поруч, можна оновити WordPress спочатку, не ламавши інші додатки на машині.

3) Визначте радіус ураження: один сайт чи флот?

• Скільки віртуальних хостів вказують на той самий рантайм PHP?
• Чи є інші сайти застарілими і прив’язаними до PHP 7.4?

Рішення: Масові оновлення вимагають стейджингу і поетапного розгортання. Оновлення одного сайту може бути швидшим — але все одно потрібен план відкату.

4) Захопіть реальну помилку (логи, а не інтуїція)

• Лог налагодження WordPress для PHP-помилок.
• Логи веб-сервера та PHP-FPM для помилок при старті/конфігурації.

Рішення: Якщо помилка каже «requires PHP X», оновлення обов’язкове. Якщо помилка «undefined function» або «typed property», зазвичай це теж невідповідність версії.

5) Оберіть найменш ризикований спосіб, який відповідає вимозі

• Найкраще: оновити PHP (підтримувана версія) зі стейджингом та відкатом.
• Друге за якістю: ізолювати сайт в контейнері або окремій віртуальній машині.
• Останній шанс: зафіксувати стару версію плагіна (тимчасово) та запланувати міграцію.

Що насправді означає помилка (і чого вона не означає)

Коли плагін каже, що потрібен PHP 8.1+ (або 8.0+ тощо), це рідко «бо автор вас не любить». Зазвичай це одне з наступного:

• Мовні можливості: плагін використовує синтаксис, недоступний у старих PHP (union types, attributes, match expressions, enums, readonly properties).
• Ядро та розширення: він залежить від нових функцій або сучасних версій розширень, як-от cURL, OpenSSL, JSON, mbstring або intl.
• Позиція щодо безпеки: вони не хочуть підтримувати EOL-версії PHP з відомими вразливостями.
• Реальність матриці тестування: підтримка зворотної сумісності аж до PHP 7.4 (або старіше) множить вартість тестування. Вони обрізали хвіст.

Чого це не означає: що оновлення PHP автоматично зламає WordPress. Сам WordPress консервативний, але екосистема — ні. Розриви сумісності зазвичай викликають:

• Давні теми/плагіни, які покладалися на застарілу поведінку.
• Жорстко закодовані припущення про перетворення рядків/масивів.
• Старі бібліотеки, упаковані в плагіни (vendor folders), які конфліктують з сучасними очікуваннями PHP.

І так, іноді можна «змусити працювати» на старому PHP, редагуючи плагін. Але це також перетворює вас на нового мейнтейнера плагіна, якого ви не просили. Вітаю — ви взяли на утримання маленького цифрового вихованця, який кусається.

Цікаві факти та трохи історії (щоб хаос був зрозуміліший)

Розуміння, чому ви застрягли на старому PHP, допоможе вирішити, чи варто боротися з хостом, чи йти геть.

1. PHP 7.0 (2015) дав великий приріст продуктивності порівняно з PHP 5.x, тому багато хостів «нарешті оновилися», а потім знову заспокоїлися.
2. WordPress історично підтримував дуже старі PHP, щоб тримати довгий хвіст вебу в роботі. Це благородно, але переклало тиск на авторів плагінів.
3. PHP 8.0 (2020) впровадив JIT (just-in-time). JIT рідко змінює типові навантаження WordPress, але це сигнал, що PHP не «застиг».
4. Типізовані властивості та суворіша поведінка типів у PHP 7.4/8.x відсікають неакуратний код. Багато плагінів «що працювали роками» загинули при контакті з сучасним PHP.
5. Деякі shared host-и фіксують версії PHP, бо один застарілий модуль панелі управління, інтеграція білінгу чи кастомний Apache-хендлер залежить від цього. Це бізнесовий вибір, а не технічний закон.
6. Автооновлення WordPress змінило очікування: ядро і плагіни можуть рухатись швидше, тож відставання рантайму шкодить більше, ніж десять років тому.
7. Composer став мейнстримом, і багато плагінів тепер залежать від сучасних бібліотек, які явно відмовляються від старих PHP.
8. CloudLinux + CageFS поширилися на shared hosting для ізоляції користувачів, і часто вони поставляються з «PHP Selector», що може запускати кілька версій. Якщо ваш хост цього не має — це сигнал про їхню зрілість.
9. Аудити PCI та безпеки все частіше відмічають EOL-рантайми, незалежно від того, чи «вам здається нормально». Комплаєнс не зважає на відчуття.

Дерево рішень: оновити, ізолювати чи мігрувати

Надто відверто: якщо ваш хостинг не може запускати підтримувані версії PHP, ви платите за машину часу. Іноді це підходить для архівного сайту. Не підходить для всього, що приймає оплати, зберігає персональні дані або потребує оновлень плагінів.

Варіант A (переважний): Оновіть PHP там, де він є

Підходить коли:

• Ви контролюєте сервер (VPS/виділений/хмара).
• Ваш shared host дає селектор версії PHP по сайту.
• Ви можете робити стейджинг і відкат.

Добре виконане оновлення — нудне. Нудьга — це мета.

Варіант B: Ізолюйте сайт (контейнер/VM) без зміни хоста

Підходить коли:

• Ваш хост застарілий, але ви не можете перейти негайно (контракти, бюрократія або «той, хто має креденшіали, зараз у відпустці»).
• Ви можете поставити сайт за реверс-проксі і запускати сучасний PHP в іншому місці.

Це додає рухомих частин, але може безпечно купити час.

Варіант C: Міграція на хост, що не застряг у 2019

Підходить коли:

• Хост не може надати PHP 8.1/8.2/8.3 сьогодні.
• Ви не можете запускати кілька версій.
• Підтримка каже «просто використайте стару версію плагіна».

Якщо платформа не може патчити — їй не можна довіряти для продакшену. Це не різкість; це операційна реальність.

Короткий жарт №1: Запускати EOL PHP у продакшені — як зберігати резервні копії на тому ж диску: технічно вони є, духовно їх немає.

Практичні завдання з командами (і як вирішувати за результатами)

Нижче конкретні завдання, які можна виконати на VPS або будь-якому хості з shell-доступом. Кожне завдання містить: команду, приклад виводу, що це означає і яке рішення приймати далі. Якщо у вас shared hosting без SSH, робіть еквівалент через панель управління або звернення в підтримку — логіка та сама.

Завдання 1: Перевірте версію PHP, що використовує CLI (базова перевірка)

cr0x@server:~$ php -v
PHP 7.4.33 (cli) (built: Nov 16 2023 12:01:17) ( NTS )
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies

Що це означає: Ваш CLI-версія за замовчуванням — PHP 7.4. Вона може співпадати або не співпадати з тим, що використовує веб-сервер.

Рішення: Якщо плагін вимагає 8.1+, потрібен новий PHP, налаштований для веб-стеку, а не тільки для CLI.

Завдання 2: Перевірте, яку версію PHP віддає веб-сервер (та, що важлива)

cr0x@server:~$ curl -sI https://example.com | grep -i x-powered-by
X-Powered-By: PHP/7.4.33

Що це означає: HTTP-відповідь рекламує PHP 7.4. Деякі сайти приховують цей заголовок, але якщо він є — це сильна підказка.

Рішення: Якщо це стара версія, з’ясуйте, який хендлер використовується (FPM vs mod_php) і шлях оновлення.

Завдання 3: Якщо у вас є WP-CLI, дізнайтесь, що бачить WordPress

cr0x@server:~$ cd /var/www/example.com/public
cr0x@server:/var/www/example.com/public$ wp --info
OS:     Linux 6.1.0-18-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.76-1 (2024-02-01) x86_64
Shell:  /bin/bash
PHP binary:     /usr/bin/php7.4
PHP version:    7.4.33
wp-cli version: 2.10.0

Що це означає: WP-CLI запускається під PHP 7.4. Це корисно для діагностики, але знову ж: веб-PHP може відрізнятися.

Рішення: Розглядайте це як підтвердження, що система стара. Тепер перевірте хендлер веб-сервера.

Завдання 4: З’ясуйте, чи Apache використовує mod_php (поширена спадкова пастка)

cr0x@server:~$ apache2ctl -M | grep -E 'php|proxy_fcgi'
 php7_module (shared)

Що це означає: Apache має завантажений mod_php (тут як php7_module). Це зазвичай прив’язує Apache до однієї версії PHP.

Рішення: Розгляньте міграцію на PHP-FPM. Це чистий спосіб запускати кілька версій і зменшити зв’язування.

Завдання 5: Перевірте встановлені служби PHP-FPM (готовність до мульти-версій)

cr0x@server:~$ systemctl list-units --type=service | grep php | grep fpm
php7.4-fpm.service loaded active running The PHP 7.4 FastCGI Process Manager
php8.2-fpm.service loaded active running The PHP 8.2 FastCGI Process Manager

Що це означає: У вас вже є PHP 8.2 FPM встановлений і запущений. Чудово — тепер потрібно лише направити сайт на нього.

Рішення: Краще переключити віртуальний хост на php8.2-fpm для цього сайту. Тримайте 7.4 тимчасово для інших сайтів до міграції.

Завдання 6: Перевірте, який сокет FPM використовує сайт (реальне джерело правди)

cr0x@server:~$ grep -R "proxy:unix" -n /etc/apache2/sites-enabled/example.com.conf
42:    SetHandler "proxy:unix:/run/php/php7.4-fpm.sock|fcgi://localhost/"

Що це означає: Цей сайт прив’язаний до PHP 7.4 FPM.

Рішення: Змініть на сокет 8.2 (або 8.1/8.3 за вимогою), перезавантажте Apache і протестуйте.

Завдання 7: Переконайтесь, які версії PHP та модулі встановлені (плагіни турбуються про розширення)

cr0x@server:~$ php8.2 -m | egrep 'curl|mbstring|intl|openssl|imagick'
curl
intl
mbstring
openssl

Що це означає: Ці розширення доступні для PHP 8.2. Якщо плагін потребує imagick, а воно відсутнє, після оновлення версії ви все одно зламаєтеся.

Рішення: Встановіть відсутні розширення перед переключенням продакшен-трафіку, або погодьтеся на функціональний регрес, поки це не виправлено (зазвичай недопустимо для сайтів з медіа).

Завдання 8: Перевірте, чи немає пакетів PHP, що досягли EOL, на Debian/Ubuntu

cr0x@server:~$ apt-cache policy php
php:
  Installed: 2:8.2+93
  Candidate: 2:8.2+93
  Version table:
 *** 2:8.2+93 500
        500 http://deb.debian.org/debian bookworm/main amd64 Packages
        100 /var/lib/dpkg/status

Що це означає: Мета-пакет вирівняний з PHP 8.2. Це добре, але не гарантує, що ваш vhost його використовує.

Рішення: Підтвердьте пул FPM і конфіг веб-сервера. Стан пакетів необхідний, але не достатній.

Завдання 9: Переключити Apache-сайт з PHP 7.4 FPM на PHP 8.2 FPM (хірургічна зміна)

cr0x@server:~$ sudo sed -i 's#/run/php/php7.4-fpm.sock#/run/php/php8.2-fpm.sock#g' /etc/apache2/sites-available/example.com.conf
cr0x@server:~$ sudo apache2ctl configtest
Syntax OK
cr0x@server:~$ sudo systemctl reload apache2

Що це означає: Конфіг синтаксично валідний і Apache перезавантажився без помилок.

Рішення: Негайно проведіть перевірку працездатності: завантаження головної сторінки, доступ до wp-admin та проба phpinfo. Якщо щось не так — швидко відкотіть.

Завдання 10: Підтвердіть, що сайт тепер обслуговується новою версією PHP

cr0x@server:~$ curl -sI https://example.com | grep -i x-powered-by
X-Powered-By: PHP/8.2.15

Що це означає: Запити тепер виконуються на PHP 8.2.

Рішення: Перейдіть до функціональних перевірок: логін, оформлення замовлення (якщо є ecommerce), cron та оновлення плагіна.

Завдання 11: Увімкніть налагодження WordPress безпечно (логувати, не показувати)

cr0x@server:~$ sudo -u www-data bash -lc "grep -n \"WP_DEBUG\" -n /var/www/example.com/public/wp-config.php | head"
87:// define('WP_DEBUG', false);

Що це означає: Debug явно не встановлений (або закоментований). Можна увімкнути логування, не показуючи помилок відвідувачам.

Рішення: Увімкніть WP_DEBUG_LOG та вимкніть WP_DEBUG_DISPLAY. Потім відтворіть помилку та прочитайте логи.

Завдання 12: Слідкуйте за PHP-FPM та веб-логами під час тестового запиту (найкращий сигнал)

cr0x@server:~$ sudo tail -f /var/log/php8.2-fpm.log /var/log/apache2/error.log
[27-Dec-2025 10:11:07] NOTICE: ready to handle connections
[Sat Dec 27 10:11:14.282910 2025] [proxy_fcgi:error] [pid 21234] [client 203.0.113.10:53122] AH01071: Got error 'PHP message: PHP Fatal error:  Uncaught Error: Call to undefined function mysql_connect() in /var/www/example.com/public/wp-content/plugins/legacy-db/legacy.php:41'

Що це означає: Старий плагін використовує mysql_connect(), який давно видалено. Це не «баг PHP 8». Це плагін, що мав бути виведений з експлуатації.

Рішення: Вимкніть або замініть плагін. Якщо він критичний, можливо доведеться тимчасово тримати сайт на старому PHP — але заплануйте виправлення або міграцію. Не тримайте платежі на такому налаштуванні.

Завдання 13: Вимкнути зламаний плагін без wp-admin (найбезпечніший аварійний важіль)

cr0x@server:~$ cd /var/www/example.com/public/wp-content
cr0x@server:/var/www/example.com/public/wp-content$ sudo mv plugins/legacy-db plugins/legacy-db.disabled

Що це означає: WordPress перестане завантажувати цей плагін, бо він більше не в очікуваному каталозі.

Рішення: Якщо сайт відновився, ви підтвердили корінну причину. Замініть плагін або рефакторніть функціонал. Якщо сайт не відновився, продовжуйте читати логи; може бути декілька стекових помилок.

Завдання 14: Швидко перевірте підключення до БД та версію (деякі хости ламають це під час міграцій)

cr0x@server:~$ mysql --version
mysql  Ver 8.0.36 for Linux on x86_64 (MySQL Community Server - GPL)

Що це означає: У вас MySQL 8.0, що зазвичай нормально. Якщо б була дуже стара версія MySQL, деякі плагіни також можуть скаржитись.

Рішення: Якщо PHP оновлений, а помилки лишаються, перевірте драйвери бази даних (mysqli, pdo_mysql) та облікові дані.

Завдання 15: Перевірте поведінку WordPress cron після зміни PHP (тиха помилка)

cr0x@server:~$ cd /var/www/example.com/public
cr0x@server:/var/www/example.com/public$ wp cron event list --fields=hook,next_run --allow-root | head
action_scheduler_run_queue  2025-12-27 10:15:00
wp_version_check            2025-12-27 12:00:00
wp_update_plugins           2025-12-27 12:00:00

Що це означає: Cron-події існують. Це не доводить виконання, але перша перевірка.

Рішення: Якщо планові завдання перестали виконуватись після оновлення (часто при переключенні на інший PHP-двійник), налаштуйте системний cron, який викликає WP-CLI з правильною версією PHP, або виправте доступ до веб-endpoint для cron.

Завдання 16: Зробіть знімок перед великими змінами (snapshot файлової системи на сучасному сховищі)

cr0x@server:~$ sudo zfs snapshot tank/www@example.com@pre-php82
cr0x@server:~$ sudo zfs list -t snapshot | grep pre-php82
tank/www@example.com@pre-php82  0B  -  240G  -

Що це означає: У вас є миттєвий знімок. Відкат тепер — команда, а не молитва.

Рішення: Продовжуйте з оновленням. Якщо щось піде не так, ви зможете швидко повернутися. Якщо у вас немає знімків — емулюйте їх бекапами та клонуванням стейджингу.

Короткий жарт №2: Якщо ви оновите PHP у п’ятницю після обіду, вікенд теж оновиться — у вигляді робочого вікенду.

Шляхи оновлення за типом хостингу

Shared hosting (cPanel, Plesk, «кастомна панель»)

Це найпоширеніше поле бою «плагін вимагає новішу версію PHP». Зазвичай у вас обмежений контроль, але не нульовий.

• Шукайте селектор PHP по домену. Якщо можна обрати PHP 8.1/8.2 по сайту — проблема вирішується за 10 хвилин. Робіть це спочатку на стейджингу, якщо хост його надає.
• Якщо найновіше — все ще старе, ескалюйте. Спитайте підтримку, коли вони планують PHP 8.2/8.3 і чи можуть увімкнути його для вашого акаунту. Їхня відповідь підкаже, чи варто мігрувати.
• Остерігайтеся заяв «у нас є PHP 8.x», що стосуються тільки CLI. Деякі хости мають кілька CLI, але блокують веб-хендлер на одній версії.

Порада з позицією: якщо хост не може запропонувати підтримувану версію PHP сьогодні — починайте планувати переїзд. Не тягніть місяцями, ігноруючи оновлення безпеки.

Managed WordPress hosting

Керовані платформи зазвичай роблять поетапні випуски і дають перемикач версії PHP. Ваше завдання:

• Використовуйте їхній стейджинг, а не продакшен, для першого переключення.
• Підтвердіть, що вони зберігають старі версії PHP лише тимчасово; вам не потрібна платформа, яка ставиться до EOL як до опції.
• Перевірте, чи вони контролюють об’єктне кешування, кеш сторінок і WAF-політики — вони можуть змінити поведінку при оновленні PHP.

VPS / виділений сервер (ви володієте проблемою і виправленням)

Плюс: ви можете вирішити це правильно. Мінус: ви можете вирішити це неправильно, і вам дзвонитимуть уночі.

• Віддавайте перевагу PHP-FPM над mod_php. Це роз’єднує веб-сервер і дозволяє пулі для кожного сайту.
• Встановіть кілька версій, якщо хостите кілька сайтів, а потім мігруйте по сайту.
• Фіксуйте зміни конфігурації спочатку для одного vhost. Не робіть «apt upgrade всього» і надійтесь.

Контейнеризовані / Kubernetes налаштування

Якщо WordPress вже в контейнерах, рантайм — просто тег образу. Це звучить легко — і є таким — поки не врахуєш постійне сховище і процеси оновлення плагінів.

• Зберіть або візьміть образ з потрібною версією PHP.
• Розгорніть у стейджингу з тією ж дамп-базою і снапшотом uploads.
• Переконайтесь, що ваш persistent volume підтримує атомарні снапшоти (або консистентні бекапи). Інакше відкат буде складним.

Три міні-історії з корпоративного світу

Міні-історія №1: Інцидент через хибне припущення

Середня компанія мала WordPress-сайт, що здавався простим: маркетинговий сайт з блогом, кількома лендингами та інтеграцією форм. Він хостився на VPS, «якого ніхто не торкався», що в корпоративній мові означає «ніхто ним не володіє».

Розробник оновив плагін форм для виправлення вразливості. Плагін почав вимагати PHP 8.1. Сервер був на PHP 7.4. Припущення було: «ОС оновлена, отже PHP має бути оновлений». ОС була оновлена. PHP — ні. Apache все ще був прив’язаний до старого FPM-сокета, а нові пакети встановлено, але не використовувалися.

Сайт потрапив у петлю фатальної помилки, але тільки на певних сторінках — тих, що завантажували новий код плагіна. Це затримало діагностику, бо головна сторінка ще працювала і всі сперечалися, що «це періодично».

SRE на виклику зробив те, що зекономило час: припинив дискусію і подивився логи, відтворюючи запит. Повідомлення про помилку було соромно явним: плагін відмовився запускатися на PHP 7.4.

Виправлення не було героїчним: переключили vhost на PHP 8.2 FPM, відключили один давній плагін, що використовував видалені mysql-функції, а потім по черзі ввімкнули функції. Постмортем стосувався володіння: версія рантайму — залежність, і залежності потребують власника. «Ніхто не торкався» — не стратегія.

Міні-історія №2: Оптимізація, що спалила назад

Інша організація хотіла менше рухомих частин. Вони тримали Apache з mod_php, бо «це швидше» і «не потрібні додаткові демони». Хтось прочитав старий бенчмарк і вирішив, що PHP-FPM — зайва складність. Також вони консолідували кілька WordPress-сайтів на одній машині, щоб зекономити.

Потім один сайт потребував сучасного розширення WooCommerce, що вимагало PHP 8.2. Інший сайт мав спадкову тему, яка ламалася на PHP 8.x через строгі попередження типів, що перетворювалися на винятки кастомним обробником помилок.

З mod_php у них була тільки одна версія PHP для всіх. Їхня «оптимізація» позбавила можливості поступового міграції. Їх змусили робити велике коливання: змінити PHP для всіх сайтів одразу або тримати все старим. Вони обрали зміну.

Половина сайтів зламалася тонкими способами: контактні форми перестали надсилати, обробка зображень провалилась, бо Imagick не був скомпільований для нового PHP, і планові завдання мовчки загинули. Звернень у службу підтримки стало багато, і команда тиждень займалась аварійним триажем замість планової міграції.

Вони зрештою перейшли на PHP-FPM з пулом на сайт і базовим канарним розгортанням. Урок не в «ніколи не оптимізуйте». Урок — «не оптимізуйте вартістю ізоляції». У продакшені ізоляція — це продуктивність. Це продуктивність людей під тиском.

Міні-історія №3: Нудна, але правильна практика, що врятувала день

Регульований бізнес вів WordPress для порталу документації. Не гламурно, але клієнтоорієнтовано і піддається аудитам. Їхня інфраструктурна команда мала нудну політику: кожна зміна проходить через стейджинг, і стейджинг максимально віддзеркалює продакшен. Та сама версія PHP, та сама конфігурація веб-сервера, ті самі правила кешування. Також вони брали снапшоти файлової системи та бази даних перед змінами рантайму.

Коли оновлення плагіна стало вимагати PHP 8.1, вони не панікували. Клонували продакшен у стейджинг зі вчорашнього снапшоту, переключили стейджинг на PHP 8.2 і запустили скриптований план тестів: логін, пошук, рендер сторінки, завантаження файлу і специфічні сценарії плагіна.

Знайшли одну проблему: кастомний mu-plugin використовував застарілі функції, що тепер були лише попередженнями. У продакшені попередження піднімалися до помилок через строгий обробник помилок. Це спричинило б жорсткий outage, якби виявили наживо.

Вони виправили mu-plugin, повторили тести і запланували переключення в продакшен. Під час фактичного cutover слідкували за логами й метриками, мали план відкату, що включав повернення снапшотів і переключення FPM-сокетів назад. Відкат не знадобився — в цьому і суть.

Що їх врятувало — не геній. Це нудьга: повторювана процедура, снапшоти і відмова ставити продакшен як пісочницю. Хочете менше інцидентів — візьміть більше нудьги.

Поширені помилки: симптом → корінна причина → виправлення

Тут більшість команд марнують час. Симптоми виглядають як WordPress-драма, але корінні причини майже завжди передбачувані.

1) Симптом: повідомлення «Plugin requires PHP 8.1» в wp-admin

• Корінна причина: Рантайм сайту старший за мінімальну версію плагіна.
• Виправлення: Оновіть рантайм PHP, який використовує веб-сервер. Підтвердіть зміни через заголовки/логи. Не оновлюйте тільки CLI PHP.

2) Симптом: білий екран або «There has been a critical error» після оновлення плагіна

• Корінна причина: Фатальна помилка через несумісну версію PHP або відсутнє розширення.
• Виправлення: Перевірте веб-логи і логи PHP-FPM. Вимкніть плагін, перейменувавши його каталог, потім оновіть PHP або встановіть потрібне розширення.

3) Симптом: Сайт працює для відвідувачів, але wp-admin зламаний (або навпаки)

• Корінна причина: Різні шляхи коду, різне завантаження плагінів або кеш приховує помилки.
• Виправлення: Обійдіть кеш і відтворіть помилку, слідкуючи логи. Тестуйте інтерфейс і адмінку після змін PHP.

4) Симптом: Після оновлення PHP завантаження медіа перестало працювати або мініатюри не генеруються

• Корінна причина: Відсутні бібліотеки обробки зображень (GD/Imagick) для нової версії PHP або проблеми з правами в uploads.
• Виправлення: Встановіть розширення для нового PHP і перезапустіть FPM. Перевірте php -m під правильною версією.

5) Симптом: Випадкові 502/504 після переключення на PHP-FPM

• Корінна причина: Неправильна конфігурація пулу FPM, права сокета, занадто низький pm.max_children або таймаути.
• Виправлення: Перевірте логи на «connect() to unix socket failed» vs «upstream timed out». Виправте права або налаштуйте ліміти пулу за реальним трафіком.

6) Симптом: «Call to undefined function» після оновлення

• Корінна причина: Плагін/тема використовує видалені/застарілі функції; або потрібне PHP-розширення не ввімкнено.
• Виправлення: Визначте функцію: якщо це функція розширення — встановіть/увімкніть розширення. Якщо це видалена поведінка ядра — замініть плагін/тему.

7) Симптом: wp-cron зупинився, заплановані пости не публікуються, задачі ecommerce зависли

• Корінна причина: Cron залежить від веб-запитів; після змін loopback-запити відмовляють або системний cron викликає неправильний PHP-двійник.
• Виправлення: Налаштуйте системний cron, який викликає WP-CLI з правильною версією PHP; перевірте loopback і правила фаєрвола.

8) Симптом: Ви оновили PHP, але плагін все одно каже, що він старий

• Корінна причина: Ви оновили одну версію PHP (CLI), але веб-хендлер все ще вказує на стару; або існує кілька рантаймів і сайт прив’язаний до старого.
• Виправлення: Знайдіть хендлер (FPM-сокет, Apache module, Nginx fastcgi_pass) і переключіть його. Підтвердіть через заголовки і phpinfo.

Чеклісти / покроковий план

Ось план, який я б виконав як SRE, що підтримує WordPress: мінімум драми, максимум відкатності.

Чекліст A: Перед тим як торкатися продакшену

1. Прочитайте вимоги плагіна. Мінімальна версія PHP, потрібні розширення і примітки щодо версії WordPress.
2. Перелічіть ваш рантайм. Який PHP використовує веб? Який CLI? Чи відрізняються вони?
3. Випишіть критичні потоки. Логін, оформлення замовлення, контактні форми, завантаження медіа, редагування адмінки, очищення кешу, cron-задачі.
4. Зробіть відкат реальним. Снапшот файлової системи + бази, або хоча б бекап, який ви перевіряли на відновлення.
5. Зберіть стейджинг-клон. Такий самий тип хендлера PHP, той самий кеш-слой, та сама конфігурація.

Чекліст B: Потік оновлення у стейджингу (рекомендовано навіть для «малих» сайтів)

1. Клонувати продакшен у стейджинг (файли + БД).
2. Переключити стейджинг на цільову версію PHP (8.1/8.2/8.3).
3. Встановити потрібні PHP-розширення на стейджингу.
4. Оновити плагін у стейджингу перш ніж у продакшені.
5. Прогнати критичні сценарії і слідкувати за логами.
6. Виправити або замінити будь-які несумісні плагіни/теми.
7. Записати точні зміни (diff конфігів, встановлені пакети).

Чекліст C: Cutover у продакшен з мінімальним простоєм

1. Обрати тихий час. Навіть «безпростоєві» зміни мають ризик, який менший при меншому трафіку.
2. Застосувати ті самі зміни, що в стейджингу. Не імпровізуйте.
3. Перезавантажувати замість рестарту, де можливо. Релоад конфігурації веб-сервера зменшує переривання.
4. Негайно виконати health check. Головна сторінка, wp-admin і один плагін-специфічний сценарій.
5. Слідкувати за логами 15–30 хвилин. Багато збоїв проявляються після запуску фонових задач.
6. Тільки потім оновлюйте плагін у продакшені (якщо ви цього ще не зробили і політика дозволяє).

Чекліст D: Якщо не можете оновити PHP на хості

1. Призупиніть оновлення плагіна. Тримайте поточну версію, якщо вона не вразлива.
2. Оцініть ризик: якщо оновлення плагіна виправляло уразливість, вважайте, що ви на годиннику.
3. Оберіть стратегію ізоляції:
   • Перенесіть сайт на новий хост з підтримкою сучасного PHP.
   • Підніміть новий VPS і мігруйте DNS.
   • Поставте реверс-проксі і запускайте WordPress в іншому місці.
4. Зробіть міграцію нудною. Файли, база, конфіги і план cutover з відкатом (DNS TTL, снапшот, режим обслуговування).

Як думати про безпеку: сумісність, безпека і відкат

Найгірше мислення — «оновлення PHP страшне». Друге за гіркістю — «оновлення PHP нічого не змінює». Ставтесь до цього як до будь-якого оновлення рантайму: змінюється поведінка, обробка помилок, характеристики продуктивності і іноді доступність бібліотек.

Ось операційна формула, що працює:

• Ризик сумісності головним чином про старі плагіни/теми. Перелічіть і виведіть їх з експлуатації. Якщо щось не оновлювалося роками — це не «стабільне», це покинуте.
• Ризик безпеки зростає з часом. Стара версія PHP — не просто повільніша чи некрасивіша; це зобов’язання. Хости іноді «бекпортять патчі», але вимагайте ясності: що запатчено і як швидко?
• Відкат має бути механічним. Якщо відкат — «ми спробуємо це скасувати», це не відкат. Це імпровізація.

Парафраз ідеї від Werner Vogels (CTO Amazon): ви будуєте надійні системи, очікуючи відмов і проектуючи відновлення, а не сподіваючись, що нічого не зламається.

Чого уникати (сильні думки, набуті важким шляхом)

• Не редагуйте vendor/plugin код, щоб «змусити працювати». Ви забудете, автoоновлення перепише зміни, і наступний інцидент буде вашою провиною.
• Не робіть продакшен-змін без логів. Якщо ви не бачите PHP-FPM та помилок веб-сервера, ви дебажите з зав’язаними очима.
• Не тримайте ecommerce на EOL-рантаймі. Якщо через нього проходять гроші, тактовність патчів — частина продукту.
• Не припускайте, що «хост це вирішить». Деякі справді допоможуть. Багато — ні. Перевіряйте.
• Не ототожнюйте «WordPress підтримує це» з «плагіни підтримують це». Вашою реальною платформою є екосистема встановлених вами компонентів.

FAQ

1) Чи можу я просто встановити старішу версію плагіна?

Можна, іноді. Це тимчасове рішення, а не виправлення. Якщо плагін відмовився від старого PHP через безпеку або оновлення залежностей, фіксація старої версії може лишити вас вразливими. Використовуйте це лише щоб виграти час на оновлення PHP або міграцію.

2) Якщо я оновлю PHP, чи зламається ядро WordPress?

Сучасний WordPress зазвичай працює нормально на PHP 8.1/8.2/8.3. Поломки частіше викликають старі теми/плагіни або кастомний код. Ось чому стейджинг важливий: він показує, яка залежність проблема, до того як побачать це користувачі.

3) Мій хост каже, що «підтримує PHP 8», але плагін все одно скаржиться. Чому?

Бо «підтримує» може означати «доступно для деяких акаунтів», «доступно для CLI» або «доступно, якщо ви переключите селектор по сайту». Підтвердіть рантайм, який використовує веб-сервер, а не тільки те, що встановлено.

4) На яку версію PHP мені орієнтуватись зараз?

Орієнтуйтесь на поточну підтримувану версію PHP, яку надає ваш дистро/хост — зазвичай PHP 8.2 або 8.3. Якщо плагін вимагає 8.1, не обмежуйтесь 8.1 без причин; інакше доведеться повторювати весь процес скоро.

5) Як оновити PHP без простою?

Запустіть кілька версій PHP-FPM, переключіть upstream сокет сайту і перезавантажте веб-сервер. Це зазвичай майже миттєво. Справжній ризик простою — несумісність застосунку, яку пом’якшують стейджинг і снапшоти.

6) Якщо на тій же машині є інший сайт, що потребує старого PHP?

Вам потрібен PHP-FPM з кількома пулами/версіями і конфігурацією по vhost. Якщо ви застрягли на mod_php, ви самі себе запакували. Міґруйте спадкові сайти або ізолюйте їх на окрему VM/контейнер.

7) Чи достатньо оновити PHP, чи треба оновлювати MySQL/MariaDB теж?

Зазвичай саме PHP блокує помилку плагіна. Але, перевіривши PHP, перевірте також версії бази та розширення. Деякі сучасні плагіни очікують новішу поведінку MySQL/MariaDB, особливо щодо наборів символів і строгих режимів SQL.

8) Сайт працює після оновлення PHP, але продуктивність погіршилася. Що сталося?

Поширені причини: OPcache не увімкнено/не налаштовано для нового PHP, ліміти пулу FPM занадто низькі або кеш-шари поводяться інакше. Перевірте статус OPcache і налаштуйте FPM, а не звинувачуйте версію PHP без аналізу.

9) У мене немає SSH. Що я можу зробити?

Використовуйте панель управління хостингу, щоб переключити версію PHP, якщо така можливість є, і перевірте зміни через Site Health у WordPress. Якщо хост не може надати сучасний PHP — мігруйте. Відсутність SSH не фатальна; відсутність підтримуваних рантаймів фатальна.

Наступні кроки, які можна зробити сьогодні

Практична послідовність, що працює в реальному житті:

1. Підтвердіть фактичну версію PHP, яку використовує веб-сервер. Не довіряйте рекламній панелі; довіряйте заголовкам і логам.
2. Оберіть найчистіший шлях: оновлення на місці, ізоляція або міграція.
3. Створіть стейджинг. Клон, переключення PHP, оновлення плагіна, тестування фінансових шляхів і адмін-процесів.
4. Зробіть відкат механічним. Снапшоти або протестовані бекапи. Не «ми згадаємо, що змінювали».
5. Переключайте і стежте. Логи, cron і рівні помилок мінімум 15–30 хвилин.
6. Потім прибирайте. Видаліть закинуті плагіни, задокументуйте хендлер PHP і заплануйте періодичні рев’ю рантайму, щоб це не застало зненацька вдруге.

Якщо ваш хост не може надати підтримувані версії PHP — не сперечайтесь із фізикою. Переїжджайте. Продакшен-системи не стають кращими від сподівань; вони стають кращими від відповідальності і відтворюваних змін.