PHP Selector nell'hosting condiviso: eseguire in parallelo le versioni di PHP in tutta sicurezza

Cosa controlla un selettore PHP

A Selettore PHP È un'interfaccia di gestione per gli ambienti di esecuzione PHP messa a disposizione dal gestore del server. Tramite di essa è possibile, a seconda della configurazione dell'hosting, selezionare un ramo PHP e le relative estensioni o opzioni. L'interfaccia non installa automaticamente ogni versione desiderata né garantisce che ogni selezione sia applicata separatamente ai singoli domini.

Per la pianificazione sono importanti tre livelli: sul server possono esserci diverse versioni installato ; tuttavia, nel piano tariffario il fornitore può rendere disponibile solo una parte di esse. La versione effettivamente eseguita da una richiesta specifica dipende inoltre dalla configurazione del dominio, del server web e dell'handler PHP competente. Una voce di menu visibile da sola non basta a rispondere a quest'ultima domanda.

CloudLinux offre runtime alternativi come PHP vecchio pronto. Esiste inoltre l'ambiente PHP nativo del server o del pannello di controllo. Il termine "nativo" non indica in questo caso un numero di versione specifico: la versione di PHP e la configurazione sottostanti dipendono dal rispettivo ambiente server. Pertanto, in caso di passaggio all'ambiente nativo, un'applicazione potrebbe trovarsi di fronte a requisiti diversi rispetto a quelli previsti dalla scelta di una versione precedente di PHP.

Se hai bisogno di una versione specifica di PHP per il tuo hosting, verifica innanzitutto i requisiti dell’applicazione e poi informati sulla disponibilità effettiva nel piano tariffario. Verifica inoltre se sia possibile modificare le estensioni e le impostazioni necessarie. Le funzionalità documentate di CloudLinux descrivono le possibilità offerte dal software, non le caratteristiche effettive di un determinato pacchetto di hosting.

Account, domini e isolamento

Immagina un sito web attuale e un’applicazione aziendale più datata che richiedono rami PHP diversi. Se si trovano su account di hosting separati, possono utilizzare versioni diverse, a condizione che entrambi gli account dispongano di una propria selezione di selettori e che il provider autorizzi i rami necessari. Si tratta di una possibile configurazione in parallelo sullo stesso server, ma non è garantita per tutti i piani tariffari.

La situazione è diversa nel caso di due domini all’interno dello stesso account. CloudLinux descrive una selezione del Selector che si applica a tutti i domini di un utente gestiti da quel Selector. Se modifichi la versione in quel contesto, devi quindi aspettarti che ciò abbia ripercussioni su entrambe le applicazioni; la semplice esistenza del Selector non implica una selezione indipendente dei domini.

Il sito Ambito di applicazione È quindi necessario chiarirlo prima di ogni modifica. Se il provider non supporta una gestione adeguata a livello di dominio, una soluzione potrebbe essere quella di utilizzare account separati. A tal fine, è necessario trasferire le applicazioni di conseguenza e verificare le rispettive condizioni tariffarie. Un secondo dominio o un’ulteriore directory, di per sé, non garantiscono ancora la possibilità di scegliere una versione indipendente.

CageFS serve, nell'ambiente multiutente di CloudLinux, a separare gli ambienti utente. Questi Isolamento Va distinta dalla questione relativa alla versione di PHP che può essere impostata per un dominio. Anche un ulteriore isolamento dei siti web all’interno di un account non dimostra di per sé una scelta indipendente del selettore; per ulteriori approfondimenti su questo concetto, si veda l’articolo su CageFS per singolo sito nell'hosting condiviso.

CloudLinux documenta anche una configurazione speciale di Selector senza CageFS attivato per un server con un solo account utente. Ciò non implica tuttavia alcuna raccomandazione di disattivare CageFS su un normale server di hosting condiviso. L'architettura di sicurezza e la sua configurazione sono di competenza del gestore; in qualità di cliente, dovresti informarti sulla separazione offerta e sulla sua portata.

Selector e MultiPHP Manager

CloudLinux PHP Selector e cPanel MultiPHP Manager sono strumenti diversi. Selector gestisce le opzioni PHP fornite nell’ambito della sua integrazione; MultiPHP Manager consente di gestire le impostazioni PHP a livello di dominio. Tuttavia, il fatto che una di queste interfacce supporti impostazioni a livello di dominio non significa che tali impostazioni siano disponibili nel proprio piano tariffario o abilitate per ogni combinazione.

Nell'interazione documentata con cPanel, CloudLinux indica, tra le altre cose, quanto segue per l'utilizzo del Selector: Impostazione predefinita del sistema in MultiPHP Manager e PHP-FPM disattivato per il dominio in questione. Questi prerequisiti descrivono una specifica integrazione, non una guida generale passo passo. È la configurazione dell’handler e dell’interfaccia da parte del provider di hosting a determinare quale impostazione sia effettiva.

