LiteSpeed Hosting i zarządzanie wersjami PHP: Kompletny przewodnik techniczny dla użytkowników AlexHost

Wybór odpowiedniej wersji PHP dla środowiska hostingowego jest jedną z najważniejszych decyzji przy wdrażaniu aplikacji webowych. Niewłaściwa wersja może po cichu obniżyć wydajność, wprowadzić luki bezpieczeństwa lub całkowicie zepsuć kompatybilność z frameworkiem. Hosting współdzielony AlexHost oparty na LiteSpeed obsługuje jednocześnie PHP 7.3, 7.4, 8.0 i 8.1, umożliwiając przypisanie różnych wersji PHP do poszczególnych domen za pomocą MultiPHP Manager w cPanel — bez modyfikowania plików konfiguracyjnych serwera ani otwierania zgłoszenia do pomocy technicznej.

Ten przewodnik omawia, co każda wersja PHP faktycznie dostarcza na poziomie silnika, jak prawidłowo przełączać wersje w infrastrukturze AlexHost oraz jak unikać typowych pułapek powodujących awarie aplikacji po zmianie wersji.

Dlaczego wybór wersji PHP ma większe znaczenie, niż większość deweloperów zdaje sobie sprawę

PHP nie jest monolitycznym środowiskiem uruchomieniowym. Każde główne i poboczne wydanie zmienia zachowanie Zend Engine, deprecjonuje funkcje, zmienia reguły koercji typów i modyfikuje sposób interakcji OPcache i kompilatora JIT z kodem. Uruchamianie kodu PHP 7.3 na PHP 8.1 bez testowania nie jest bezpiecznym uaktualnieniem — to hazard z środowiskiem produkcyjnym.

LiteSpeed Web Server obsługuje wykonywanie PHP przez LSAPI (LiteSpeed Server Application Programming Interface), który architektonicznie różni się od mod_php Apache’a lub FastCGI. LSAPI utrzymuje trwałe procesy robocze PHP, eliminując narzut związany z tworzeniem procesów dla każdego żądania, który obciąża tradycyjne konfiguracje. Rezultatem jest mierzalnie niższy czas do pierwszego bajtu (TTFB) i znacznie zmniejszona liczba cykli CPU na żądanie — szczególnie ważne dla aplikacji intensywnie korzystających z PHP, takich jak WordPress, Magento czy Laravel.

Połączenie LSAPI LiteSpeed z MultiPHP Manager cPanel zapewnia izolację wersji PHP na poziomie procesu dla każdej domeny, nie tylko na poziomie konfiguracji. To kluczowe rozróżnienie dla agencji lub deweloperów hostujących wiele witryn klientów na jednym koncie Hostingu Współdzielonego.

Porównanie wersji PHP: macierz funkcji i bezpieczeństwa

Kluczowy wniosek z tej tabeli: PHP 7.3 i 7.4 przekroczyły oficjalne daty końca życia. Powinny być używane wyłącznie wtedy, gdy starsza aplikacja ma twarde zależności, których nie można rozwiązać — nie jako domyślny wybór dla nowych wdrożeń.

PHP 7.3: Stabilność starszych wersji ze znanymi ograniczeniami

PHP 7.3 było wydaniem skoncentrowanym na konserwacji, które wprowadziło array_key_first(), array_key_last(), elastyczną składnię heredoc/nowdoc oraz funkcję is_countable(). Stanowiło stabilną platformę dla aplikacji działających na PHP 5.x, które potrzebowały ścieżki migracji bez agresywnego refaktoryzowania.

Krytyczna rzeczywistość operacyjna: PHP 7.3 osiągnął koniec życia w grudniu 2021 roku. Nie otrzymuje żadnych poprawek bezpieczeństwa od projektu PHP. Uruchamianie go w środowisku produkcyjnym oznacza, że każda nowo odkryta luka w Zend Engine lub podstawowych rozszerzeniach pozostanie niezałatana. Jedynym uzasadnionym powodem używania PHP 7.3 na AlexHost jest dziś utrzymanie starszej aplikacji podczas aktywnej migracji do PHP 8.x.

