Risolvere le problematiche di deploy in PHP

Quando portiamo in produzione del codice testato nell'ambiente di sviluppo, è normale avere qualche sorpresa. Uno scenario molto diffuso è il deploy su un server in hosting di alcune pagine PHP: è davvero frustrante scoprire che l'applicazione che girava benissimo in locale, dopo averla copiata via FTP sul server remoto, non apre nemmeno la prima pagina.

Per fissare le idee sulla possibili problematiche di questo tipo, consideriamo il deploy di una web application scritta in PHP su un server Apache.

Lo scenario

Abbiamo un set di pagine PHP, sviluppate in locale, e vogliamo portarle sulla macchina di produzione o post-produzione, che si trova in remoto presso qualche hosting provider. Uploadiamo l'applicazione (ad esempio via FTP) ma quando andiamo a verificare il risultato vediamo solamente pagine bianche, senza alcun errore.

Prima di romperci la testa e dare la colpa a qualche stranezza del codice, ricordiamoci che questo scenario solitamente implica delle differenze tra ambiente locale e ambiente remoto

• Le versioni di Apache e PHP potrebbero essere diverse: se non abbiamo modo di cambiare la versione di Apache o PHP in remoto, è buona norma allineare la macchina locale a quella remota. E' molto popolare la pratica di creare in locale diversi ambienti di sviluppo di tipo AMP, indipendenti tra loro, in modo da poter effettuare delle prove complete in locale. Una buona soluzione è installare pacchetti diversi, come ad esempio XAMPP e easyPHP, in modo da poterli usare in modo indipendente
• La configurazione del PHP remoto non è quasi mai quella di default: il nostro file php.ini locale sarà probabilmente uguale a quello di default, ovvero sarà quello risultante dall'installazione del pacchetto AMP. Un server remoto con supporto PHP avrà invece una configurazione ad hoc, che tende a limitare l'uso delle risorse e chiudere eventuali falle di sicurezza. In molti casi, il provider dell'hosting non ci permette di mettere mano al file php.ini, per cui non è facile individuare le eventuali differenze. In tal caso dovremo mettere la mani al codice PHP: vedremo un esempio di questo tipo più avanti
• Gli errori non vengono mostrati nel browser: nell'ambiente di produzione è buona norma non mostrare messaggi di errore nel browser. In parole povere: un banale syntax error che in locale viene stampato nella finestra del browser, in remoto potrebbe risultare una pagina bianca. Questo per evitare che gli utenti finali vedano cosa non funziona o, peggio ancora, ne approfittino per danneggiare il sistema. Una soluzione potrebbe essere quella di imparare a consultare i files di log
• Controllare i permessi: se la macchina remota è un sistema Linux, in alcuni casi le risorse che abbiamo uploadato potrebbero non avere i permessi necessari per fare quello che devono fare. Questo è abbastanza probabile se abbiamo spostato le risorse da una macchina Windows ad una macchina Linux, perché la gestione dei permessi è molto diversa. Per fortuna molti client FPT permettono di assegnare i permessi tramite un semplice click con tasto destro sulla risorsa

Individuare il problema

Il modo di scoprire cosa non funziona dipende dall'interfaccia dell'hosting provider. Se consideriamo come scenario di hosting un server virtuale gestito (VPS) amministrato usando Plesk, un modo di capire cosa non va è controllare il file di log del web server

Plesk: Log Manager

il pannello permette di controllare il file di apache error_log, dove dovremmo trovare le informazioni che ci servono. Se non abbiamo accesso ai files di log, probabilmente dobbiamo rivolgerci al nostro provider.

Problemi più comuni

Data la vastità delle combinazioni possibili, non è possibile dare indicazioni per risolvere ogni singolo specifico problema. Esistono però alcune situazioni ricorrenti, che si manifestano ad esempio mediante un errore come questo

PHP Parse error: syntax error, unexpected T_STRING

alcune delle cause più frequenti di questo errore sono

• Codifica: controlliamo che la codifica dei nostri files sia UTF-8. Se la codifica è diversa, può capitare di non vedere un “carattere strano” nell'editor locale, che invece viene letto come parte del codice sul server remoto
• Tag abbreviate: ricordiamoci che nel file php.ini è definita la direttiva short_open_tag, di cui abbiamo già parlato in questo articolo. Se le nostre pagine PHP non rispettano la sintassi attesa per la tag di apertura (cioè <? oppure <?php), avremo sicuramente dei problemi
• Dichiarazione XML: una pagina XHTML, prima della dichiarazione del DOCTYPE, dovrebbe contenere una riga come questa

 <?xml version="1.0" encoding="utf-8"?>

 se il server remoto sta usando le tag abbreviate, questa riga verrà interpretata come un pezzo di codice PHP, chiaramente errato. In questo caso la soluzione potrebbe essere stampare la dichiarazione XML a run-time, ad esempio

 echo '<?xml version="1.0" encoding="utf-8"?>' ;

Concludiamo ricordando che gli errori possono dipendere dall'estensione della pagina. Considerando ad esempio l'ultimo caso, una pagina con estensione HTML verrà visualizzata anche se contiene la dichiarazione XML qui sopra, mentre la stessa identica pagina, con estensione PHP (ma senza alcun codice PHP al suo interno), potrebbe dare errore proprio a causa dell'errata interpretazione della tag di apertura.