LiteSpeed Хостинг та управління версіями PHP: Повний технічний посібник для користувачів AlexHost

Вибір правильної версії PHP для вашого хостингового середовища є одним із найважливіших рішень при розгортанні веб-застосунків. Неправильна версія може непомітно знизити продуктивність, створити вразливості безпеки або повністю порушити сумісність із фреймворком. Спільний хостинг AlexHost на базі LiteSpeed підтримує PHP 7.3, 7.4, 8.0 та 8.1 одночасно, дозволяючи призначати різні версії PHP для кожного домену через MultiPHP Manager у cPanel — без редагування файлів конфігурації сервера або звернення до служби підтримки.

Цей посібник охоплює те, що кожна версія PHP реально надає на рівні рушія, як правильно перемикати версії на інфраструктурі AlexHost, а також як уникнути поширених помилок, що призводять до збоїв застосунків після зміни версії.

Чому вибір версії PHP має більше значення, ніж більшість розробників усвідомлює

PHP — це не монолітне середовище виконання. Кожен основний і другорядний випуск змінює поведінку Zend Engine, оголошує функції застарілими, змінює правила приведення типів і модифікує взаємодію OPcache та JIT-компілятора з вашим кодом. Запуск коду PHP 7.3 на PHP 8.1 без тестування — це не безпечне оновлення, а ризик для вашого виробничого середовища.

LiteSpeed Web Server обробляє виконання PHP через LSAPI (LiteSpeed Server Application Programming Interface), що архітектурно відрізняється від mod_php або FastCGI в Apache. LSAPI підтримує постійні робочі процеси PHP, усуваючи накладні витрати на створення процесу для кожного запиту, що обтяжує традиційні налаштування. Результатом є помітно менший час до першого байта (TTFB) і значно менша кількість циклів CPU на запит — що особливо важливо для PHP-інтенсивних застосунків, таких як WordPress, Magento або Laravel.

Поєднуючи LSAPI від LiteSpeed із MultiPHP Manager від cPanel, ви отримуєте ізоляцію версій PHP на рівні процесу для кожного домену, а не лише на рівні конфігурації. Це критична відмінність для агентств або розробників, які розміщують кілька клієнтських сайтів на одному обліковому записі спільного веб-хостингу.

Порівняння версій PHP: матриця функцій і безпеки

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

PHP 7.3: застаріла стабільність із відомими обмеженнями

PHP 7.3 був випуском, орієнтованим на обслуговування, який представив array_key_first(), array_key_last(), гнучкий синтаксис heredoc/nowdoc та функцію is_countable(). Він забезпечував стабільну платформу для застосунків, що працювали на PHP 5.x і потребували шляху міграції без агресивного рефакторингу.

Критична операційна реальність: PHP 7.3 досяг кінця підтримки у грудні 2021 року. Він не отримує патчів безпеки від проєкту PHP. Використання його у виробництві означає, що будь-яка нещодавно виявлена вразливість у Zend Engine або основних розширеннях залишиться без виправлення. Єдина законна причина використовувати PHP 7.3 на AlexHost сьогодні — підтримка застарілого застосунку під час активної міграції на PHP 8.x.

Поширений випадок використання: Старіші інсталяції Joomla 3.x, застарілі застосунки CodeIgniter 3 або власні кодові бази епохи PHP 5.6, які не були оновлені для використання сучасних оголошень типів.

PHP 7.4: останній у лінійці 7.x — корисний для перехідних розгортань

PHP 7.4 був фінальним випуском у гілці PHP 7 і представив кілька функцій, які зробили код значно зручнішим у підтримці та продуктивнішим без критичних змін, що з’явилися у PHP 8.0.

Типізовані властивості класу дозволяють застосовувати обмеження типів на рівні класу:

class User {
    public int $id;
    public string $email;
    public ?DateTime $lastLogin;
}

Це усуває цілу категорію помилок часу виконання, які раніше виявлялися лише за певних шляхів виконання.

Стрілкові функції зменшують багатослівність коротких замикань, особливо корисних в операціях із масивами:

$multiplied = array_map(fn($n) => $n * 2, $numbers);

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