Typowy przypadek użycia: Starsze instalacje Joomla 3.x, starsze aplikacje CodeIgniter 3 lub niestandardowe bazy kodu z ery PHP 5.6, które nie zostały zaktualizowane do używania nowoczesnych deklaracji typów.

PHP 7.4: Ostatnia z linii 7.x — przydatna do wdrożeń przejściowych

PHP 7.4 było ostatnim wydaniem w gałęzi PHP 7 i wprowadziło kilka funkcji, które znacznie poprawiły możliwości utrzymania i wydajność kodu bez wymagania przełomowych zmian, które pojawiły się w PHP 8.0.

Typowane właściwości klas pozwalają wymuszać ograniczenia typów na poziomie klasy:

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

Eliminuje to całą kategorię błędów czasu wykonania, które wcześniej ujawniały się tylko w określonych ścieżkach wykonania.

Funkcje strzałkowe redukują rozwlekłość krótkich domknięć, szczególnie przydatnych w operacjach na tablicach:

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

Wstępne ładowanie OPcache (wprowadzone w 7.4) ma znaczenie architektoniczne: pozwala PHP załadować i skompilować zestaw plików do pamięci współdzielonej podczas uruchamiania serwera, udostępniając te pliki wszystkim procesom roboczym bez wielokrotnej kompilacji. W LiteSpeed z LSAPI zwielokrotnia to korzyść wydajnościową, ponieważ trwałe procesy robocze już unikają narzutu związanego z tworzeniem procesów.

PHP 7.4 osiągnął koniec życia w listopadzie 2022 roku. Jest odpowiedni dla instalacji WordPress uruchamiających starsze wtyczki ze znanymi niezgodnościami z PHP 8.x lub dla wdrożeń Drupal 7 wciąż oczekujących na migrację.

PHP 8.0: Architektoniczny punkt zwrotny

PHP 8.0 nie było wydaniem przyrostowym. Wprowadziło zmiany, które fundamentalnie zmieniły sposób pisania, wykonywania i rozumowania kodu PHP. Kilka długo istniejących zachowań zostało zmienionych lub usuniętych, co czyni je przełomowym uaktualnieniem dla baz kodu opartych na luźnej koercji typów lub przestarzałych funkcjach.

Kompilacja Just-In-Time

Kompilator JIT w PHP 8.0 kompiluje gorące ścieżki kodu do natywnego kodu maszynowego w czasie wykonania, omijając wielokrotną interpretację. W obciążeniach związanych z CPU — obliczeniach matematycznych, przetwarzaniu obrazów, potokach transformacji danych — JIT może zapewnić znaczne przyspieszenie. Jednak w typowych aplikacjach webowych związanych z I/O (zapytania do bazy danych, odczyty plików, wywołania API) korzyść z JIT jest często marginalna, ponieważ wąskim gardłem nie jest wykonanie CPU, lecz oczekiwanie na zasoby zewnętrzne.

Zrozumienie tej różnicy zapobiega powszechnemu błędowi polegającemu na oczekiwaniu, że JIT automatycznie przyspieszy witrynę WordPress. Nie przyspieszy — chyba że witryna wykonuje znaczące obliczenia wewnątrz procesu.

Typy unii i nazwane argumenty

Typy unii pozwalają parametrowi funkcji lub wartości zwracanej jawnie akceptować wiele typów:

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

Nazwane argumenty oddzielają kolejność argumentów od sygnatur funkcji, znacznie poprawiając czytelność w funkcjach z wieloma opcjonalnymi parametrami:

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

Wyrażenie match

Wyrażenie match zastępuje switch ścisłym porównaniem typów, bez zachowania fall-through i zwrotami opartymi na wyrażeniach:

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

W przeciwieństwie do switch, match rzuca UnhandledMatchError, jeśli żadne ramię nie pasuje i nie podano wartości domyślnej — co uniemożliwia ciche awarie.

Atrybuty (metadane strukturalne)

Atrybuty PHP 8.0 zastępują adnotacje docblock używane przez frameworki takie jak Doctrine i Symfony. Są parsowane przez sam silnik, a nie przez wyrażenia regularne w przestrzeni użytkownika:

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

Ma to istotne implikacje dla wydajności frameworka i dokładności narzędzi IDE.