Se entrambe le interfacce sono visibili, non dovresti cercare di individuarne le competenze sperimentando su un sito web in produzione. Un’impostazione relativa al dominio in MultiPHP Manager e una selezione nel Selector potrebbero altrimenti creare aspettative che non corrispondono all’handler effettivamente utilizzato. Chiedi al provider di spiegarti quale strumento è determinante per il dominio in questione e quali modifiche interessano gli altri domini.

Per prendere una decisione concreta, è utile porsi alcune domande: quale interfaccia è disponibile nel piano tariffario? La scelta vale per ogni account o per ogni dominio, e quali versioni di PHP ed estensioni sono consentite? Chiedi inoltre se sono disponibili SSH e le attività pianificate e quale interprete le esegue. In questo modo è possibile pianificare separatamente l’applicazione web e le attività in background, invece di dedurre tutte le modalità di esecuzione da una schermata del pannello di controllo.

Verifica infine se sono disponibili un ambiente di test isolato e un backup e chi, in caso di errore, sia in grado di ripristinare la configurazione precedente. Solo quando saranno note le responsabilità relative all’interfaccia e all’area interessata, sarà possibile preparare un cambiamento con un rischio gestibile. Le voci di menu non confermate o una soluzione di configurazione apparentemente universale non sono di alcun aiuto in questo senso.

Scegliere l'ambito di applicazione corretto

Prima di modificare la versione di PHP sul tuo hosting, verifica che Ambito di applicazione dell'impostazione disponibile. Non è determinante solo il numero di domini che gestisci, ma anche quali di essi utilizzano lo stesso utente e la stessa selezione di selettori. La tabella traduce i requisiti tipici in domande che puoi chiarire con il tuo provider.

Il CloudLinux Selector applica la propria selezione, come documentato, ai domini di un utente da esso gestiti. Se due applicazioni nello stesso account richiedono versioni diverse, può essere utile separarle in account distinti, purché il piano tariffario e le versioni disponibili lo consentano. Per eventuali costi aggiuntivi e condizioni, è necessario rivolgersi al fornitore.

Un'altra possibilità è quella di una gestione specifica per dominio espressamente supportata, ad esempio tramite il MultiPHP Manager di cPanel. Non è possibile stabilire in modo generale se tale funzione sia disponibile nel piano specifico e come interagisca con un selettore. Anche una modifica tramite .htaccess non dovresti considerarlo un sostituto affidabile.

Inoltre, la separazione delle versioni non risolve tutte le dipendenze: un’applicazione può richiedere determinati moduli o impostazioni, mentre un’attività pianificata utilizza un proprio interprete. Tieni traccia di questi requisiti separatamente, in modo da richiedere al fornitore non solo un numero di versione, ma anche il percorso di esecuzione completo.

Verifica della versione di PHP e dell'assistenza

Scegli un ramo PHP supportato dalla tua applicazione specifica e per il quale siano disponibili correzioni di sicurezza. A tal fine, verifica i requisiti della versione del CMS o del negozio online in uso, nonché quelli dei plugin, dei temi, delle librerie e del codice personalizzato. Una versione aggiornata di PHP da sola non rende automaticamente eseguibile un'applicazione più vecchia e non compatibile.

La tabella ufficiale di PHP distingue assistenza attiva e una fase successiva dedicata alle correzioni di sicurezza. Secondo una ricerca del 4 novembre 2026, PHP 8.2 e 8.3 riceveranno solo correzioni di sicurezza; PHP 8.4 e 8.5 sono ancora in fase di supporto attivo. Per PHP 8.2, il supporto ufficiale alla sicurezza terminerà il 31 dicembre 2026. Verifica nuovamente lo stato prima di prendere una decisione, poiché questa classificazione è soggetta a modifiche nel tempo.

La visualizzazione di una versione nel Selector risponde a una domanda diversa rispetto alla tabella di supporto: mostra una selezione disponibile nel tuo ambiente, ma non garantisce né il supporto ufficiale né la compatibilità della tua applicazione. Viceversa, il fatto che un ramo sia ufficialmente supportato non implica che il tuo piano di hosting lo offra.

Un fornitore potrebbe offrire un proprio servizio di assistenza estesa per i pacchetti meno recenti. A tal fine, chiarisci per iscritto quali pacchetti e correzioni di sicurezza sono inclusi, quale sia la durata del servizio e come vengano forniti gli aggiornamenti. Questo Assistenza fornitori non è da equiparare al supporto ufficiale del progetto PHP e non sostituisce un piano di migrazione per l'applicazione.

