Aggiornare vTiger CRM: PHP, versioni e passaggio a 8.x

Per aggiornare vTiger CRM da una versione 7.x alla serie 8.x servono tre cose: un backup completo di database e file, un server con PHP 8 configurato secondo i requisiti di vTiger e una prova su una copia prima di toccare il CRM in produzione. Il problema, quasi sempre, non è la patch di migrazione ma il codice personalizzato che non regge le versioni recenti di PHP. In questa guida vediamo versioni, requisiti, errori tipici e quando conviene smettere di aggiornare e migrare.

Qual è oggi l'ultima versione di vTiger open source

Alla data di questo articolo la versione stabile indicata sulla pagina di download ufficiale è vTiger CRM 8.4.0, rilasciata il 9 luglio 2025 e dichiarata compatibile con PHP 8.x. Sulla stessa pagina è disponibile la patch di migrazione dalla 8.3.0 alla 8.4.0, mentre le versioni precedenti restano scaricabili dall'archivio SourceForge del progetto. vTiger stessa raccomanda di usare l'ultima release per ragioni di sicurezza.

Il passaggio a PHP 8 è iniziato già con la 7.5: nel riepilogo del 2022 pubblicato da vTiger l'azienda presenta la 7.5 come la release open source con supporto a PHP 8.x. Chi è fermo a una 7.0, 7.1 o 7.2, invece, ha un codice pensato per PHP 7: nel tracker ufficiale di vTiger si legge che per la 7.1 la documentazione di installazione indicava solo PHP 7.0.

Perché un vTiger 7.x si blocca quando il server aggiorna PHP

Le versioni di PHP hanno un ciclo di vita fisso, pubblicato su php.net. Quando un ramo esce dal supporto di sicurezza, hosting e sistemisti lo dismettono, e un vTiger nato per PHP 7 si ritrova su un server che non lo esegue più. È il motivo più frequente per cui un CRM che funzionava da anni smette di aprirsi da un giorno all'altro.

• PHP 8.2: supporto attivo terminato il 31 dicembre 2024, aggiornamenti di sicurezza fino al 31 dicembre 2026.
• PHP 8.3: aggiornamenti di sicurezza fino al 31 dicembre 2027.
• PHP 8.4: supporto attivo fino al 31 dicembre 2026, sicurezza fino al 31 dicembre 2028.
• PHP 8.5: rilasciato il 20 novembre 2025, sicurezza fino al 31 dicembre 2029.
• PHP 8.1 e precedenti (tutta la serie 7.x): non compaiono più tra le versioni supportate.

In pratica, a fine 2026 anche PHP 8.2 esce dal supporto. Se il tuo vTiger gira ancora su PHP 7.x, o su un server che il provider sta per aggiornare, conviene pianificare l'intervento adesso e non dopo il primo blocco.

Cosa cambia in PHP 8 per il codice di vTiger

La pagina sulle incompatibilità di PHP 8.0 elenca le modifiche che rompono il codice scritto per PHP 7. Tra le più rilevanti per moduli e personalizzazioni datate ci sono la rimozione di create_function() e di each(), l'impossibilità di chiamare staticamente metodi non statici e la trasformazione di diversi avvisi in eccezioni di tipo Error. Il core di vTiger 8.x è stato adeguato; il codice aggiunto negli anni da fornitori diversi, spesso no.

Requisiti tecnici da verificare prima di aggiornare

Il manuale di installazione ufficiale indica i requisiti minimi dell'ambiente. Prima di qualsiasi migrazione controlliamo che il server di destinazione li rispetti tutti, perché molti errori attribuiti alla patch dipendono in realtà dalla configurazione.

• Software: PHP 8.0 o superiore, MySQL 5.1 o superiore, Apache 2.1 o superiore.
• Estensioni PHP: php-imap, php-curl e php-xml.
• php.ini: memory_limit di almeno 256 MB, max_execution_time di almeno 60 secondi, display_errors e short_open_tag disattivati, error_reporting impostato su E_ERROR & ~E_NOTICE & ~E_STRICT & ~E_DEPRECATED.
• MySQL: motore di storage InnoDB, local_infile abilitato, sql_mode vuoto oppure impostato su NO_ENGINE_SUBSTITUTION.

L'ultimo punto è il più sottovalutato. Secondo il manuale di MySQL 8.0 la modalità SQL predefinita include STRICT_TRANS_TABLES e ONLY_FULL_GROUP_BY: su un server nuovo, senza intervento, vTiger può generare errori di salvataggio o query rifiutate che sembrano bug del CRM.

Backup: cosa salvare prima di toccare il CRM

Il manuale di migrazione di vTiger apre con un avviso in maiuscolo: fare il backup dell'installazione esistente, sia del database sia dei sorgenti. Noi aggiungiamo una regola: il backup va ripristinato almeno una volta su un altro server, altrimenti non sai se funziona.

