Selektor PHP w hostingu współdzielonym: bezpieczne równoległe korzystanie z różnych wersji PHP

Co kontroluje selektor PHP

A Selektor PHP jest interfejsem administracyjnym dla środowisk uruchomieniowych PHP udostępnianym przez operatora serwera. Za jego pomocą możesz, w zależności od konfiguracji hostingu, wybrać gałąź PHP oraz powiązane rozszerzenia lub opcje. Interfejs nie instaluje automatycznie każdej wybranej wersji i nie gwarantuje również, że każdy wybór będzie obowiązywał oddzielnie dla poszczególnych domen.

W procesie planowania istotne są trzy poziomy: na serwerze może znajdować się kilka wersji zainstalowane ; w ramach taryfy dostawca może jednak udostępnić do wyboru tylko część z nich. To, która wersja faktycznie zostanie wykonana w przypadku konkretnego zapytania, zależy ponadto od konfiguracji domeny, serwera WWW oraz odpowiedniego modułu obsługi PHP. Sama widoczna pozycja w menu nie daje odpowiedzi na to ostatnie pytanie.

CloudLinux oferuje alternatywne środowiska uruchomieniowe jako Stara wersja PHP gotowe. Oprócz tego istnieje natywne środowisko PHP serwera lub panelu sterowania. Termin „natywne” nie odnosi się tutaj do konkretnego numeru wersji: o tym, jaka wersja PHP i jaka konfiguracja są za tym stoją, decyduje dane środowisko serwerowe. Dlatego też po przejściu na środowisko natywne aplikacja może napotkać inne wymagania niż w przypadku wyboru starszej wersji PHP.

Jeśli potrzebujesz konkretnej wersji PHP dla swojego hostingu, najpierw sprawdź wymagania aplikacji, a następnie zapytaj o faktyczną dostępność tej wersji w ramach wybranego pakietu. Upewnij się również, czy możliwe jest dostosowanie wymaganych rozszerzeń i ustawień. Opisane funkcje CloudLinux przedstawiają możliwości oprogramowania, a nie automatycznie wyposażenie konkretnego pakietu hostingowego.

Konta, domeny i izolacja

Wyobraź sobie aktualną stronę internetową i starszą aplikację biznesową, które wymagają różnych gałęzi PHP. Jeśli znajdują się one na oddzielnych kontach hostingowych, mogą korzystać z różnych wersji, pod warunkiem że oba konta mają własny wybór selektora, a dostawca udostępnia wymagane gałęzie. Jest to możliwa eksploatacja równoległa na tym samym serwerze, ale nie jest to gwarantowane w przypadku każdego planu taryfowego.

Inaczej wygląda sytuacja w przypadku dwóch domen w ramach tego samego konta. CloudLinux opisuje wybór selektora, który ma zastosowanie do wszystkich domen użytkownika zarządzanych przez ten selektor. Jeśli zmienisz tam wersję, musisz zatem liczyć się z konsekwencjami dla obu aplikacji; sam fakt istnienia selektora nie powoduje automatycznego wyboru domeny.

Der Zakres zastosowania Dlatego przed każdą zmianą należy to wyjaśnić. Jeśli dostawca nie obsługuje odpowiedniego zarządzania na poziomie domen, rozwiązaniem mogą być oddzielne konta. W tym celu należy odpowiednio przenieść aplikacje i sprawdzić warunki poszczególnych taryf. Sama druga domena lub dodatkowy katalog nie zapewniają jeszcze niezależnego wyboru wersji.

W środowisku wieloużytkownikowym CloudLinux system CageFS służy do oddzielania środowisk użytkowników. Te Izolacja należy odróżnić to od kwestii, jaką wersję PHP można ustawić dla danej domeny. Również dodatkowa izolacja stron internetowych w ramach jednego konta sama w sobie nie świadczy o niezależnym wyborze selektora; więcej na temat tej koncepcji wyjaśnia artykuł poświęcony CageFS na poszczególnych stronach w ramach hostingu współdzielonego.

CloudLinux opisuje również specjalną konfigurację Selector bez włączonego CageFS dla serwera z jednym kontem użytkownika. Nie oznacza to jednak, że zaleca się wyłączenie CageFS na zwykłym serwerze z hostingiem współdzielonym. Za architekturę bezpieczeństwa i jej konfigurację odpowiada operator; jako klient powinieneś zapytać o oferowaną izolację i jej zakres.

