PHP-vælger i delt hosting: Kør PHP-versioner sikkert sideløbende

Hvad en PHP-selector styrer

En PHP-vælger er en administrationsgrænseflade til PHP-kørselsmiljøer, som serverudbyderen stiller til rådighed. Her kan du, afhængigt af hostingkonfigurationen, vælge en PHP-gren og tilhørende udvidelser eller indstillinger. Grænsefladen installerer ikke automatisk alle ønskede versioner og garanterer heller ikke, at hvert valg gælder separat for de enkelte domæner.

Der er tre niveauer, der er vigtige for planlægningen: På serveren kan der være flere versioner installeret ; i taksten kan udbyderen dog kun gøre en del af dem tilgængelige. Hvilken version der rent faktisk udføres ved en konkret forespørgsel, afhænger desuden af konfigurationen af domænet, webserveren og den relevante PHP-handler. Et synligt menupunkt alene giver ikke svar på dette sidste spørgsmål.

CloudLinux tilbyder alternative kørselstider som Gammel PHP klar. Derudover findes der serverens eller kontrolpanelets native PHP-miljø. Udtrykket »native« henviser her ikke til et bestemt versionsnummer: Det er det pågældende servermiljø, der bestemmer, hvilken PHP-version og hvilken konfiguration der ligger bag. En applikation kan derfor støde på andre forudsætninger ved en overgang til »native« end ved valg af en ældre PHP-version.

Hvis du har brug for en bestemt PHP-version til dit webhosting, skal du først tjekke applikationens krav og derefter spørge om, hvorvidt den faktisk er tilgængelig i det pågældende abonnement. Find også ud af, om de nødvendige udvidelser og indstillinger kan konfigureres. De dokumenterede CloudLinux-funktioner beskriver softwarens muligheder, ikke automatisk udstyret i et konkret hostingpakke.

Konti, domæner og isolation

Forestil dig en aktuel hjemmeside og en ældre forretningsapplikation, der kræver forskellige PHP-grene. Hvis de ligger på separate hostingkonti, kan de bruge forskellige versioner, forudsat at begge konti har deres egen selektorvalg, og udbyderen frigiver de nødvendige versioner. Dette er en mulig parallel drift på samme server, men det er ikke garanteret for alle abonnementer.

Det er anderledes, når der er tale om to domæner inden for samme konto. CloudLinux beskriver et Selector-valg, der gælder for alle domæner, som Selector administrerer for en bruger. Hvis du ændrer versionen der, skal du derfor regne med, at det vil påvirke begge applikationer; et uafhængigt domænevalg følger ikke blot af Selectorens eksistens.

Der Anvendelsesområde skal derfor afklares inden enhver ændring. Hvis udbyderen ikke understøtter passende styring på domæneniveau, kan separate konti være en løsning. Til dette formål skal applikationerne flyttes i overensstemmelse hermed, og de respektive prisbetingelser skal gennemgås. Et andet domæne eller et yderligere bibliotek i sig selv giver ikke mulighed for uafhængigt valg af version.

CageFS bruges i CloudLinux-miljøet med flere brugere til at adskille brugermiljøerne. Disse Isolering skal adskilles fra spørgsmålet om, hvilken PHP-version der kan indstilles for et domæne. Selv en yderligere isolering af hjemmesider inden for en konto beviser i sig selv ikke, at der er tale om et uafhængigt valg af selektor; mere om dette koncept forklares i artiklen om CageFS pr. hjemmeside i delt hosting.

CloudLinux beskriver også en særlig Selector-konfiguration uden aktiveret CageFS til en server med kun én brugerkonto. Dette betyder dog ikke, at det anbefales at deaktivere CageFS på en almindelig server med delt hosting. Sikkerhedsarkitekturen og dens opsætning er operatørens ansvar; som kunde bør du forhøre dig om den tilbudte adskillelse og dens omfang.

Selector og MultiPHP Manager

CloudLinux PHP Selector og cPanel MultiPHP Manager er forskellige værktøjer. Selector administrerer de tilgængelige PHP-indstillinger som en del af sin integration, mens MultiPHP Manager kan administrere PHP-indstillinger på domæneniveau. At en af disse grænseflader understøtter domænespecifikke indstillinger betyder dog ikke, at de er tilgængelige i din egen pakke eller er aktiveret for alle kombinationer.

I den dokumenterede cPanel-integration angiver CloudLinux blandt andet følgende for brugen af Selectors: Systemindstilling i MultiPHP Manager og deaktiveret PHP-FPM for det pågældende domæne. Disse forudsætninger beskriver en bestemt integration, ikke en generel vejledning med klik-for-klik-instruktioner. Det afhænger af, hvordan hostingudbyderen har konfigureret håndteringen og brugergrænsefladerne, hvilke indstillinger der er gældende.

