PHP-väljare vid delad hosting: Säker parallelldrift av PHP-versioner

Vad en PHP-selektor styr

En PHP-väljare är ett administrationsgränssnitt för PHP-körmiljöer som tillhandahålls av serveroperatören. Via detta gränssnitt kan du, beroende på webbhotellkonfigurationen, välja en PHP-gren och tillhörande tillägg eller alternativ. Gränssnittet installerar inte automatiskt varje önskad version och garanterar inte heller att varje val gäller separat för enskilda domäner.

Tre nivåer är viktiga för planeringen: På servern kan flera versioner installerad ; i prisplanen kan leverantören dock endast göra en del av dessa tillgängliga för val. Vilken version som faktiskt körs vid en konkret förfrågan beror dessutom på konfigurationen av domänen, webbservern och den aktuella PHP-hanteraren. En synlig menypost i sig ger inte svar på den sista frågan.

CloudLinux erbjuder alternativa körmiljöer som Gammal PHP klar. Dessutom finns serverns respektive kontrollpanelens inbyggda PHP-miljö. Med ”inbyggd” avses här inte ett fast versionsnummer: vilken PHP-version och vilken konfiguration som ligger bakom bestäms av den aktuella servermiljön. En applikation kan därför stöta på andra förutsättningar vid en övergång till den inbyggda miljön än vid val av en äldre PHP-version.

Om du behöver en viss PHP-version för ditt webbhotell bör du först kontrollera applikationens krav och därefter fråga om den faktiska tillgängligheten i paketet. Kontrollera också om nödvändiga tillägg och inställningar kan hanteras. De dokumenterade CloudLinux-funktionerna beskriver programvarans möjligheter, inte automatiskt utrustningen i ett specifikt webbhotellspaket.

Konton, domäner och isolering

Tänk dig en aktuell webbplats och en äldre affärsapplikation som kräver olika PHP-grenar. Om de ligger på separata webbhotellkonton kan de använda olika versioner, förutsatt att båda kontona har en egen selektorinställning och att leverantören godkänner de nödvändiga versionerna. Detta är en möjlig form av parallelldrift på samma server, men inget som garanteras för alla abonnemang.

Det är annorlunda när det gäller två domäner inom samma konto. CloudLinux beskriver ett selektorval som gäller för alla domäner som hanteras av selektorn för en användare. Om du ändrar versionen där måste du därför räkna med att det påverkar båda applikationerna; ett oberoende domänval följer inte av selektorns blotta existens.

Der Tillämpningsområde Därför måste detta klargöras innan varje ändring. Om leverantören inte stöder lämplig styrning per domän kan separata konton vara en lösning. För detta måste applikationerna flyttas på lämpligt sätt och respektive prisvillkor kontrolleras. En andra domän eller en ytterligare katalog i sig ger inte möjlighet till oberoende val av version.

CageFS används i CloudLinux-miljön med flera användare för att avgränsa användarmiljöerna. Dessa Isolering måste skiljas från frågan om vilken PHP-version som kan ställas in för en domän. Inte heller en ytterligare isolering av webbplatser inom ett konto innebär i sig ett oberoende val av selektor; mer om detta koncept förklaras i inlägget om CageFS per webbplats vid delad hosting.

CloudLinux beskriver även en särskild Selector-konfiguration utan aktiverat CageFS för en server med endast ett användarkonto. Detta innebär dock inte någon rekommendation att inaktivera CageFS på en vanlig server för delad hosting. Säkerhetsarkitekturen och dess inställningar ligger där hos operatören; som kund bör du fråga om den erbjudna isoleringen och dess omfattning.

Selector och MultiPHP Manager

CloudLinux PHP Selector och cPanel MultiPHP Manager är olika verktyg. Selector hanterar tillgängliga PHP-alternativ inom ramen för sin integration, medan MultiPHP Manager kan hantera PHP-inställningar på domännivå. Att ett av dessa gränssnitt stöder domänspecifika inställningar innebär dock inte att dessa är tillgängliga i just ditt abonnemang eller att de är aktiverade för alla kombinationer.

I den dokumenterade samverkan med cPanel anger CloudLinux bland annat följande för användningen av Selectors: Systeminställning i MultiPHP Manager och att PHP-FPM är inaktiverat för den aktuella domänen. Dessa förutsättningar beskriver en specifik integration, inte en allmängiltig klickguide. Hur webbhotellet har konfigurerat hanteraren och gränssnitten avgör vilken inställning som gäller.