PHP 8.1: Nowoczesne PHP klasy produkcyjnej

PHP 8.1 to wersja, na którą większość nowych projektów powinna być ukierunkowana w chwili pisania tego tekstu. Opiera się na fundamencie PHP 8.0 i dodaje funkcje, które wypełniają długo istniejące luki w systemie typów języka i modelu współbieżności.

Wyliczenia

Enums rozwiązują problem „magicznych stałych”, który nękał bazy kodu PHP przez dziesięciolecia:

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

Wspierane enums mogą być przechowywane w bazach danych i czysto serializowane. Czyste enums zapewniają bezpieczną typowo reprezentację stanu bez kruchości stałych klas lub flag całkowitoliczbowych.

Fibry: kooperatywna wielozadaniowość

Fibry wprowadzają do PHP niskopoziomowy prymityw współbieżności. W przeciwieństwie do wątków, fibry są kooperatywne — jawnie oddają kontrolę. To fundament, którego asynchroniczne frameworki PHP (takie jak ReactPHP i Amp) używają do implementacji nieblokującego I/O bez wymagania rozszerzeń takich jak Swoole:

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

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

Dla aplikacji działających na Hostingu VPS z pełną kontrolą nad środowiskiem uruchomieniowym PHP, fibry otwierają drzwi do budowania aplikacji opartych na pętli zdarzeń w czystym PHP.

Właściwości tylko do odczytu

Właściwości tylko do odczytu wymuszają niezmienność po inicjalizacji, co jest niezbędne dla obiektów wartości i encji domenowych w architekturach DDD (Domain-Driven Design):

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

Po ustawieniu w konstruktorze $value nie można modyfikować. Każda próba rzuca Error. Eliminuje to całą klasę defensywnego szablonu programistycznego.

Typy przecięcia

Podczas gdy typy unii mówią „to LUB tamto”, typy przecięcia mówią „to I tamto” — wymagając, aby wartość implementowała jednocześnie wiele interfejsów:

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

Jest to szczególnie cenne w architekturach kontenerów usług i potoków middleware.

Jak zmienić wersje PHP na hostingu LiteSpeed AlexHost przez cPanel

Środowiska VPS z cPanel i hostingu współdzielonego AlexHost udostępniają zarządzanie wersjami PHP przez MultiPHP Manager cPanel. Oto dokładna procedura:

Krok 1: Dostęp do panelu cPanel

Zaloguj się na swoje konto AlexHost i przejdź do sekcji Dane logowania, aby pobrać dane uwierzytelniające cPanel. Otwórz cPanel bezpośrednio przez podany URL (zazwyczaj yourdomain.com:2083 lub bezpośredni IP z portem).

Krok 2: Przejdź do MultiPHP Manager

W cPanel znajdź sekcję Oprogramowanie. Kliknij MultiPHP Manager. Ten interfejs wyświetla wszystkie domeny i subdomeny powiązane z Twoim kontem, każda z aktualnie przypisaną wersją PHP.

Krok 3: Wybierz docelową domenę i wersję PHP

Zaznacz pole wyboru obok domeny lub subdomeny, którą chcesz zmodyfikować. Użyj listy rozwijanej Wersja PHP, aby wybrać spośród dostępnych wersji — PHP 7.3, 7.4, 8.0 lub 8.1 w zależności od konfiguracji planu hostingowego. Kliknij Zastosuj.

Krok 4: Zweryfikuj zmianę

Po zastosowaniu zmiana natychmiast wchodzi w życie dla nowych żądań. Zweryfikuj, tworząc tymczasowy plik phpinfo.php w katalogu głównym dokumentów domeny:

<?php phpinfo(); ?>

Potwierdź wersję PHP w danych wyjściowych, a następnie natychmiast usuń ten plik — pozostawienie phpinfo() w środowisku produkcyjnym jest luką bezpieczeństwa, która ujawnia konfigurację serwera atakującym.

Krok 5: Przetestuj funkcjonalność aplikacji

Nie zakładaj, że zmiana wersji PHP jest bezpieczna bez testowania. Sprawdź dziennik błędów aplikacji (/home/username/logs/ lub przez narzędzie Błędy cPanel) pod kątem powiadomień o przestarzałości, błędów krytycznych lub wywołań niezdefiniowanych funkcji wskazujących na niezgodność.