Hvis begge grænseflader er synlige, bør du ikke afprøve deres funktioner på et produktionswebsted for at finde ud af, hvad de kan. En domænespecifik indstilling i MultiPHP Manager og et valg i Selector kan ellers skabe forventninger, der ikke stemmer overens med den handler, der rent faktisk bruges. Bed udbyderen om at forklare, hvilket værktøj der er afgørende for det pågældende domæne, og hvilke ændringer der påvirker andre domæner.

Følgende spørgsmål kan hjælpe med at træffe en konkret beslutning: Hvilket brugergrænseflade er tilgængeligt i abonnementet? Gælder valget pr. konto eller pr. domæne, og hvilke PHP-versioner samt udvidelser er godkendt? Spørg desuden, om SSH og planlagte opgaver er tilgængelige, og hvilken fortolker der udfører dem. På den måde kan webapplikationer og baggrundsopgaver planlægges separat, i stedet for at skulle udlede alle udførelsesveje ud fra en panelvisning.

Afklar til sidst, om der er adgang til et afskærmet testmiljø og en sikkerhedskopi, og hvem der i tilfælde af en fejl kan gendanne den hidtidige konfiguration. Først når ansvarsfordelingen for brugergrænsefladen og det berørte område er kendt, kan man forberede en overgang med et overskueligt risiko. Ubekræftede menupunkter eller en angiveligt universel konfigurationsløsning er ikke til nogen hjælp i denne sammenhæng.

Vælg det relevante anvendelsesområde

Inden du ændrer en PHP-version på dit webhosting, skal du afklare Anvendelsesområde den tilgængelige indstilling. Det afgørende er ikke kun, hvor mange domæner du administrerer, men også hvilke af dem, der bruger den samme bruger og det samme selektorvalg. Tabellen omsætter typiske krav til spørgsmål, som du kan afklare med din udbyder.

CloudLinux Selector anvender sit valg på de domæner, som den administrerer for en bruger, hvilket er dokumenteret. Hvis to applikationer på samme konto kræver forskellige versioner, kan det være en hjælp at opdele dem på forskellige konti, forudsat at abonnementstypen og de tilgængelige versioner tillader det. Du skal forhøre dig hos udbyderen om eventuelle ekstra omkostninger og betingelser.

En anden mulighed er en udtrykkeligt understøttet domænespecifik administration, f.eks. via cPanel MultiPHP Manager. Om denne funktion er tilgængelig i det pågældende abonnement, og hvordan den fungerer sammen med en selektor, kan ikke antages generelt. En ændring via .htaccess Du bør ikke regne med, at det er en pålidelig erstatning.

Opdelingen af versionerne løser desuden ikke alle afhængigheder: Et program kan kræve bestemte moduler eller indstillinger, mens en planlagt opgave bruger sin egen fortolker. Notér disse krav separat, så du ikke blot spørger udbyderen om et versionsnummer, men om den fulde eksekveringssti.

Kontroller PHP-version og support

Vælg en PHP-gren, som din konkrete applikation understøtter, og hvor der er sikkerhedsrettelser tilgængelige. Kontroller derfor kravene til den anvendte CMS- eller webshop-version samt til plugins, temaer, biblioteker og din egen kode. En opdateret PHP-version alene gør ikke automatisk en ældre, ikke-kompatibel applikation kørbar.

Den officielle PHP-tabel skelner mellem aktiv support og en efterfølgende fase med sikkerhedsrettelser. Ifølge en undersøgelse fra den 4. november 2026 modtager PHP 8.2 og 8.3 kun sikkerhedsrettelser; PHP 8.4 og 8.5 er i aktiv support. Den officielle sikkerhedsstøtte til PHP 8.2 udløber den 31. december 2026. Tjek status igen, inden du træffer en beslutning, da denne klassificering kan ændre sig med tiden.

Visningen af en version i vælgeren besvarer et andet spørgsmål end supporttabellen: Den viser et udvalg i dit miljø, men bekræfter hverken officiel support eller din applikations kompatibilitet. Omvendt betyder officiel support for en gren ikke nødvendigvis, at din hostingpakke tilbyder den.

En udbyder kan muligvis tilbyde sin egen udvidede support til ældre pakker. Afklar derfor skriftligt, hvilke pakker og sikkerhedsrettelser denne omfatter, hvor længe den gælder, og hvordan opdateringerne leveres. Dette Udbydersupport skal ikke sidestilles med den officielle support fra PHP-projektet og erstatter ikke en migrationsplan for applikationen.