PHP 7.4 досяг кінця підтримки у листопаді 2022 року. Він підходить для інсталяцій WordPress із застарілими плагінами, що мають відомі несумісності з PHP 8.x, або для розгортань Drupal 7, що очікують міграції.

PHP 8.0: архітектурна точка перегину

PHP 8.0 не був інкрементальним випуском. Він вніс зміни, що фундаментально змінили спосіб написання, виконання та аналізу PHP-коду. Кілька давніх поведінок були змінені або видалені, що зробило його критичним оновленням для кодових баз, що покладалися на нестрогу перевірку типів або застарілі функції.

JIT-компіляція

JIT-компілятор у PHP 8.0 компілює гарячі шляхи коду в нативний машинний код під час виконання, обходячи повторну інтерпретацію. У навантаженнях, обмежених CPU, — математичних обчисленнях, обробці зображень, конвеєрах перетворення даних — JIT може забезпечити суттєве прискорення. Однак для типових веб-застосунків, обмежених I/O (запити до бази даних, читання файлів, API-виклики), переваги JIT часто незначні, оскільки вузьким місцем є не виконання CPU, а очікування зовнішніх ресурсів.

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

Об’єднані типи та іменовані аргументи

Об’єднані типи дозволяють параметру функції або значенню, що повертається, явно приймати кілька типів:

function processInput(int|string $input): int|false {
    // ...
}

Іменовані аргументи відокремлюють порядок аргументів від сигнатур функцій, значно покращуючи читабельність у функціях із кількома необов’язковими параметрами:

array_slice(array: $data, offset: 2, length: 5, preserve_keys: true);

Вираз match

Вираз match замінює switch суворим порівнянням типів, без поведінки провалювання та поверненням на основі виразів:

$status = match($code) {
    200, 201 => 'success',
    404 => 'not found',
    500 => 'server error',
    default => 'unknown',
};

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

Атрибути (структуровані метадані)

Атрибути PHP 8.0 замінюють анотації docblock, що використовуються фреймворками, такими як Doctrine та Symfony. Вони аналізуються самим рушієм, а не регулярними виразами у просторі користувача:

#[Route('/api/users', methods: ['GET'])]
public function listUsers(): Response { ... }

Це має суттєві наслідки для продуктивності фреймворків і точності інструментів IDE.

PHP 8.1: сучасний PHP виробничого рівня

PHP 8.1 — це версія, на яку більшість нових проєктів повинна орієнтуватися на момент написання цього матеріалу. Вона будується на основі PHP 8.0 і додає функції, що усувають давні прогалини в системі типів мови та моделі паралелізму.

Перерахування

Enums вирішують проблему «магічних констант», що десятиліттями переслідувала кодові бази PHP:

enum Status: string {
    case Active = 'active';
    case Inactive = 'inactive';
    case Pending = 'pending';
}

Підкріплені enums можна зберігати в базах даних і серіалізувати без проблем. Чисті enums забезпечують типобезпечне представлення стану без крихкості констант класу або цілочисельних прапорів.

Fibers: кооперативна багатозадачність

Fibers вводять низькорівневий примітив паралелізму в PHP. На відміну від потоків, Fibers є кооперативними — вони явно передають управління. Це основа, яку асинхронні PHP-фреймворки (такі як ReactPHP та Amp) використовують для реалізації неблокуючого I/O без необхідності розширень, таких як Swoole:

$fiber = new Fiber(function(): void {
    $value = Fiber::suspend('first suspension');
    echo "Resumed with: " . $value;
});

$value = $fiber->start();
$fiber->resume('hello');

Для застосунків, що працюють на VPS-хостингу з повним контролем над середовищем виконання PHP, Fibers відкривають можливість створення застосунків на основі циклу подій на чистому PHP.

Властивості лише для читання

Властивості лише для читання забезпечують незмінність після ініціалізації, що є важливим для об’єктів-значень і доменних сутностей в архітектурах DDD (Domain-Driven Design):

class OrderId {
    public function __construct(
        public readonly string $value
    ) {}
}

Після встановлення в конструкторі $value не може бути змінено. Будь-яка спроба викидає Error. Це усуває цілий клас захисного програмного шаблону.

Типи перетину

Якщо об’єднані типи означають «це АБО те», то типи перетину означають «це І те» — вимагаючи, щоб значення реалізовувало кілька інтерфейсів одночасно:

function processEntity(Serializable&Countable $entity): void { ... }

Це особливо цінно в архітектурах контейнерів служб і конвеєрів проміжного програмного забезпечення.

Як змінити версії PHP на хостингу AlexHost LiteSpeed через cPanel

Середовища AlexHost на VPS із cPanel та спільному хостингу надають управління версіями PHP через MultiPHP Manager у cPanel. Ось точна процедура:

Крок 1: Доступ до панелі керування cPanel

Увійдіть до свого облікового запису AlexHost і перейдіть до розділу Login Details, щоб отримати облікові дані cPanel. Відкрийте cPanel безпосередньо через надану URL-адресу (зазвичай yourdomain.com:2083 або прямий IP із портом).

Крок 2: Перейдіть до MultiPHP Manager

У cPanel знайдіть розділ Software. Натисніть MultiPHP Manager. Цей інтерфейс відображає всі домени та субдомени, пов’язані з вашим обліковим записом, кожен із поточно призначеною версією PHP.

Крок 3: Виберіть цільовий домен і версію PHP

Поставте прапорець поруч із доменом або субдоменом, який ви хочете змінити. Використовуйте випадаючий список PHP Version, щоб вибрати з доступних версій — PHP 7.3, 7.4, 8.0 або 8.1 залежно від конфігурації вашого тарифного плану. Натисніть Apply.

Крок 4: Перевірте зміну

Після застосування зміна набуває чинності негайно для нових запитів. Перевірте, створивши тимчасовий файл phpinfo.php у кореневому каталозі документів домену:

<?php phpinfo(); ?>

Підтвердіть версію PHP у виводі, а потім негайно видаліть цей файл — залишення phpinfo() у виробництві є вразливістю безпеки, що розкриває конфігурацію вашого сервера зловмисникам.

Крок 5: Перевірте функціональність застосунку

Не припускайте, що зміна версії PHP є безпечною без тестування. Перевірте журнал помилок вашого застосунку (/home/username/logs/ або через інструмент Errors у cPanel) на наявність повідомлень про застарілі функції, фатальних помилок або викликів невизначених функцій, що вказують на несумісність.

Перевизначення версії PHP для окремого каталогу через .htaccess

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

<FilesMatch ".php$">
    SetHandler application/x-httpd-ea-php81
</FilesMatch>

Формат назви обробника — application/x-httpd-ea-phpXX, де XX відповідає номеру версії без десяткової крапки. Це конвенція EasyApache 4, що використовується в середовищах cPanel.

Матриця рішень для вибору версії PHP

Наслідки для безпеки при використанні версій PHP із завершеним терміном підтримки

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

• CVE, виявлені після EOL, не виправляються у відповідній гілці версії.
• Середовища спільного хостингу особливо вразливі, оскільки скомпрометований PHP-процес потенційно може впливати на сусідні облікові записи залежно від конфігурації ізоляції.
• Відповідність PCI DSS явно забороняє запуск програмного забезпечення після закінчення терміну підтримки від постачальника. Якщо ви обробляєте платежі, використання PHP 7.3 або 7.4 є порушенням відповідності.
• Брандмауери веб-застосунків (WAF) можуть зменшити деяку вразливість, але не можуть виправити вразливості на рівні рушія.

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

Особливості продуктивності PHP, специфічні для LiteSpeed

Кілька поведінок LiteSpeed взаємодіють із вибором версії PHP способами, які не є очевидними:

LiteSpeed Cache (LSCache): Плагін LSCache для WordPress працює на рівні веб-сервера, а не на рівні PHP. Однак покращені показники влучень OPcache у PHP 8.x означають, що промахи кешу обслуговуються швидше, зменшуючи штраф за продуктивність незакешованих запитів.

Постійність робочих процесів LSAPI: LiteSpeed зберігає PHP-воркери між запитами. Це означає, що JIT-компілятор PHP 8.1 має більше можливостей для прогрівання та оптимізації гарячих шляхів коду порівняно з традиційним налаштуванням CGI, де кожен запит запускає холодний процес.