Om båda gränssnitten är synliga bör du inte försöka ta reda på deras ansvarsområden genom att testa på en produktiv webbplats. En domänrelaterad inställning i MultiPHP Manager och ett val i Selector kan annars skapa förväntningar som inte stämmer överens med den hanterare som faktiskt används. Be leverantören förklara vilket verktyg som är avgörande för den berörda domänen och vilka ändringar som påverkar andra domäner.

För att fatta ett konkret beslut kan följande frågor vara till hjälp: Vilket gränssnitt ingår i paketet? Gäller valet per konto eller per domän, och vilka PHP-versioner och tillägg är tillåtna? Fråga också om SSH och schemalagda uppgifter är tillgängliga och vilken tolk som kör dem. På så sätt kan webbapplikationer och bakgrundsuppgifter planeras separat, istället för att dra slutsatser om alla körvägar utifrån en panelvy.

Kontrollera slutligen om det finns en avskärmad testmiljö och en säkerhetskopia, samt vem som kan återställa den tidigare konfigurationen om ett fel skulle uppstå. Först när ansvaret för gränssnittet och det berörda området är klart kan man förbereda en övergång med en hanterbar risk. Obekräftade menyalternativ eller en förmodat universell konfigurationslösning är inte till någon hjälp i detta sammanhang.

Välj rätt tillämpningsområde

Innan du ändrar PHP-versionen i webbhotellet bör du klargöra Tillämpningsområde den tillgängliga inställningen. Det avgörande är inte bara hur många domäner du har, utan vilka av dem som använder samma användare och samma selektorval. Tabellen omvandlar typiska krav till frågor som du kan reda ut med din leverantör.

CloudLinux Selector tillämpar sitt val på de domäner som den förvaltar åt en användare, vilket dokumenteras. Om två applikationer i samma konto kräver olika versioner kan det vara en hjälp att dela upp dem på olika konton, förutsatt att abonnemanget och de tillgängliga versionerna tillåter detta. Du måste kontakta leverantören för information om eventuella extra kostnader och villkor.

Ett annat alternativ är en uttryckligen stödd domänbaserad hantering, till exempel via cPanel MultiPHP Manager. Om denna funktion finns tillgänglig i just det abonnemanget och hur den samverkar med en selektor kan inte generellt antas. Även en ändring via .htaccess Du bör inte räkna med att det är en pålitlig ersättning.

Att separera versionerna löser dessutom inte alla beroenden: En applikation kan kräva vissa moduler eller inställningar, medan ett planerat uppdrag använder en egen tolk. Dokumentera dessa krav separat så att du inte bara frågar leverantören om ett versionsnummer, utan om den fullständiga körvägen.

Kontrollera PHP-version och support

Välj en PHP-gren som stöds av just din applikation och för vilken säkerhetsuppdateringar finns tillgängliga. Kontrollera därför kraven för den CMS- eller webbutiksversion som används samt för plugins, teman, bibliotek och egen kod. En aktuell PHP-version i sig gör inte automatiskt att en äldre, icke-kompatibel applikation kan köras.

Den officiella PHP-tabellen skiljer mellan aktiv support och en efterföljande fas med säkerhetsuppdateringar. Enligt en undersökning från den 4 november 2026 får PHP 8.2 och 8.3 endast säkerhetsuppdateringar; PHP 8.4 och 8.5 omfattas fortfarande av aktiv support. För PHP 8.2 upphör det officiella säkerhetsstödet den 31 december 2026. Kontrollera statusen igen innan du fattar ett beslut, eftersom denna klassificering kan ändras med tiden.

Att en version visas i väljaren besvarar en annan fråga än supporttabellen: den visar ett urval i din miljö, men innebär varken officiell support eller att din applikation är kompatibel. Omvänt innebär inte officiell support för en gren att ditt webbhotellpaket erbjuder den.

En leverantör kan eventuellt erbjuda egen förlängd support för äldre paket. Klargör därför skriftligen vilka paket och säkerhetsuppdateringar som ingår, hur länge supporten gäller och hur uppdateringar tillhandahålls. Detta Support från leverantören ska inte likställas med det officiella stödet från PHP-projektet och ersätter inte någon migreringsplan för applikationen.