Se è previsto il passaggio a un ramo più recente, controlla anche i passaggi di migrazione saltati e le attività in background. L'articolo su PHP 8.5 nell'hosting e per la verifica della compatibilità spiega quali dipendenze e quali processi possono essere rilevanti in questo specifico cambio di versione.

Preparare la transizione in modo controllato

Inizia con un'analisi della situazione attuale: quale interfaccia hai a disposizione, quali domini gestisce e quali versioni di PHP sono abilitate per il tuo account? Prendi nota delle opzioni disponibili e, in caso di dubbi, chiedi chiarimenti sull'effettivo ambito di applicazione. In questo modo eviterai di migrare un sito web che ritieni singolo, mentre in realtà sono coinvolti altri domini.

Supponiamo che un'applicazione recente e una più vecchia siano in esecuzione contemporaneamente. Verifica innanzitutto se i loro requisiti sono compatibili con una versione di destinazione comune. In caso contrario, può essere utile effettuare una selezione personalizzata in account separati; un'alternativa basata sul dominio è prendibile in considerazione solo se il fornitore la supporta per la tua configurazione.

Prima di apportare modifiche in ambiente di produzione, verifica se è disponibile una versione aggiornata Backup dei file e del database sia disponibile e che il loro ripristino sia stato definito. Un ambiente di test isolato è utile, se riesci a metterlo a disposizione: in questo modo potrai testare la versione di destinazione senza mettere inutilmente a rischio i visitatori o i dati di produzione. Spetta al fornitore chiarire se il piano tariffario prevede lo staging o i backup.

Oltre alla versione PHP attuale e a quella desiderata, documenta anche le estensioni necessarie e le opzioni rilevanti. Confronta queste informazioni con i requisiti dell'applicazione e con le impostazioni autorizzate dal piano tariffario. Il CloudLinux Manager consente di impostare parametri amministrativi per versioni ed estensioni; ciò non significa tuttavia che ogni opzione sia modificabile autonomamente dai clienti.

Nell'ambiente isolato, testa non solo la pagina iniziale, ma anche le procedure di accesso, i moduli, le importazioni e altre operazioni importanti per il tuo progetto. Verifica separatamente le attività pianificate, poiché la loro esecuzione non è comprovata esclusivamente dalla visualizzazione del sito web. Prendi nota di eventuali anomalie ed elimina i problemi di compatibilità prima del passaggio all’ambiente di produzione.

Infine, inserisci un Viaggio di ritorno Nota bene: chi può ripristinare la versione precedente e quali impostazioni devono essere poi verificate? Pianifica il passaggio in un momento opportuno e monitora successivamente le applicazioni interessate. Il semplice ripristino della versione precedente non garantisce che tutte le estensioni e le opzioni siano state reimpostate come prima.

Verifica di Web, CLI e cronjob

Un sito web e i suoi processi in background non devono necessariamente utilizzare lo stesso interprete PHP. Le richieste HTTP vengono elaborate da un ambiente di esecuzione determinato dal server web e dal relativo gestore; una chiamata da riga di comando, invece, avvia l’interprete che l’ambiente in questione riesce a individuare. CloudLinux distingue i percorsi nativi per gli interpreti web e CLI. La visualizzazione nel PHP Selector, da sola, non risponde quindi a tutte le domande relative all’effettiva esecuzione.

Se SSH è disponibile nel tuo piano tariffario, puoi eseguire il seguente comando di lettura in una sessione di terminale. Esso mostra la versione del Interpreti CLI, che viene individuato proprio per questo richiamo. Per il controllo non sono necessarie modifiche ai file o alle impostazioni.

php -v

Il risultato non indica né la versione PHP di una richiesta HTTP né quella di un cronjob eseguito in altro modo. Un’attività pianificata può utilizzare un percorso dell’interprete specificato esplicitamente o un altro ambiente. Verifica quindi la chiamata memorizzata e l’ambiente di esecuzione del job specifico, anziché basarti sull’output della tua sessione interattiva.

Per il controllo via web, utilizza un metodo protetto e supportato dal fornitore e, se necessario, richiedi l’intervento del responsabile competente. Uno script di diagnostica accessibile pubblicamente con informazioni dettagliate sull’ambiente non rappresenta una soluzione standard adeguata. Verifica anche le attività pianificate tramite un canale supportato e controlla successivamente se, ad esempio, un’importazione o un processo di invio funzioni effettivamente come previsto.

Per ogni percorso di esecuzione rilevante, registra quale versione è prevista e come è stata verificata. Se il pannello, l'output SSH e il comportamento di un job forniscono indicazioni diverse, chiarisci innanzitutto con il fornitore la responsabilità del rispettivo ambiente di esecuzione. In questo modo eviterai di modificare un'impostazione nel posto sbagliato.

Individuare il guasto dopo la sostituzione