• Dump completo del database, con la stessa codifica dei caratteri dell'originale.
• Intera cartella dell'applicazione, inclusi file di configurazione, privilegi utente generati e documenti allegati.
• Elenco delle estensioni installate e dei file modificati rispetto alla versione originale.
• Configurazione del server: versione di PHP, php.ini, virtual host, cron e certificati.
• Credenziali delle integrazioni: chiavi di accesso usate da sito web, gestionale, moduli di contatto e automazioni.

La procedura di migrazione da 7.x a 8.x

La procedura ufficiale è semplice sulla carta. Si decomprime il pacchetto di patch nella cartella di vTiger, si apre nel browser il percorso /migrate e si seguono le istruzioni del wizard; sui sistemi Linux il processo Apache deve avere i permessi di scrittura sui file.

Lo stesso manuale avverte che lo script di migrazione richiede molto tempo e memoria, che conviene usare sempre la patch più recente e che le tabelle devono essere in InnoDB. Non specifica però come trattare personalizzazioni e moduli di terze parti: è lì che si concentra il lavoro vero.

• 1. Copia di staging: cloniamo database e file su un server separato, con la versione di PHP di destinazione.
• 2. Inventario delle personalizzazioni: confrontiamo i sorgenti con la release originale per trovare ogni file modificato.
• 3. Migrazione di prova: applichiamo le patch nell'ordine corretto e annotiamo ogni errore.
• 4. Correzione del codice custom: adeguiamo moduli, workflow personalizzati e integrazioni a PHP 8.
• 5. Test con gli utenti: chi usa il CRM ogni giorno verifica schede, report, preventivi e automazioni.
• 6. Passaggio in produzione: in una finestra concordata, con il backup pronto per il ripristino.

Moduli personalizzati ed estensioni: il vero rischio

Un vTiger usato da anni raramente è quello installato il primo giorno. Ci sono campi aggiunti, moduli sviluppati su misura, modifiche dirette ai file del core ed estensioni comprate dal marketplace. Ogni elemento va classificato: compatibile, da adeguare o da sostituire.

Le modifiche fatte direttamente nei file del core sono le più pericolose, perché la patch le sovrascrive senza avvisare. In questi casi riportiamo la logica in un modulo separato o in un'estensione, così il prossimo aggiornamento non la cancella. Per i casi più complessi trovi altri esempi nella nostra guida alla personalizzazione di vTiger.

Errori tipici dopo un aggiornamento di PHP e come diagnosticarli

Il sintomo più comune è una pagina bianca. Con display_errors disattivato, come richiesto da vTiger, l'errore non compare a schermo ma finisce nei log: il primo passo è sempre leggere il log di PHP e di Apache, non reinstallare.

• Call to undefined function create_function() o each(): codice scritto per PHP 7 o precedente; va riscritto con funzioni anonime o cicli foreach.
• Non-static method ... cannot be called statically: chiamate statiche a metodi di istanza, frequenti in moduli datati.
• Errori SQL in salvataggio (valori non validi, campi senza default): sql_mode in modalità strict sul nuovo server MySQL.
• Query di report rifiutate: effetto di ONLY_FULL_GROUP_BY su report personalizzati.
• Pagine che si caricano a metà o template rotti: cache dei template compilati non svuotata o permessi di scrittura errati.
• Integrazioni che smettono di funzionare: estensioni PHP mancanti, ad esempio curl o imap, o chiavi di accesso cambiate.

Per diagnosticare in modo ordinato riproduciamo il problema sulla copia di staging, attiviamo un log degli errori dedicato e correggiamo un file alla volta. Se il server permette più versioni di PHP in parallelo, confrontare lo stesso CRM su due versioni isola rapidamente il codice incompatibile.

Quando conviene migrare invece di aggiornare

Aggiornare non è sempre la scelta migliore. Se il CRM è fermo a una 6.x o a una 7.0, se le personalizzazioni sono molte e non documentate o se nessuno sa più cosa fanno certi moduli, il costo dell'adeguamento può superare quello di una ripartenza pulita.

• vTiger 8.x pulito + migrazione dati: installazione nuova, solo le personalizzazioni che servono davvero, dati importati e validati. Ne parliamo nella guida alla migrazione dati verso vTiger.
• Passaggio a Zoho CRM: niente server da gestire, aggiornamenti a carico del fornitore, licenza mensile per utente.
• CRM su misura: quando i processi sono così specifici che ogni piattaforma andrebbe forzata; è il lavoro del nostro servizio di ERP e CRM personalizzati.

Se invece il CRM è già su una 7.x recente e le personalizzazioni sono poche, l'aggiornamento resta la strada più rapida. Le regole generali per pianificarlo sono nell'articolo su aggiornamento e upgrade di vTiger; qui trovi il nostro servizio di assistenza vTiger e Zoho CRM.