Om en övergång till en nyare gren står för dörren, kontrollera även eventuella utelämnade migrationssteg och bakgrundsuppgifter. Inlägget om PHP 8.5 i webbhotell och för kompatibilitetskontroll förklarar vilka beroenden och processer som kan vara relevanta vid just detta versionsbyte.

Förbereda övergången på ett kontrollerat sätt

Börja med att göra en inventering: Vilken plattform har du tillgång till, vilka domäner hanteras av den och vilka PHP-versioner är godkända för ditt konto? Notera det nuvarande utbudet och fråga om det råder oklarheter om den faktiska tillämpningsområdet. På så sätt undviker du att migrera en webbplats som du tror är den enda, trots att fler domäner berörs.

Anta att en aktuell applikation och en äldre applikation körs parallellt. Kontrollera först om deras krav är förenliga med en gemensam målversion. Om så inte är fallet kan det vara bra att göra ett eget val i separata konton; ett domänbaserat alternativ är endast aktuellt om leverantören stöder det för din konfiguration.

Kontrollera innan du gör ändringar i produktionsmiljön om det finns en aktuell Säkring av filer och databaser finns på plats och att återställningen av dem är klarlagd. En isolerad testmiljö är till hjälp, om du kan ordna en sådan: där kan du testa målversionen utan att utsätta besökare eller produktiva data för onödiga risker. Om abonnemanget inkluderar staging eller säkerhetskopiering måste du klargöra med leverantören.

Dokumentera inte bara den nuvarande och den önskade PHP-versionen, utan även nödvändiga tillägg och relevanta alternativ. Jämför dessa uppgifter med applikationens krav och de inställningar som är tillåtna enligt abonnemanget. CloudLinux Manager möjliggör administrativa inställningar för versioner och tillägg; detta innebär dock inte att kunderna själva kan ändra alla alternativ.

Testa inte bara startsidan i den isolerade miljön, utan även inloggningar, formulär, importer och andra processer som är viktiga för ditt projekt. Kontrollera planerade uppgifter separat, eftersom det inte räcker med att webbplatsen visas för att bekräfta att de utförs. Dokumentera avvikelser och åtgärda kompatibilitetsproblem innan den produktiva övergången.

Lägg till slut en Återresa Observera: Vem får välja tillbaka till den tidigare versionen, och vilka inställningar måste kontrolleras därefter? Planera övergången till ett lämpligt tillfälle och övervaka därefter de berörda applikationerna. Att byta tillbaka till den tidigare versionen garanterar inte i sig att alla tillägg och alternativ återställs till tidigare inställningar.

Kontrollera webb, CLI och cron-jobb

En webbplats och dess bakgrundsuppgifter behöver inte använda samma PHP-tolken. HTTP-förfrågningar hanteras av en runtime som bestäms av webbservern och dess hanterare; ett kommandoradsanrop startar däremot den tolk som den aktuella miljön hittar. CloudLinux skiljer mellan inbyggda sökvägar för webb- och CLI-tolkar. Visningen i PHP Selector ger därför inte i sig svar på alla frågor om den faktiska körningen.

Om SSH ingår i ditt abonnemang kan du köra följande läsbefallning i en terminalsession. Den visar versionen av CLI-tolkar, som hittas för just denna uppmaning. För kontrollen krävs inga ändringar av filer eller inställningar.

php -v

Resultatet visar varken PHP-versionen för en HTTP-förfrågan eller för ett cron-jobb som anropats på annat sätt. Ett schemalagt jobb kan använda en uttrycklig tolkväg eller en annan miljö. Kontrollera därför det lagrade anropet och körningsmiljön för det specifika jobbet, istället för att överföra utdata från din interaktiva session till det.

Använd en säker metod som stöds av leverantören för webbkontrollen och fråga vid behov efter den ansvariga handläggaren. Ett offentligt tillgängligt diagnostiskt skript med detaljerad miljöinformation är ingen lämplig standardlösning. Kontrollera även planerade uppgifter via en stödd metod och verifiera därefter om exempelvis en import eller ett sändningsjobb faktiskt fungerar som avsett.

Notera för varje relevant körningsväg vilken version som förväntas och hur den har kontrollerats. Om panelen, SSH-utdata och ett jobs beteende ger olika indikationer, klargör först ansvaret för respektive körningsmiljö med leverantören. På så sätt undviker du att ändra en inställning på fel ställe.