Se la pagina iniziale si carica dopo la modifica, ma un modulo o un’importazione non funziona, significa che la migrazione non è stata ancora verificata a sufficienza. Ripeti la procedura in questione e annota l’ora, la funzione e il messaggio di errore riscontrato. Confronta queste informazioni con i log dell’applicazione e del server disponibili, nella misura in cui il tuo piano tariffario ne consenta l’accesso; i dati sensibili dei log non devono essere inseriti in file accessibili al pubblico.

Controlla quindi il Compatibilità dell'applicazione interessata e delle sue estensioni con il ramo PHP selezionato. Un modulo, ad esempio, può dipendere da un plugin che non viene eseguito affatto sulla pagina iniziale. In caso di importazione, sono rilevanti anche le sue dipendenze e il percorso di esecuzione effettivo: un processo in background può utilizzare un runtime diverso da quello del sito web.

Prima di effettuare il passaggio, confronta le estensioni PHP disponibili e attivate per la versione di destinazione, nonché le opzioni necessarie, con la tua documentazione. La scelta di un ramo PHP non garantisce automaticamente che tutti i moduli e le impostazioni necessari siano corretti. Le modifiche che puoi apportare autonomamente dipendono dall'autorizzazione concessa dall'amministratore.

Verifica inoltre se il dominio in questione corrisponda effettivamente a quello previsto gestore e viene utilizzata la durata desiderata. Se sono presenti più interfacce di amministrazione, chiarisci le rispettive competenze con il fornitore prima di modificare ulteriori impostazioni. Una visualizzazione nel Selector non deve necessariamente spiegare quale percorso di esecuzione elabori una richiesta specifica.

Avviso: Non impostare i percorsi di configurazione in modo generico tramite PHPRC oppure PHP_INI_SCAN_DIR . CloudLinux avverte che tali modifiche ai percorsi di configurazione di PHP potrebbero compromettere il funzionamento del Selector. Se si ritiene necessario un percorso specifico, è opportuno chiarirlo prima con il provider.

Se non è possibile risolvere l'errore in tempi brevi, utilizza la procedura di ripristino alla versione precedente stabilita in precedenza. Successivamente, verifica nuovamente la versione effettivamente in uso, le estensioni e le opzioni, nonché le funzioni interessate. Non dare per scontato che il ripristino della versione precedente ripristini automaticamente tutte le impostazioni precedenti; documenta eventuali discrepanze in vista del prossimo tentativo.

Pianificazione della gestione dei sistemi legacy e della migrazione

Per un funzionamento continuativo, il fattore determinante è innanzitutto il Ambito di applicazione: Se è sufficiente una configurazione comune per i domini di un utente gestiti dal Selector, quest’ultimo può rappresentare un’interfaccia adeguata. Se invece due applicazioni richiedono versioni indipendenti, valuta una gestione basata sui domini supportata dal provider o account di hosting separati. La selezione documentata di Selector da sola non garantisce impostazioni indipendenti per ogni dominio all’interno dello stesso account.

I conti separati possono disaccoppiare dal punto di vista organizzativo le decisioni relative alle versioni, a condizione che siano disponibili i rami necessari. Anche una soluzione basata sul dominio può essere adeguata, purché il fornitore la metta a disposizione e sia stata chiarita la sua interoperabilità con altri strumenti PHP. Prima di procedere alla migrazione, informatevi sui costi, sulle condizioni tariffarie e sulle responsabilità; la fattibilità tecnica non implica infatti l’impegno a fornire un determinato pacchetto.

Un’applicazione meno recente non dovrebbe rimanere in modo permanente su un vecchio ramo solo perché questo è selezionabile dal menu. Pianifica la Migrazione per una combinazione supportata di applicazione, dipendenze e PHP: individua gli aggiornamenti mancanti, le estensioni sostituibili e le modifiche necessarie. Stabilisci una data per il prossimo controllo di compatibilità e una data obiettivo per la sostituzione.

Controlla regolarmente lo stato ufficiale del supporto del ramo PHP in uso e monitora al contempo i messaggi di errore e i processi aziendali critici. La disponibilità di un ramo precedente non costituisce garanzia di un supporto ufficiale continuativo. È opportuno ricontrollare la tabella di supporto del progetto PHP prima di ogni decisione a lungo termine, poiché lo stato può cambiare nel tempo.

Se un fornitore promette un supporto esteso, chiedi che ti vengano forniti prove concrete dei pacchetti interessati, del tipo di correzioni di sicurezza e della durata del servizio. Questo supporto va valutato separatamente dal supporto ufficiale di PHP e non sostituisce né gli aggiornamenti dell’applicazione né la migrazione pianificata. Assicurati inoltre di stabilire chi si occuperà di gestire eventuali modifiche e malfunzionamenti durante il periodo di transizione.