Selector i MultiPHP Manager

CloudLinux PHP Selector i cPanel MultiPHP Manager to różne narzędzia. Selector zarządza udostępnionymi opcjami PHP w ramach swojej integracji; MultiPHP Manager umożliwia zarządzanie ustawieniami PHP w odniesieniu do poszczególnych domen. Fakt, że jeden z tych interfejsów obsługuje ustawienia związane z domenami, nie oznacza jednak, że są one dostępne w ramach danego pakietu lub udostępnione dla każdej kombinacji.

W udokumentowanej współpracy z cPanel firma CloudLinux wymienia między innymi następujące elementy niezbędne do korzystania z selektora: Ustawienie systemowe w MultiPHP Managerze oraz wyłączony moduł PHP-FPM dla danej domeny. Warunki te opisują konkretną integrację, a nie uniwersalną instrukcję krok po kroku. To, w jaki sposób dostawca usług hostingowych skonfigurował moduł obsługi i interfejsy, decyduje o tym, które ustawienie będzie obowiązywać.

Jeśli widoczne są obie interfejsy, nie należy ustalać ich zakresu działania metodą prób i błędów na działającej stronie internetowej. Ustawienie związane z domeną w MultiPHP Managerze oraz wybór selektora mogą w przeciwnym razie wywołać oczekiwania, które nie będą odpowiadały faktycznie używanemu handlerowi. Poproś dostawcę o wyjaśnienie, które narzędzie ma zastosowanie do danej domeny oraz jakie zmiany mogą wpłynąć na inne domeny.

W podjęciu konkretnej decyzji pomocne mogą być następujące pytania: Jaki interfejs jest dostępny w ramach pakietu? Czy wybór dotyczy jednego konta czy jednej domeny oraz jakie wersje PHP i rozszerzenia są dozwolone? Należy również zapytać, czy dostępne są SSH i zaplanowane zadania oraz jaki interpreter je wykonuje. Dzięki temu można oddzielnie planować aplikacje internetowe i zadania w tle, zamiast wyciągać wnioski na temat wszystkich ścieżek wykonania na podstawie wyświetlanych w panelu informacji.

Na koniec należy ustalić, czy dostępne jest odizolowane środowisko testowe oraz kopia zapasowa, a także kto będzie w stanie przywrócić dotychczasową konfigurację w razie awarii. Dopiero po ustaleniu, kto odpowiada za interfejs użytkownika i który obszar jest nim objęty, można przygotować się do zmiany przy rozsądnym poziomie ryzyka. Niepotwierdzone pozycje menu lub rzekomo uniwersalne rozwiązanie konfiguracyjne nie są tu żadną pomocą.

Wybierz odpowiedni zakres obowiązywania

Zanim zmienisz wersję PHP na serwerze hostingowym, upewnij się, że Zakres zastosowania dostępnych opcji. Decydujące znaczenie ma nie tylko liczba domen, które obsługujesz, ale także to, które z nich korzystają z tego samego użytkownika i tego samego wyboru selektora. Tabela przedstawia typowe wymagania w formie pytań, które możesz omówić ze swoim dostawcą.

CloudLinux Selector stosuje swoje ustawienia w sposób udokumentowany do domen użytkownika, którymi zarządza. Jeśli dwie aplikacje na tym samym koncie wymagają różnych wersji, pomocne może być rozdzielenie ich na różne konta, o ile pozwala na to plan taryfowy i dostępne wersje. O dodatkowych kosztach i warunkach należy zapytać dostawcę.

Inną opcją jest wyraźnie obsługiwane zarządzanie na poziomie domeny, na przykład za pomocą narzędzia cPanel MultiPHP Manager. Nie ma jednak uniwersalnej zasady określającej, czy funkcja ta jest dostępna w konkretnym pakiecie taryfowym i jak współdziała z selektorem. Również zmiana za pośrednictwem .htaccess nie powinieneś zakładać, że będzie to niezawodny zamiennik.

Rozdzielenie wersji nie rozwiązuje ponadto wszystkich zależności: aplikacja może wymagać określonych modułów lub ustawień, podczas gdy zaplanowane zlecenie korzysta z własnego interpretera. Należy oddzielnie określić te wymagania, aby zwrócić się do dostawcy nie tylko o numer wersji, ale o pełną ścieżkę wykonania.