Identifiera fel efter bytet

Om startsidan laddas efter ändringen, men ett formulär eller en import misslyckas, har övergången ännu inte testats tillräckligt. Upprepa den berörda processen och notera tidpunkt, funktion och det felmeddelande som visas. Jämför dessa uppgifter med de tillgängliga applikations- och serverloggarna, i den mån ditt abonnemang ger tillgång till dem; känsliga loggdata hör inte hemma i offentligt tillgängliga filer.

Kontrollera sedan Kompatibilitet den berörda applikationen och dess tillägg med den valda PHP-grenen. Ett formulär kan till exempel vara beroende av ett plugin som inte körs alls på startsidan. Vid en import är dess beroenden och den faktiska körvägen dessutom relevanta: ett bakgrundsjobb kan använda en annan körmiljö än webbplatsen.

Jämför de PHP-tillägg som är tillgängliga och aktiverade för målversionen samt de nödvändiga inställningarna med din dokumentation innan du byter. Valet av en PHP-gren bekräftar inte automatiskt att alla nödvändiga moduler och inställningar är korrekta. Vilka ändringar du själv får göra beror på godkännande från operatören.

Kontrollera dessutom om den berörda domänen verkligen är den förväntade handlare och den önskade körningstiden används. Om det finns flera administrationsgränssnitt bör du klargöra deras ansvarsområden med leverantören innan du ändrar ytterligare inställningar. En visning i Selector behöver inte förklara vilken körningsväg som hanterar en specifik förfrågan.

Varning: Styr inte konfigurationsvägarna generellt via PHPRC eller . PHP_INI_SCAN_DIR . CloudLinux varnar för att sådana ändringar av PHP:s konfigurationsvägar kan påverka Selector negativt. Om en specifik väg verkar nödvändig bör du först klargöra detta med leverantören.

Om felet inte kan åtgärdas omedelbart, använd den i förväg fastställda återgångsvägen till den tidigare versionen. Kontrollera därefter på nytt vilken version som faktiskt gäller, tillägg och alternativ samt de berörda funktionerna. Räkna inte med att en återgång automatiskt återställer alla tidigare inställningar; dokumentera avvikelser inför nästa försök.

Planera drift av äldre system och migrering

För kontinuerlig drift är det först och främst den nödvändiga Tillämpningsområde: Om ett gemensamt val passar för de domäner som Selector hanterar åt en användare kan Selector vara ett lämpligt gränssnitt. Om två applikationer däremot kräver oberoende versioner bör du överväga en domänbaserad hantering som stöds av leverantören eller separata webbhotellskonton. Det dokumenterade Selector-urvalet i sig garanterar inte oberoende inställningar för varje domän inom samma konto.

Separata konton kan organisatoriskt separera versionsbesluten, förutsatt att de nödvändiga grenarna erbjuds i varje fall. En domänbaserad lösning kan också vara lämplig, förutsatt att leverantören tillhandahåller den och att samspelet med andra PHP-verktyg är klarlagt. Innan en övergång genomförs bör man fråga om kostnader, avtalsvillkor och ansvarsfördelning; den tekniska möjligheten innebär inte automatiskt ett löfte om ett visst paket.

En äldre applikation bör inte stanna kvar permanent på en gammal gren enbart för att den går att välja i menyn. Planera för Migration för en stödd kombination av applikation, beroenden och PHP: Identifiera saknade uppdateringar, utbytbara tillägg och nödvändiga anpassningar. Fastställ ett datum för nästa kompatibilitetskontroll och ett mål för övergången.

Kontrollera regelbundet den officiella supportstatusen för den PHP-gren du använder och håll samtidigt ett öga på felmeddelanden och viktiga affärsprocesser. Att en äldre gren erbjuds är inte ett bevis på fortsatt officiellt stöd. PHP-projektets supporttabell bör granskas på nytt inför varje långsiktigt beslut, eftersom statusen förändras med tiden.

Om en leverantör utlovar utökad support, be om bevis på vilka paket som berörs, vilken typ av säkerhetskorrigeringar det rör sig om och hur länge supporten gäller. Denna support ska bedömas separat från den officiella PHP-supporten och ersätter varken uppdateringar av applikationen eller den planerade migreringen. Notera också vem som hanterar ändringar och störningar under övergångsperioden.