У панелі хостингу змінити версію PHP часто можна за кілька кліків. Але саме після такого «простого» перемикання сайт іноді перестає відкриватися, зникає адмінпанель або з’являється помилка 500.
Причина не в тому, що новіша версія PHP погана. Найчастіше проблема в старій темі, плагіні, модулі або власному коді, який використовує застарілі функції.
Тому правильне оновлення PHP — це не натискання перемикача, а коротка процедура з перевіркою сумісності та можливістю швидко повернути попередній стан.
Коротка відповідь
Безпечний порядок зміни PHP виглядає так:
- визначити поточну версію PHP;
- перевірити вимоги CMS, теми та критичних модулів;
- створити повну резервну копію;
- за можливості протестувати нову версію на staging;
- змінити PHP;
- перевірити сайт, адмінпанель, форми та інтеграції;
- переглянути PHP error log;
- залишити можливість швидкого відкату.
Якщо сайт давно не оновлювався, переходити одразу через декілька поколінь PHP без тестування особливо ризиковано.
Навіщо взагалі оновлювати PHP, якщо сайт і так працює
Стару версію часто залишають за принципом «не чіпай те, що працює». Для бізнес-сайту це слабка стратегія.
Підтримувана версія PHP дає три основні переваги:
- виправлення безпеки;
- кращу сумісність із сучасними CMS та плагінами;
- зазвичай кращу продуктивність порівняно з давно застарілими гілками.
З часом виникає й практична проблема: нові версії WordPress, WooCommerce, OpenCart-модулів або бібліотек перестають нормально підтримувати старе PHP.
У результаті власник відкладає оновлення декілька років, а потім змушений міняти одночасно PHP, CMS, тему та десятки модулів.
Як дізнатися поточну версію PHP
Найпростіше — у панелі хостингу. Зазвичай версія вказується окремо для домену або сайту.
Також її можна перевірити:
- у системній інформації CMS;
- через панель WordPress Site Health;
- через командний рядок на VPS;
- через службову інформацію хостингу.
Не рекомендується надовго залишати у відкритому доступі файл phpinfo.php, оскільки він показує багато технічної інформації про сервер.
Крок 1. Перевірте вимоги CMS
Спочатку потрібно зрозуміти, чи підтримує ваша система нову версію PHP.
Перевіряються:
- CMS;
- тема або шаблон;
- плагіни;
- модулі;
- кастомний код;
- інтеграції.
Особливу увагу потрібно приділити компонентам, які давно не оновлювалися.
Якщо розробник плагіна припинив підтримку декілька років тому, саме він може стати головною перешкодою для переходу.
Крок 2. Не оновлюйте PHP раніше, ніж сам сайт
Типова помилка — на дуже старому WordPress або OpenCart спочатку увімкнути нове PHP, а вже потім намагатися оновлювати CMS.
Безпечніший сценарій часто виглядає так:
- створити бекап;
- оновити сумісні плагіни та модулі;
- перевірити CMS;
- підготувати тему;
- лише після цього тестувати нове PHP.
Конкретний порядок залежить від віку сайту, тому на дуже старих проєктах оновлення краще планувати як окреме технічне завдання.
Крок 3. Створіть повну резервну копію
Перед перемиканням потрібні:
- копія всіх файлів;
- дамп бази даних;
- бажано копія поточної конфігурації.
Зміна PHP сама по собі не повинна видаляти дані. Але проблема може виникнути після запуску несумісного модуля або невдалого оновлення, яке виконувалося одночасно.
Тому резервна копія — це нормальна частина процедури, а не перестраховка.
Крок 4. Перевірте PHP на staging
Для комерційного сайту це найкращий варіант.
Створюється копія проєкту, на якій:
- вмикається нова версія PHP;
- очищається кеш;
- перевіряється frontend;
- перевіряється адміністративна панель;
- тестуються ключові бізнес-функції;
- аналізується error log.
Як правильно ізолювати тестову копію, ми розбирали в матеріалі як створити staging-середовище для сайту.
Що тестувати на WordPress
Недостатньо просто відкрити головну сторінку.
Після зміни PHP перевірте:
- вхід у wp-admin;
- редагування сторінки;
- форми;
- пошук;
- мобільну версію;
- кеш;
- cron;
- відправлення пошти.
Якщо використовується WooCommerce, додаються:
- каталог;
- варіативні товари;
- кошик;
- checkout;
- оплата;
- листи про замовлення;
- особистий кабінет.
Що тестувати на OpenCart
Для OpenCart важливо пройти весь сценарій покупця:
- відкрити категорію;
- перевірити фільтри;
- виконати пошук;
- відкрити товар;
- додати його в кошик;
- оформити тестове замовлення;
- перевірити оплату в тестовому режимі;
- перевірити листи;
- відкрити адміністративну частину.
Окремо варто перевірити OCMOD та сторонні модулі. Старі розширення OpenCart досить часто стають причиною несумісності з новішим PHP.
Крок 5. Перемикайте PHP для конкретного сайту
Якщо в одному хостинг-акаунті знаходиться декілька сайтів, не завжди потрібно змінювати PHP глобально.
Сучасні панелі часто дозволяють встановити різні версії для різних доменів.
Це значно безпечніше:
- оновлюєте один сайт;
- перевіряєте його;
- переходите до наступного.
Якщо один старий проєкт потребує попередньої версії PHP, він не блокує модернізацію інших сайтів.
Після перемикання очистіть кеш
Потрібно очистити:
- кеш CMS;
- кеш плагіна;
- object cache;
- серверний кеш;
- за потреби CDN.
Інакше частина сторінок може продовжувати віддаватися зі старого кешу, створюючи хибне враження, що все працює.
Найважливіше після оновлення — PHP error log
Сайт може виглядати нормально, але журнал уже містити десятки попереджень про застарілі функції.
Це важливий сигнал.
Шукайте:
- Fatal error;
- Uncaught Error;
- Deprecated;
- Warning;
- TypeError;
- помилки конкретних плагінів і модулів.
Не кожен warning критичний, але велика кількість таких повідомлень означає, що компонент потрібно оновити або замінити.
Сайт показує 500 після зміни PHP: що робити
Якщо після перемикання одразу з’явилася помилка 500:
- поверніть попередню версію PHP;
- перевірте, чи сайт відновив роботу;
- відкрийте error log;
- знайдіть файл або модуль, який викликає помилку;
- оновіть або замініть проблемний компонент;
- повторіть тест.
Не потрібно хаотично видаляти файли або змінювати десятки параметрів одночасно.
Якщо старе PHP одразу повертає сайт до роботи, ви вже локалізували проблему до рівня сумісності.
Білий екран після зміни PHP
Так званий White Screen of Death часто означає критичну PHP-помилку, але її відображення вимкнене.
Не варто вмикати display_errors на production і залишати його активним для всіх користувачів.
Правильніше переглянути серверний PHP error log.
Адмінка працює, а окремі сторінки — ні
Це хороший приклад того, чому поверхнева перевірка недостатня.
Причиною може бути конкретний:
- shortcode;
- плагін форми;
- шаблон сторінки;
- віджет;
- модуль каталогу;
- API-клієнт.
Тому після переходу потрібно пройти основні типи сторінок, а не лише homepage.
Зміна PHP і база даних
Версія PHP та версія MySQL/MariaDB — різні речі.
Оновлення PHP не означає автоматичного оновлення бази даних.
Проте старий код може використовувати бібліотеки або методи роботи з базою, які поводяться інакше в новому середовищі.
Тому після зміни PHP потрібно тестувати:
- збереження налаштувань;
- створення користувачів;
- оформлення замовлень;
- імпорт;
- пошук;
- складні фільтри.
PHP extensions: непомітна причина проблем
Іноді сайт сумісний із новою версією PHP, але після перемикання перестає працювати окрема функція.
Причиною може бути відсутнє розширення.
Сайту можуть бути потрібні, залежно від програмного забезпечення:
- curl;
- mbstring;
- intl;
- zip;
- gd або imagick;
- mysqli;
- soap.
На shared-хостингу вони зазвичай керуються через панель. На VPS за них відповідає адміністратор.
memory_limit після зміни версії
Перевірте, чи не змінилися PHP-параметри разом із версією.
Особливо:
- memory_limit;
- upload_max_filesize;
- post_max_size;
- max_execution_time;
- max_input_vars.
У деяких панелях кожна версія PHP може мати власний набір параметрів.
Чи стане сайт швидшим після переходу
Іноді так, особливо якщо попередня версія була дуже старою.
Але не варто очікувати, що одне оновлення PHP вирішить усі проблеми продуктивності.
Якщо TTFB високий через:
- повільні SQL-запити;
- перевантажений shared-сервер;
- важкий плагін;
- зовнішній API;
- відсутність кешування;
нова версія PHP може лише частково покращити ситуацію.
Для комплексної діагностики використовуйте окремий гід як зменшити TTFB сайту.
Не тримайте старе PHP лише через один плагін
Якщо весь сайт можна оновити, але один давно покинутий компонент працює тільки на старій версії PHP, правильніше планувати його заміну.
Інакше один модуль поступово блокує:
- оновлення PHP;
- оновлення CMS;
- інші плагіни;
- безпекові виправлення.
Це класичний технічний борг.
Коли не варто змінювати PHP самостійно
Краще спочатку підготувати технічний план, якщо:
- сайт не оновлювався декілька років;
- використовується стара кастомна тема;
- є власні PHP-модулі;
- невідомо, хто розробляв сайт;
- немає резервної копії;
- сайт приносить критично важливі замовлення;
- немає можливості швидкого rollback.
Практичний сценарій для старого бізнес-сайту
Якщо сайт працює на давно застарілому середовищі, безпечніше розділити роботу на етапи:
- створити повний бекап;
- розгорнути staging;
- перевірити сайт на шкідливий код;
- оновити сумісні компоненти;
- видалити непотрібні плагіни;
- перевірити нову версію PHP;
- виправити конфлікти;
- провести функціональне тестування;
- лише після цього виконати зміни на production.
Такий підхід займає більше часу, але значно знижує ризик довгого простою.
Чек-лист після зміни PHP
- Головна сторінка відкривається.
- Внутрішні сторінки працюють.
- Адмінпанель доступна.
- Форми надсилаються.
- Пошта приходить.
- Пошук працює.
- Авторизація працює.
- Для магазину оформлено тестове замовлення.
- Cron виконується.
- PHP error log перевірено.
- Кеш очищено.
- Версія PHP зафіксована в технічній документації.
FAQ
Чи можна просто перемкнути PHP назад, якщо сайт зламався?
У більшості панелей — так. Якщо проблема виникла саме через несумісність, повернення попередньої версії часто швидко відновлює роботу. Але після цього потрібно знайти й усунути причину.
Чи змінюється база даних при перемиканні PHP?
Саме перемикання PHP базу не оновлює. Але код CMS може виконувати операції з даними, тому перед змінами все одно потрібен backup.
Чи потрібно оновлювати PHP, якщо сайт працює нормально?
Підтримувані версії важливі для безпеки та сумісності. Залишати сайт на давно непідтримуваному PHP лише тому, що він відкривається, не варто.
Чому після оновлення зламався тільки один плагін?
Найімовірніше, саме його код використовує конструкції, які більше не підтримуються або поводяться інакше.
Хостинг повинен сам оновити PHP?
Хостинг підтримує серверні версії, але сумісність конкретного сайту зазвичай потрібно перевіряти власнику або розробнику. Детальніше межі відповідальності описані в матеріалі про технічну підтримку сайту.
Висновок
Зміна PHP займає декілька хвилин тільки на технічному рівні. Для бізнес-сайту основна робота полягає в перевірці сумісності.
Найбезпечніша схема — резервна копія, staging, тестування нової версії, перевірка PHP error log і лише після цього зміна production.
Якщо сайт дуже старий, не намагайтеся вирішити багаторічний технічний борг одним перемикачем. Краще поступово оновити CMS, плагіни та серверне середовище, зберігаючи можливість відкату на кожному етапі.