Sprawdź wersję PHP i wsparcie techniczne

Wybierz gałąź PHP, którą obsługuje Twoja konkretna aplikacja i dla której dostępne są poprawki bezpieczeństwa. W tym celu sprawdź wymagania stosowanej wersji systemu CMS lub sklepu internetowego, a także wtyczek, motywów, bibliotek i własnego kodu. Sama aktualna wersja PHP nie gwarantuje automatycznie, że starsza, niekompatybilna aplikacja będzie działać.

Oficjalna tabela PHP rozróżnia aktywne wsparcie a następnie etap wprowadzania poprawek bezpieczeństwa. Zgodnie z danymi z 4 listopada 2026 r. wersje PHP 8.2 i 8.3 otrzymują już wyłącznie poprawki bezpieczeństwa; wersje PHP 8.4 i 8.5 są objęte aktywnym wsparciem. Oficjalne wsparcie w zakresie bezpieczeństwa dla PHP 8.2 kończy się 31 grudnia 2026 r. Przed podjęciem decyzji sprawdź ponownie status, ponieważ klasyfikacja ta może ulec zmianie z upływem czasu.

Wyświetlenie wersji w selektorze odpowiada na inne pytanie niż tabela wsparcia: pokazuje wybór dostępny w Twoim środowisku, ale nie potwierdza ani oficjalnego wsparcia, ani kompatybilności Twojej aplikacji. Z drugiej strony fakt, że dana gałąź jest oficjalnie obsługiwana, nie oznacza, że Twój plan hostingowy ją oferuje.

Dostawca może ewentualnie oferować własne przedłużone wsparcie techniczne dla starszych pakietów. W tym celu należy ustalić na piśmie, jakie pakiety i poprawki bezpieczeństwa obejmuje to wsparcie, jak długo będzie trwało oraz w jaki sposób będą udostępniane aktualizacje. To Pomoc techniczna dostawcy nie należy utożsamiać z oficjalnym wsparciem projektu PHP i nie zastępuje planu migracji aplikacji.

Jeśli planujesz przejście na nowszą gałąź, sprawdź również pominięte etapy migracji i zadania działające w tle. Artykuł na temat PHP 8.5 w hostingu i do sprawdzania zgodności wyjaśnia, jakie zależności i procesy mogą mieć znaczenie w przypadku tej konkretnej zmiany wersji.

Kontrolowane przygotowanie do zmiany

Zacznij od sporządzenia zestawienia: jaka platforma jest do Twojej dyspozycji, jakie domeny są przez nią zarządzane i jakie wersje PHP są dostępne dla Twojego konta? Zanotuj dotychczasowy wybór, a w razie niejasności zapytaj o faktyczny zakres usług. W ten sposób unikniesz sytuacji, w której rzekomo migrujesz tylko jedną stronę internetową, podczas gdy w rzeczywistości dotyczy to również innych domen.

Załóżmy, że aktualna aplikacja i starsza aplikacja działają równolegle. Najpierw sprawdź, czy ich wymagania są zgodne ze wspólną wersją docelową. Jeśli nie, pomocne może być dokonanie osobnego wyboru na oddzielnych kontach; alternatywa oparta na domenie wchodzi w grę tylko wtedy, gdy dostawca obsługuje ją w Twojej konfiguracji.

Przed wprowadzeniem zmian w środowisku produkcyjnym sprawdź, czy aktualna Kopia zapasowa plików i bazy danych oraz że sposób ich przywrócenia jest jasno określony. Pomocne jest odizolowane środowisko testowe, o ile możesz je zapewnić: tam możesz przetestować docelową wersję bez niepotrzebnego narażania odwiedzających lub danych produkcyjnych. To, czy plan taryfowy zapewnia środowisko stagingowe lub kopie zapasowe, należy wyjaśnić z dostawcą.

Oprócz dotychczasowej i pożądanej wersji PHP należy również udokumentować wymagane rozszerzenia oraz istotne opcje. Należy porównać te dane z wymaganiami aplikacji oraz ustawieniami dopuszczonymi w ramach danego planu taryfowego. CloudLinux Manager umożliwia ustanawianie administracyjnych wytycznych dotyczących wersji i rozszerzeń; nie oznacza to jednak, że klienci mogą samodzielnie zmieniać każdą opcję.