Nadpisanie wersji PHP dla katalogu przez .htaccess

Dla szczegółowej kontroli — na przykład uruchamiania starszego podkatalogu na PHP 7.4, podczas gdy główna witryna działa na PHP 8.1 — możesz nadpisać wersję PHP na poziomie katalogu używając .htaccess:

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

Format nazwy handlera to application/x-httpd-ea-phpXX, gdzie XX odpowiada numerowi wersji bez kropki dziesiętnej. Jest to konwencja EasyApache 4 używana w środowiskach cPanel.

Macierz decyzyjna wyboru wersji PHP

Implikacje bezpieczeństwa uruchamiania wersji PHP po zakończeniu życia

Ten punkt zasługuje na wyraźne podkreślenie. Wersje PHP po dacie końca życia nie otrzymują poprawek bezpieczeństwa od projektu PHP. Oznacza to:

• CVE odkryte po EOL nie są łatane w gałęzi dotkniętej wersji.
• Środowiska hostingu współdzielonego są szczególnie narażone, ponieważ skompromitowany proces PHP może potencjalnie wpłynąć na sąsiednie konta w zależności od konfiguracji izolacji.
• Zgodność z PCI DSS wyraźnie zabrania uruchamiania oprogramowania po dacie końca życia obsługiwanej przez dostawcę. Jeśli przetwarzasz płatności, uruchamianie PHP 7.3 lub 7.4 jest naruszeniem zgodności.
• Zapory aplikacji webowych (WAF) mogą łagodzić pewne narażenie, ale nie mogą łatać luk na poziomie silnika.

Jeśli potrzebujesz pełnej kontroli nad środowiskiem PHP, harmonogramem łatania bezpieczeństwa i możliwością kompilowania niestandardowych rozszerzeń PHP, Serwer Dedykowany zapewnia izolację i dostęp administracyjny, których środowiska współdzielone nie mogą zapewnić.

Zagadnienia wydajności PHP specyficzne dla LiteSpeed

Kilka zachowań LiteSpeed wchodzi w interakcję z wyborem wersji PHP w sposób, który nie jest oczywisty:

LiteSpeed Cache (LSCache): Wtyczka LSCache dla WordPress działa na poziomie serwera webowego, a nie PHP. Jednak ulepszone współczynniki trafień OPcache PHP 8.x oznaczają, że chybienia pamięci podręcznej są obsługiwane szybciej, zmniejszając karę wydajnościową dla żądań niebuforowanych.

Trwałość procesów roboczych LSAPI: LiteSpeed utrzymuje procesy robocze PHP aktywne między żądaniami. Oznacza to, że kompilator JIT PHP 8.1 ma więcej możliwości rozgrzania i optymalizacji gorących ścieżek kodu w porównaniu z tradycyjną konfiguracją CGI, gdzie każde żądanie uruchamia zimny proces.

PHP-FPM vs. LSAPI: Na Panelach Sterowania VPS, gdzie samodzielnie konfigurujesz stos, możesz wybierać między PHP-FPM a LSAPI. LSAPI konsekwentnie przewyższa PHP-FPM w testach porównawczych dla środowisk LiteSpeed, ponieważ używa dedykowanego protokołu komunikacyjnego zamiast ogólnego interfejsu FastCGI.

Limity pamięci i liczba procesów roboczych: PHP 8.x ma nieco wyższy bazowy ślad pamięci niż PHP 7.x ze względu na dodatkowe struktury czasu wykonania dla JIT i systemu typów. Jeśli działasz w środowisku z ograniczoną pamięcią, monitoruj ustawienia memory_limit po uaktualnieniu.

Praktyczna lista kontrolna kluczowych wniosków

Przed zmianą lub wyborem wersji PHP na hostingu LiteSpeed AlexHost, przejdź przez tę listę kontrolną:

• Sprawdź oficjalną macierz kompatybilności PHP swojej aplikacji — nie zgaduj. Laravel, WordPress, Magento i Drupal publikują minimalne i maksymalne obsługiwane wersje PHP.
• Przeprowadź audyt zainstalowanych wtyczek i rozszerzeń — kod stron trzecich jest najczęstszym źródłem niezgodności z PHP 8.x. Uruchom composer check-platform-reqs, jeśli używasz Composer.
• Najpierw przetestuj zmianę na środowisku testowym — użyj subdomeny lub środowiska testowego, aby przetestować zmianę wersji PHP przed zastosowaniem jej w środowisku produkcyjnym.
• Przejrzyj dzienniki błędów natychmiast po przełączeniu — szukaj wpisów E_DEPRECATED, E_NOTICE i E_FATAL wskazujących na zepsutą kompatybilność.
• Usuń wszelkie pliki phpinfo() utworzone podczas weryfikacji.
• Nie uruchamiaj wersji PHP po EOL w środowisku produkcyjnym, chyba że masz udokumentowany, ograniczony czasowo plan migracji i kompensujące kontrole bezpieczeństwa.
• Użyj MultiPHP INI Editor (również w sekcji Oprogramowanie cPanel), aby dostroić dyrektywy PHP dla poszczególnych domen, takie jak memory_limit, upload_max_filesize i max_execution_time po zmianie wersji — wartości domyślne różnią się między wersjami.
• Jeśli Twoja aplikacja wymaga PHP 8.2 lub 8.3, rozważ uaktualnienie do planu VPS, gdzie kontrolujesz pełny stos oprogramowania i możesz zainstalować dowolną wersję PHP przez repozytoria takie jak Remi lub ondrej/php.

Często zadawane pytania

Czy mogę uruchamiać różne wersje PHP na różnych domenach w ramach tego samego konta hostingu współdzielonego AlexHost?

Tak. MultiPHP Manager cPanel stosuje ustawienia wersji PHP na poziomie poszczególnych domen. Każda domena lub subdomena na Twoim koncie może niezależnie uruchamiać inną wersję PHP, zarządzaną przez ten sam interfejs bez wpływu na inne domeny.

Czy przełączanie wersji PHP w MultiPHP Manager wymaga restartu serwera lub powoduje przestój?

Nie. Zmiana natychmiast wchodzi w życie dla nowych przychodzących żądań. Istniejące długo działające procesy PHP mogą kontynuować na starej wersji do momentu ich zakończenia, ale dla typowych żądań webowych to przejście jest płynne i nie powoduje mierzalnego przestoju.

Czy kompilator JIT PHP 8.1 automatycznie przyspieszy moją witrynę WordPress?

Nie znacząco dla standardowych wdrożeń WordPress. JIT przynosi korzyści obciążeniom związanym z CPU. Wydajność WordPress jest przede wszystkim ograniczona przez czas zapytań do bazy danych i operacje I/O, których JIT nie przyspiesza. Bardziej znaczące ulepszenia PHP 8.x dla WordPress to lepsza wydajność OPcache i zmniejszony narzut wywołań funkcji.

Jaka jest różnica między MultiPHP Manager a MultiPHP INI Editor w cPanel?

MultiPHP Manager kontroluje, która wersja PHP jest przypisana do każdej domeny. MultiPHP INI Editor kontroluje dyrektywy konfiguracyjne PHP (ustawienia php.ini) dla każdej kombinacji domeny i wersji PHP. Oba narzędzia są wymagane do pełnego zarządzania środowiskiem PHP — sam wybór wersji nie konfiguruje limitów pamięci, limitów czasu wykonania ani ładowania rozszerzeń.

Co powinienem zrobić, jeśli moja aplikacja przestaje działać po uaktualnieniu do PHP 8.x?

Najpierw przywróć poprzednią wersję PHP w MultiPHP Manager, aby przywrócić usługę. Następnie przejrzyj dzienniki błędów w poszukiwaniu konkretnych komunikatów o błędach. Typowe problemy obejmują usunięte funkcje (each(), create_function()), zmienione zachowanie koercji typów i przestarzałe metody klas w stylu konstruktora. Rozwiąż każdy problem w środowisku testowym przed ponowną próbą uaktualnienia. Jeśli aplikacja jest CMS lub frameworkiem, sprawdź, czy istnieje zaktualizowana wersja, która oficjalnie obsługuje PHP 8.x.