Il vantaggio di usare PrestaShop per un'attività e-commerce è l'abbattimento delle spese necessarie per lo sviluppo di un software su misura, nonché l'enorme riduzione dei tempi di sviluppo, deploy e collaudo. Uno svantaggio potrebbe essere, almeno all'inizio, la difficoltà nel risolvere piccoli problemi di configurazione, o addirittura il debug di malfunzionamenti specifici.
Oggi vedremo come, con un minimo bagaglio di conoscenze tecniche, è possibile procedere alla ricerca di soluzioni ad hoc in caso di inconvenienti di qualsiasi tipo. Quello che vedremo non è la soluzione di un problema specifico, bensì una metodologia generale per affrontare un problema qualsiasi, investigare le cause e tentare una soluzione. A titolo d'esempio faremo riferimento ad un problema concreto, in modo da rendere meno astratta l'esposizione del metodo, ma la procedura che seguiremo sarà generica e applicabile in molti altri casi (i.e. altri CMS o applicazioni generiche).
Il problema
Per fissare le idee consideriamo un caso banale. Abbiamo installato PrestaShop in locale, senza alcun problema, e configurato il negozio. Decidiamo di andare live e portiamo la nostra installazione in remoto, sul server in hosting. A questo punto non riusciamo più ad aprire il pannello del backoffice che visualizza l'elenco del moduli installati. E' uno degli scenari peggiori, perché se non possiamo accedere ai moduli del backoffice, non riusciremo a modificare alcuna delle impostazioni del negozio, dalla grafica della home page fino alle modalità di pagamento.
In questi casi, di solito, si esegue una ricerca su internet per vedere se qualcuno ha già avuto (e risolto) il nostro stesso problema. Quasi sicuramente troveremo delle soluzioni, ma non è detto che vadano bene anche a noi. Continuando l'esempio visto sopra (i.e. la tab dei moduli non si apre), potremmo credere che si tratti di un problema del memory_limit di PHP, come discusso in questo articolo.
Siccome vogliamo indagare una metodologia efficiente, e non discutere il caso particolare, supponiamo che cambiando il memory_limit non risolva nulla. Il server accetta il nuovo valore, in locale funziona tutto, ma in remoto continuiamo a non poter aprire la tab dei moduli. Cosa resta da fare?
Il metodo
Se la ricerca sul web non porta a nulla, prima di disperare ricordiamoci sempre qual è lo strumento principe di analisi delle problematiche di un server remoto: l'analisi dei files di log.
Abbiamo già visto come accedere al gestore dei files di log nel caso di una VPS amministrata via Plesk.
Quando abbiamo sotto mano il file di log, di solito abbiamo due scenari:
- Il problema è replicabile quando vogliamo
- Il problema non è replicabile
L'esempio in questione è replicabile, perché basta collegarsi al backoffice di PrestaShop, tentare di aprire la tab dei moduli e guardare cosa succede nel file di log. Per i problemi non replicabili è invece necessario avere qualche indicazione dettagliata delle condizioni che generano l'errore. A seconda del contesto questi “indizi” potrebbero essere: l'orario esatto del malfunzionamento, il nome dell'utente coinvolto, l'ID del prodotto/oggetto interessato dal problema, ecc. Con questi indizi dovremo setacciare i files di log e ricostruire gli eventi, lavorando come investigatori sulla scena del crimine. Se siamo su Linux potrebbe essere utile l'uso del comando grep per filtrare opportunamente i files di log.
Una volta identificato l'errore avremo sotto gli occhi un messaggio più o meno comprensibile, ad esempio
PHP Parse error: syntax error, unexpected ':' in /var/www/vhosts/mydomain.it/subdomains/mysite/httpdocs/modules/paysafecard/PrepaidServices.php on line 181, referer: http://studioteam.hostingtech.it/admin_foo/index.php?tab=AdminThemes&token=f3d0016e2975c01cca0b6ad994d4862d
Per quanto il messaggio possa sembrare criptico, in realtà siamo a cavallo. In molti casi basterà copiare il messaggio in un motore di ricerca per trovare la soluzione specifica al nostro problema. Il vantaggio del log, in questo caso, è la possibilità di cercare sul web le parole chiavi esatte, emerse dall'analisi del file di log, anziché quelle dedotte da una diagnosi superficiale del problema.
Se non abbiamo accesso al file di log, possiamo provare ad abilitare la visualizzazione dei messaggi d'errore direttamente nel browser. Nel caso di PrestaShop ciò significa editare il file
<root>/config/config.inc.php
e cambiare la configurazione della proprietà display_errors
ini_set(‘display_errors’, ‘on’)
in questo modo dovremmo trovare la stessa indicazione vista sopra: il principale sospetto è la linea 181 del file PrepaidServices.php.
Una volta identificata la pagina (in questo caso addirittura la riga) del problema si entra nel vivo della questione, e non è più possibile fornire indicazioni generali. Dovremo guardare la codice e tirare fuori qualche competenza tecnica, ma il grosso del lavoro è fatto: siamo partiti da un problema sconosciuto, che riguardava l'intera applicazione, e siamo arrivati ad un problema specifico, circoscritto a poche line e di codice. Come ultimo consiglio, per problemi di questi tipo, ricordiamoci che in genere le differenze tra la macchina locale e il server remoto riguardano la codifica dei caratteri, la configurazione del server, l'ambiente di runtime e la versione PHP: sono questi i principali fattori di cui tener conto per trovare la causa esatta di un problema che si manifesta solo in remoto.