W środowisku izolowanym przetestuj nie tylko stronę główną, ale także procesy logowania, formularze, importy oraz inne procedury istotne dla Twojego projektu. Zadania zaplanowane należy sprawdzić osobno, ponieważ ich wykonanie nie wynika wyłącznie z wyświetlania strony internetowej. Należy odnotować wszelkie nieprawidłowości i usunąć problemy z kompatybilnością przed przejściem na środowisko produkcyjne.

Na koniec umieść Podróż powrotna Uwaga: Kto może ponownie wybrać poprzednią wersję i jakie ustawienia należy następnie sprawdzić? Zaplanuj zmianę na odpowiedni moment, a następnie obserwuj aplikacje, których to dotyczy. Samo przywrócenie poprzedniej wersji nie gwarantuje, że wszystkie rozszerzenia i opcje zostaną przywrócone do poprzedniego stanu.

Sprawdź działanie strony internetowej, interfejsu CLI i zadań cron

Strona internetowa i jej zadania działające w tle nie muszą korzystać z tego samego interpretera PHP. Żądania HTTP są przetwarzane przez środowisko uruchomieniowe określone przez serwer WWW i jego moduł obsługi; natomiast wywołanie z wiersza poleceń uruchamia interpretera, który znajduje dane środowisko. CloudLinux rozróżnia natywne ścieżki dla interpreterów WWW i CLI. Dlatego samo wyświetlenie w PHP Selectorze nie odpowiada na wszystkie pytania dotyczące faktycznego wykonania.

Jeśli w Twoim pakiecie dostępna jest usługa SSH, możesz w sesji terminala wykonać poniższe polecenie odczytowe. Wyświetla ono wersję Interpretery CLI, który zostanie znaleziony właśnie dla tego wywołania. Do przeprowadzenia testu nie są potrzebne żadne zmiany w plikach ani ustawieniach.

php -v

Wynik ten nie wskazuje ani na wersję PHP żądania HTTP, ani na wersję innego zadania cron wywołanego w inny sposób. Zaplanowane zadanie może korzystać z wyraźnie określonej ścieżki interpretera lub innego środowiska. Dlatego należy sprawdzić zapisane wywołanie i środowisko wykonania konkretnego zadania, zamiast opierać się na wynikach sesji interaktywnej.

Do sprawdzania działania w sieci należy stosować zabezpieczoną metodę obsługiwanej przez dostawcę i w razie potrzeby zapytać o właściwy moduł obsługi. Publicznie dostępny skrypt diagnostyczny zawierający szczegółowe informacje o środowisku nie stanowi odpowiedniego standardowego rozwiązania. Sprawdź również zaplanowane zadania za pomocą obsługiwanej metody, a następnie zweryfikuj, czy na przykład import lub zadanie wysyłkowe faktycznie działa zgodnie z założeniami.

Dla każdej istotnej ścieżki wykonania należy odnotować, jaka wersja jest oczekiwana i w jaki sposób została sprawdzona. Jeśli panel, wynik SSH i zachowanie zadania dostarczają sprzecznych informacji, należy najpierw wyjaśnić z dostawcą, kto jest odpowiedzialny za dane środowisko uruchomieniowe. W ten sposób unikniesz zmiany ustawienia w niewłaściwym miejscu.

Wykrywanie i lokalizowanie usterek po wymianie

Jeśli strona główna ładuje się po zmianie, ale formularz lub import nie działają, oznacza to, że zmiana nie została jeszcze wystarczająco przetestowana. Powtórz dany proces i zanotuj czas, funkcję oraz zaobserwowany komunikat o błędzie. Porównaj te informacje z dostępnymi logami aplikacji i serwera, o ile Twój pakiet taryfowy zapewnia do nich dostęp; poufne dane z logów nie powinny znajdować się w plikach dostępnych publicznie.

Następnie sprawdź Kompatybilność danej aplikacji i jej rozszerzeń z wybraną gałęzią PHP. Formularz może na przykład zależeć od wtyczki, która w ogóle nie jest uruchamiana na stronie głównej. Podczas importu istotne są dodatkowo jej zależności oraz rzeczywista ścieżka wykonania: zadanie w tle może korzystać z innego środowiska uruchomieniowego niż strona internetowa.

