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 | PHP 7.4 | PHP 8.0 | PHP 8.1 |
|---|---|---|---|---|
| Официальная поддержка безопасности | Завершена дек. 2021 | Завершена ноя. 2022 | Завершена ноя. 2023 | Завершена ноя. 2024 |
| JIT-компилятор | Нет | Нет | Да (экспериментальный) | Да (улучшенный) |
| Типизированные свойства | Нет | Да | Да | Да |
| Стрелочные функции | Нет | Да | Да | Да |
| Union-типы | Нет | Нет | Да | Да |
| Именованные аргументы | Нет | Нет | Да | Да |
| Выражение match | Нет | Нет | Да | Да |
| Атрибуты (аннотации) | Нет | Нет | Да | Да |
| Перечисления (Enums) | Нет | Нет | Нет | Да |
| Файберы (корутины) | Нет | Нет | Нет | Да |
| Readonly-свойства | Нет | Нет | Нет | Да |
| Пересекающиеся типы | Нет | Нет | Нет | Да |
| Nullsafe-оператор | Нет | Нет | Да | Да |
| Предзагрузка OPcache | Нет | Да | Да | Да |
| Относительная производительность к 7.3 | Базовая | +~5-10% | +~15-20% | +~20-25% |
Ключевой вывод из этой таблицы: 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. Этого не произойдёт — если только сайт не выполняет значительные вычисления внутри процесса.
Union-типы и именованные аргументы
Union-типы позволяют параметру функции или возвращаемому значению явно принимать несколько типов:
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';
}Backed-перечисления можно хранить в базах данных и чисто сериализовать. Чистые перечисления обеспечивают типобезопасное представление состояния без хрупкости констант класса или целочисленных флагов.
Файберы: кооперативная многозадачность
Файберы вводят низкоуровневый примитив параллелизма в PHP. В отличие от потоков, файберы кооперативны — они явно передают управление. Это основа, которую асинхронные 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, файберы открывают возможность создания приложений на основе цикла событий на чистом PHP.
Readonly-свойства
Readonly-свойства обеспечивают неизменяемость после инициализации, что необходимо для объектов-значений и доменных сущностей в архитектурах DDD (Domain-Driven Design):
class OrderId {
public function __construct(
public readonly string $value
) {}
}После установки в конструкторе $value не может быть изменено. Любая попытка выбрасывает Error. Это устраняет целый класс шаблонного защитного кода.
Пересекающиеся типы
Там где union-типы говорят «это ИЛИ то», пересекающиеся типы говорят «это И то» — требуя, чтобы значение реализовывало несколько интерфейсов одновременно:
function processEntity(Serializable&Countable $entity): void { ... }Это особенно ценно в архитектурах контейнеров сервисов и конвейеров промежуточного программного обеспечения.
Как изменить версии PHP на хостинге AlexHost LiteSpeed через cPanel
Среды VPS с cPanel и общего хостинга AlexHost предоставляют управление версиями PHP через MultiPHP Manager в cPanel. Вот точная процедура:
Шаг 1: Войдите в панель управления cPanel
Войдите в свой аккаунт AlexHost и перейдите в раздел Данные для входа, чтобы получить учётные данные cPanel. Откройте cPanel напрямую по предоставленному URL (обычно yourdomain.com:2083 или прямой IP с портом).
Шаг 2: Перейдите в MultiPHP Manager
В cPanel найдите раздел Программное обеспечение. Нажмите MultiPHP Manager. В этом интерфейсе перечислены все домены и поддомены, связанные с вашим аккаунтом, каждый с отображаемой текущей назначенной версией PHP.
Шаг 3: Выберите целевой домен и версию PHP
Установите флажок рядом с доменом или поддоменом, который хотите изменить. Используйте раскрывающийся список Версия PHP, чтобы выбрать из доступных версий — PHP 7.3, 7.4, 8.0 или 8.1 в зависимости от конфигурации вашего тарифного плана. Нажмите Применить.
Шаг 4: Проверьте изменение
После применения изменение вступает в силу немедленно для новых запросов. Проверьте, создав временный файл phpinfo.php в корневом каталоге документов домена:
<?php phpinfo(); ?>Подтвердите версию PHP в выводе, затем немедленно удалите этот файл — оставление phpinfo() в производственной среде является уязвимостью безопасности, раскрывающей конфигурацию вашего сервера злоумышленникам.
Шаг 5: Протестируйте функциональность приложения
Не считайте изменение версии PHP безопасным без тестирования. Проверьте журнал ошибок вашего приложения (/home/username/logs/ или через инструмент Ошибки в 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 | Обоснование |
|---|---|---|
| Новый проект на Laravel 10+ или Symfony 6+ | PHP 8.1 | Требует минимум PHP 8.1; полная поддержка функций |
| WordPress 6.x (все плагины обновлены) | PHP 8.1 | Официальная рекомендация; прирост производительности |
| WordPress с устаревшими плагинами (до 2022 г.) | PHP 7.4 или 8.0 | Проверьте совместимость перед обновлением |
| Magento 2.4.6+ | PHP 8.1 | Официальная матрица поддержки требует 8.1 |
| Drupal 10 | PHP 8.1 | Минимальное требование |
| Устаревший Joomla 3.x | PHP 7.3 или 7.4 | Joomla 3.x не полностью совместима с PHP 8.x |
| Пользовательское устаревшее приложение (до 2018 г.) | PHP 7.3 | Мигрируйте как можно скорее |
| Новый API-микросервис или CLI-инструмент | PHP 8.1 | Доступны Enums, Fibers, readonly-свойства |
Последствия для безопасности при использовании версий 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 (также в разделе «Программное обеспечение» 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.