PHP-FPM проти LSAPI: На панелях керування VPS, де ви самостійно налаштовуєте стек, ви можете вибирати між PHP-FPM та LSAPI. LSAPI стабільно перевершує PHP-FPM у бенчмарках для середовищ LiteSpeed, оскільки використовує спеціально розроблений протокол зв’язку, а не загальний інтерфейс FastCGI.

Ліміти пам’яті та кількість воркерів: PHP 8.x має дещо вищий базовий обсяг пам’яті порівняно з PHP 7.x через додаткові структури часу виконання для JIT та системи типів. Якщо ви працюєте в середовищі з обмеженою пам’яттю, відстежуйте налаштування memory_limit після оновлення.

Практичний контрольний список ключових висновків

Перш ніж змінювати або вибирати версію PHP на хостингу AlexHost LiteSpeed, пройдіть цей контрольний список:

• Перевірте офіційну матрицю сумісності PHP вашого застосунку — не здогадуйтесь. Laravel, WordPress, Magento та Drupal публікують мінімальні та максимальні підтримувані версії PHP.
• Перевірте встановлені плагіни та розширення — сторонній код є найпоширенішим джерелом несумісності з PHP 8.x. Запустіть composer check-platform-reqs, якщо використовуєте Composer.
• Спочатку протестуйте зміну — використовуйте субдомен або тестове середовище для перевірки зміни версії PHP перед застосуванням у виробництві.
• Перевірте журнали помилок одразу після перемикання — шукайте записи E_DEPRECATED, E_NOTICE та E_FATAL, що вказують на порушену сумісність.
• Видаліть будь-які файли phpinfo(), створені під час перевірки.
• Не використовуйте версії PHP із завершеним терміном підтримки у виробництві, якщо у вас немає задокументованого, обмеженого за часом плану міграції та компенсуючих засобів контролю безпеки.
• Використовуйте MultiPHP INI Editor (також у розділі Software у cPanel) для налаштування директив PHP для кожного домену, таких як memory_limit, upload_max_filesize та max_execution_time після зміни версії — значення за замовчуванням відрізняються між версіями.
• Якщо ваш застосунок вимагає PHP 8.2 або 8.3, розгляньте можливість переходу на тарифний план VPS, де ви контролюєте повний програмний стек і можете встановити будь-яку версію PHP через репозиторії, такі як Remi або ondrej/php.

Часті запитання

Чи можу я запускати різні версії PHP на різних доменах у межах одного облікового запису спільного хостингу AlexHost?

Так. MultiPHP Manager у cPanel застосовує налаштування версії PHP на рівні кожного домену. Кожен домен або субдомен у вашому обліковому записі може незалежно запускати різну версію PHP, керованою через той самий інтерфейс без впливу на інші домени.

Чи потребує перемикання версій PHP у MultiPHP Manager перезапуску сервера або спричиняє простій?

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

Чи автоматично прискорить JIT-компілятор PHP 8.1 мій сайт на WordPress?

Не суттєво для стандартних розгортань WordPress. JIT надає переваги навантаженням, обмеженим CPU. Продуктивність WordPress насамперед обмежена часом запитів до бази даних та операціями I/O, які JIT не прискорює. Більш значущими покращеннями PHP 8.x для WordPress є краща ефективність OPcache та зменшені накладні витрати на виклики функцій.

У чому різниця між MultiPHP Manager та MultiPHP INI Editor у cPanel?

MultiPHP Manager контролює, яка версія PHP призначена кожному домену. MultiPHP INI Editor контролює директиви конфігурації PHP (налаштування php.ini) для кожної комбінації домену та версії PHP. Обидва інструменти необхідні для повного управління середовищем PHP — вибір версії сам по собі не налаштовує ліміти пам’яті, тайм-аути виконання або завантаження розширень.

Що робити, якщо мій застосунок перестає працювати після оновлення до PHP 8.x?

Спочатку поверніться до попередньої версії PHP у MultiPHP Manager для відновлення сервісу. Потім перевірте журнали помилок на наявність конкретних повідомлень про помилки. Поширені проблеми включають видалені функції (each(), create_function()), змінену поведінку приведення типів та застарілі методи конструктора класу. Вирішіть кожну проблему в тестовому середовищі перед повторною спробою оновлення. Якщо застосунок є CMS або фреймворком, перевірте, чи існує оновлена версія, що офіційно підтримує PHP 8.x.