Przed zmianą porównaj dostępne i włączone rozszerzenia PHP dla docelowej wersji oraz wymagane opcje z dokumentacją. Wybór gałęzi PHP nie oznacza automatycznie, że wszystkie wymagane moduły i ustawienia są odpowiednie. To, jakie zmiany możesz wprowadzić samodzielnie, zależy od zgody operatora.

Sprawdź również, czy dana domena rzeczywiście jest zgodna z oczekiwaną Handler i zastosowano żądany czas trwania. Jeśli dostępnych jest kilka interfejsów administracyjnych, przed wprowadzeniem dalszych zmian w ustawieniach należy ustalić zakres ich kompetencji z dostawcą. Komunikat wyświetlany w selektorze nie musi wyjaśniać, która ścieżka wykonania obsługuje konkretne żądanie.

Ostrzeżenie: Nie należy ogólnie sterować ścieżkami konfiguracyjnymi za pomocą PHPRC lub PHP_INI_SCAN_DIR . CloudLinux ostrzega, że takie zmiany w ścieżkach konfiguracyjnych PHP mogą negatywnie wpłynąć na działanie selektora. Jeśli konieczne wydaje się użycie indywidualnej ścieżki, należy najpierw skonsultować się z dostawcą.

Jeśli nie da się szybko usunąć błędu, skorzystaj z ustalonej wcześniej procedury przywracania poprzedniej wersji. Następnie ponownie sprawdź faktycznie obowiązującą wersję, rozszerzenia i opcje, a także funkcje, których dotyczy problem. Nie należy zakładać, że przywrócenie poprzedniej wersji spowoduje automatyczne przywrócenie wszystkich wcześniejszych ustawień; należy udokumentować wszelkie rozbieżności na potrzeby kolejnej próby.

Planowanie eksploatacji starszych systemów i migracji

O ciągłości pracy decyduje przede wszystkim wymagana Zakres zastosowania: Jeśli wspólny wybór pasuje do domen użytkownika zarządzanych przez Selector, Selector może stanowić odpowiedni interfejs. Jeśli natomiast dwie aplikacje wymagają niezależnych wersji, należy rozważyć zarządzanie oparte na domenach, obsługiwane przez dostawcę, lub oddzielne konta hostingowe. Sama udokumentowana opcja wyboru w Selectorze nie gwarantuje niezależnych ustawień dla każdej domeny w ramach tego samego konta.

Oddzielne konta mogą organizacyjnie oddzielić decyzje dotyczące wersji, o ile dostępne są odpowiednie gałęzie. Rozwiązanie oparte na domenie również może być odpowiednie, o ile dostawca je udostępnia, a jego współdziałanie z innymi narzędziami PHP jest dopracowane. Przed zmianą należy zapytać o koszty, warunki taryfowe i zakres odpowiedzialności; sama możliwość techniczna nie oznacza jeszcze zgody na konkretny pakiet.

Starsza aplikacja nie powinna pozostawać na stałe na starej gałęzi tylko dlatego, że można ją wybrać z menu. Zaplanuj Migracja w odniesieniu do obsługiwanej kombinacji aplikacji, zależności i PHP: zidentyfikuj brakujące aktualizacje, rozszerzenia, które można zastąpić, oraz niezbędne dostosowania. Wyznacz termin kolejnej kontroli zgodności oraz docelowy termin wycofania.

Należy regularnie sprawdzać oficjalny status wsparcia dla używanej gałęzi PHP, a jednocześnie monitorować komunikaty o błędach i kluczowe procesy biznesowe. Fakt, że starsza gałąź jest nadal dostępna, nie oznacza, że nadal objęta jest oficjalnym wsparciem. Przed podjęciem każdej długoterminowej decyzji należy ponownie sprawdzić tabelę wsparcia projektu PHP, ponieważ status ten zmienia się z upływem czasu.

Jeśli dostawca oferuje rozszerzone wsparcie techniczne, poproś o potwierdzenie, jakie pakiety są objęte wsparciem, jaki rodzaj poprawek bezpieczeństwa obejmuje oraz na jaki okres. Wsparcie to należy oceniać oddzielnie od oficjalnego wsparcia PHP i nie zastępuje ono ani aktualizacji aplikacji, ani planowanej migracji. Należy również ustalić, kto będzie zajmował się zmianami i awariami w okresie przejściowym.