Hvis der skal skiftes til en nyere gren, skal du også kontrollere, om der er oversprungne migrationstrin og baggrundsopgaver. Indlægget om PHP 8.5 i hosting og til kompatibilitetstest forklarer, hvilke afhængigheder og processer der kan være relevante i forbindelse med netop denne versionsopgradering.

Forbered omstillingen på en kontrolleret måde

Start med at lave en oversigt: Hvilken platform har du til rådighed, hvilke domæner administrerer den, og hvilke PHP-versioner er godkendt til din konto? Notér det nuværende udvalg, og spørg om det faktiske anvendelsesområde, hvis der er noget, der er uklart. På den måde undgår du at migrere en tilsyneladende enkelt hjemmeside, selvom flere domæner er berørt.

Lad os antage, at en nyere applikation og en ældre applikation kører sideløbende. Kontroller først, om deres krav er forenelige med en fælles målversion. Hvis ikke, kan det være en hjælp at foretage et separat valg i forskellige konti; et domænespecifikt alternativ kan kun komme på tale, hvis udbyderen understøtter det til din konfiguration.

Før du foretager ændringer i produktionsmiljøet, skal du kontrollere, om der findes en opdateret Sikring af filer og databaser er til stede, og at gendannelsen er afklaret. Et isoleret testmiljø er nyttigt, hvis du har mulighed for at stille et sådant til rådighed: Her kan du teste målversionen uden unødigt at udsætte besøgende eller produktive data for risiko. Det er op til udbyderen at afklare, om abonnementet omfatter staging eller sikkerhedskopier.

Udover den nuværende og den ønskede PHP-version skal du også dokumentere de nødvendige udvidelser og relevante indstillinger. Sammenlign disse oplysninger med applikationens krav og de indstillinger, der er godkendt i abonnementet. CloudLinux Manager giver mulighed for administrative fastsættelser af versioner og udvidelser; det betyder dog ikke, at kunderne selv kan ændre alle indstillinger.

I det isolerede miljø skal du ikke kun teste startsiden, men også login, formularer, import og andre processer, der er vigtige for dit projekt. Kontroller planlagte opgaver separat, da det ikke er nok at se, at hjemmesiden vises korrekt, for at sikre, at de udføres korrekt. Noter eventuelle uregelmæssigheder, og afhjælp kompatibilitetsproblemer, inden overgangen til den produktive drift finder sted.

Til sidst lægger du en Rejsen tilbage Husk: Hvem kan vælge den tidligere version igen, og hvilke indstillinger skal kontrolleres bagefter? Planlæg overgangen til et passende tidspunkt, og overvåg derefter de berørte applikationer. En tilbagevenden til den tidligere version garanterer ikke i sig selv, at alle udvidelser og indstillinger er sat tilbage som før.

Kontroller web, CLI og cron-jobs

Et websted og dets baggrundsopgaver behøver ikke at bruge den samme PHP-fortolker. HTTP-anmodninger behandles af et kørselsmiljø, der bestemmes af webserveren og dens handler; et kommandolinjekald starter derimod den fortolker, som det pågældende miljø finder. CloudLinux skelner mellem native stier til web- og CLI-fortolkere. Visningen i PHP Selector alene besvarer derfor ikke alle spørgsmål vedrørende den faktiske udførelse.

Hvis SSH er tilgængeligt i dit abonnement, kan du i en terminalsession køre følgende kommando, der kun viser oplysninger. Den viser versionen af CLI-fortolkere, som findes for netop denne opfordring. Der kræves ingen ændringer af filer eller indstillinger for at gennemføre kontrollen.

php -v

Resultatet angiver hverken PHP-versionen for en HTTP-anmodning eller for et cron-job, der er blevet udført på anden vis. En planlagt opgave kan bruge en eksplicit interpreter-sti eller et andet miljø. Kontroller derfor den gemte opkaldsstruktur og kørselsmiljøet for det konkrete job i stedet for at overføre udskriften fra din interaktive session til det.

Brug en beskyttet metode, der understøttes af udbyderen, til webkontrollen, og spørg om nødvendigt efter den ansvarlige kontaktperson. Et offentligt tilgængeligt diagnoseskript med detaljerede oplysninger om miljøet er ikke en passende standardløsning. Kontroller også planlagte opgaver via en understøttet metode, og tjek derefter, om f.eks. en import eller en forsendelsesopgave rent faktisk fungerer som forventet.

Notér for hver relevant kørselsvej, hvilken version der forventes, og hvordan den er blevet testet. Hvis panelet, SSH-udskriften og et jobs adfærd giver forskellige oplysninger, skal du først afklare ansvaret for den pågældende kørsel med udbyderen. På den måde undgår du at ændre en indstilling det forkerte sted.

