Версії PHP у cPanel: як вибрати і перемкнути

Вибір версії PHP критичний для сумісності CMS і продуктивності. Різні проєкти потребують різних версій: те, що оптимально для нового застосунку на Laravel, може повністю зламати п'ятирічний сайт на саморобному рушії.

Як вибрати версію PHP під проєкт

«Мінімальна версія» — це поріг, нижче якого фреймворк чи CMS формально не запуститься або відмовить у встановленні. «Рекомендована» — версія з найкращим балансом швидкості і сумісності плагінів на момент актуальності статті; для конкретного сайту варто звірятися з вимогами використовуваних плагінів окремо. Якщо версія PHP на сервері нижча за мінімальну, сучасний Laravel-проєкт навіть не запустить встановлення залежностей — Composer одразу зупиниться з зрозумілим повідомленням:

Problem 1
  - Root composer.json requires php ^8.2 but your php version (7.4.33) does not
    satisfy that requirement.

Це не помилка конфігурації проєкту, а пряма вимога фреймворку — вирішується лише перемиканням версії PHP на сервері, а не правкою composer.json в обхід перевірки.

Перемикання версії PHP у cPanel

1. cPanel → Програмне забезпечення → Вибір версії PHP
2. Виберіть версію (рекомендуємо PHP 8.2)
3. Натисніть Встановити як поточну
4. Перевірте сумісність плагінів/тем

Різні версії PHP для різних доменів

У cPanel можна призначити окрему версію PHP для кожного домену чи папки:

1. cPanel → MultiPHP Manager
2. Виберіть домен → вкажіть версію

Типова помилка під час переходу на нову версію

Починаючи з PHP 8.1 передавання null у параметр функції, який не оголошений nullable, стало видавати попередження про застарілість, а в багатьох вбудованих функціях PHP 8.2+ — фатальну помилку:

Fatal error: Uncaught TypeError: trim(): Argument #1 ($string) must be of type
string, null given, called in /home/user/public_html/wp-content/plugins/old/init.php
on line 34

Це одна з найчастіших причин, чому старі плагіни WordPress ламаються саме на PHP 8.2, а не раніше: код роками передавав у trim(), strlen() чи htmlspecialchars() результат, який іноді міг виявитися null (наприклад, неіснуюче поле з бази даних), і раніше PHP мовчки перетворював його на порожній рядок. Виправлення — оновити плагін до версії, де автор додав явну перевірку на null перед викликом функції.

Налаштування PHP розширень

cPanel → Вибір версії PHP → Extensions:

• Для WordPress: mysqli, gd, curl, mbstring, xml, zip
• Для Laravel: pdo_mysql, bcmath, tokenizer, fileinfo
• Для інтернет-магазинів (WooCommerce, PrestaShop): додатково intl і soap для роботи зі службами доставки і валютами
• Для API-інтеграцій: curl і openssl обов'язкові для HTTPS-запитів до зовнішніх сервісів

Налаштування php.ini через cPanel

# cPanel → PHP Settings (або створіть .htaccess):
php_value upload_max_filesize 64M
php_value post_max_size 64M
php_value max_execution_time 300
php_value memory_limit 256M

Зміни через панель PHP Settings у cPanel застосовуються миттєво, а от при використанні файлу .user.ini як альтернативи варто пам'ятати про затримку кешування — нові значення директив підхоплюються не одразу, а із затримкою до п'яти хвилин, за яку відповідає параметр user_ini.cache_ttl.

Коли не варто одразу переходити на найновішу версію

• Сайт використовує плагіни, останнє оновлення яких було більше двох років тому — ризик фатальних помилок високий, а автор може вже не підтримувати код
• Немає тестової копії сайту — перемикати версію бойового магазину чи сайту з трафіком без staging-перевірки ризиковано
• Використовується саморобний код із прямими викликами застарілих функцій (each(), create_function(), ${} усередині рядків) — вони фізично видалені в PHP 8.x, і версія тут не допоможе, потрібен рефакторинг
• Хостинг-провайдер ще не оновив серверні модулі (наприклад, ionCube Loader) під нову версію PHP — тоді ліцензійні захищені скрипти просто перестануть запускатися

Перевірка поточної версії

# Через SSH:
php -v

# Або створіть phpinfo.php:
<?php phpinfo(); ?>
# Видаліть файл після перевірки!

PHP 7.4 не отримує оновлення безпеки з грудня 2022 року — експлуатація відомих вразливостей на такій версії не буде виправлена ніколи, і хостинг-провайдер не несе відповідальності за наслідки. Навіть якщо сайт на PHP 7.4 зараз працює без видимих проблем, це не ознака безпеки — це ознака того, що вразливість ще не була знайдена і використана саме проти вашого сервера. Детальніше про помилки після зміни версії і роботу з error_log — у статті логи помилок у cPanel, а про сам механізм PHP Selector — у статті cPanel PHP Selector.