Indsnævre fejlen efter udskiftningen

Hvis startsiden indlæses efter ændringen, men en formular eller en import mislykkes, er overgangen endnu ikke blevet testet tilstrækkeligt. Gentag den pågældende proces, og noter tidspunkt, funktion og den observerede fejlmeddelelse. Sammenlign disse oplysninger med de tilgængelige applikations- og serverlogfiler, i det omfang dit abonnement giver adgang hertil; følsomme logdata hører ikke hjemme i offentligt tilgængelige filer.

Kontroller derefter Kompatibilitet den pågældende applikation og dens udvidelser med den valgte PHP-gren. En formular kan for eksempel være afhængig af et plugin, der slet ikke kører på startsiden. Ved en import er også dens afhængigheder og den faktiske kørselssti relevante: En baggrundsopgave kan bruge en anden kørselstid end hjemmesiden.

Sammenlign de PHP-udvidelser, der er tilgængelige og aktiveret for målversionen, samt de nødvendige indstillinger med din dokumentation, inden du skifter. Valget af en PHP-gren bekræfter ikke automatisk, at alle nødvendige moduler og indstillinger er korrekte. Hvilke ændringer du selv må foretage, afhænger af godkendelse fra operatøren.

Kontroller desuden, om det pågældende domæne rent faktisk er det forventede handler og den ønskede kørselstid anvendes. Hvis der findes flere administrationsgrænseflader, skal du afklare deres ansvarsområder med udbyderen, inden du ændrer yderligere indstillinger. En visning i selektoren behøver ikke at forklare, hvilken kørselsvej en konkret forespørgsel behandles via.

Advarsel: Undgå at konfigurere stier generelt via PHPRC eller PHP_INI_SCAN_DIR . CloudLinux advarer om, at sådanne ændringer af PHP-konfigurationsstier kan påvirke Selector. Hvis en individuel sti synes nødvendig, skal du først afklare dette med udbyderen.

Hvis fejlen ikke kan løses med det samme, skal du bruge den på forhånd fastlagte fremgangsmåde til at vende tilbage til den tidligere version. Kontroller derefter igen, hvilken version der faktisk er gældende, samt udvidelser, indstillinger og de berørte funktioner. Stol ikke på, at en tilbagevenden automatisk gendanner alle tidligere indstillinger; dokumenter afvigelser til det næste forsøg.

Planlægning af drift af ældre systemer og migration

For kontinuerlig drift er det først og fremmest den nødvendige Anvendelsesområde: Hvis et fælles valg passer til de domæner, som Selector administrerer for en bruger, kan Selector være en passende løsning. Hvis to applikationer derimod kræver uafhængige versioner, bør du undersøge, om udbyderen understøtter domænespecifik administration eller separate hostingkonti. Det dokumenterede Selector-valg i sig selv garanterer ikke uafhængige indstillinger for hvert domæne på samme konto.

Separate konti kan adskille beslutningerne om versioner organisatorisk, forudsat at de nødvendige grene tilbydes i hvert tilfælde. En domænebaseret løsning kan også være passende, hvis udbyderen stiller den til rådighed, og samspillet med andre PHP-værktøjer er afklaret. Spørg om omkostninger, prisbetingelser og ansvarsfordeling, inden du skifter; den tekniske mulighed er ikke ensbetydende med en tilsagn om et bestemt pakke.

Et ældre program bør ikke forblive permanent på en gammel gren, blot fordi denne kan vælges i menuen. Planlæg Migration en understøttet kombination af applikation, afhængigheder og PHP: Identificer manglende opdateringer, udskiftelige udvidelser og nødvendige tilpasninger. Fastlæg en dato for den næste kompatibilitetstest og en måldato for udskiftningen.

Kontroller regelmæssigt den officielle supportstatus for den anvendte PHP-gren, og hold samtidig øje med fejlmeddelelser og vigtige forretningsprocesser. At en ældre gren tilbydes, er ikke ensbetydende med fortsat officiel support. Supporttabellen fra PHP-projektet bør gennemgås igen, før der træffes en langsigtet beslutning, da status ændrer sig over tid.

Hvis en udbyder lover udvidet support, skal du bede om dokumentation for de pågældende pakker, typen af sikkerhedsrettelser og supportperioden. Denne support skal vurderes uafhængigt af den officielle PHP-support og erstatter hverken opdateringer af applikationen eller den planlagte migrering. Sørg også for at fastlægge, hvem der håndterer ændringer og forstyrrelser i overgangsperioden.