Cron PrestaShop che non funziona: il guasto invisibile

Il guasto di cui nessuno si accorge

Un cron PrestaShop che non funziona non provoca alcun errore visibile. Il negozio gira, gli ordini arrivano. Ma il feed prodotti inviato ai comparatori risale a tre settimane fa, le giacenze non si sincronizzano più con l'ERP, i solleciti dei carrelli abbandonati non partono e l'export contabile del mese è vuoto.

Il commerciante scopre il problema da terzi: un cliente che ordina un prodotto esaurito, o un commercialista che reclama un file. Nel frattempo si sono accumulate settimane di danni.

L'equivoco di partenza

Il modulo ps_cronjobs è uno schedulatore interno, non un innesco. Tiene l'elenco delle attività e sa quale deve essere eseguita, ma non si sveglia da solo: serve che un'attività pianificata reale, configurata presso il suo hosting, richiami il suo URL a intervalli regolari.

Molte installazioni si fermano qui: le attività vengono create nel back office, sembra tutto a posto e non verrà mai eseguito nulla. Il modulo propone a volte di appoggiarsi al traffico dei visitatori per attivarsi, il che è imprevedibile e inutilizzabile per un'attività che deve girare a un'ora fissa.

Le cinque cause reali

1. Nessuna attività pianificata lato hosting. Controlli nel pannello di amministrazione del suo hosting, sezione «attività pianificate» o «cron». Se l'elenco è vuoto, ha trovato.

2. La versione di PHP sbagliata. È la trappola degli hosting condivisi. Le attività pianificate girano con PHP da riga di comando, la cui versione è spesso diversa da quella usata dal sito. Lo script finisce così su un PHP datato e fallisce subito, senza che nessuno legga l'output. Occorre indicare il percorso assoluto dell'interprete corretto:

/usr/local/php8.2/bin/php /home/compte/site/modules/ps_cronjobs/cron.php

3. Un token non valido. L'URL delle attività contiene un token di sicurezza. Cambia quando si reinstalla il modulo o si modifica la configurazione. Tutte le attività registrate presso l'hosting restituiscono allora un errore di autorizzazione, in silenzio.

4. Una chiamata bloccata. Un negozio protetto da un'autenticazione HTTP, da una regola del web application firewall o da una restrizione di accesso per indirizzo IP restituisce un errore ancora prima di arrivare a PrestaShop.

5. Un superamento del tempo di esecuzione. Un'attività pesante, come la reindicizzazione della ricerca o un export catalogo voluminoso, supera il limite consentito e si interrompe a metà. Il caso peggiore: lascia dati elaborati solo in parte.

La diagnosi in tre minuti

Test 1: l'attività funziona in HTTP? Copi l'URL completo dell'attività, token incluso, e lo apra in una finestra di navigazione anonima. Se viene eseguita, il problema non è in PrestaShop ma nell'innesco esterno.

Test 2: la riga di comando funziona? La esegua via SSH indicando il percorso assoluto dell'interprete PHP. Un messaggio di errore di sintassi indica una versione di PHP inadatta.

Test 3: che cosa dice il log? Aggiunga sempre una redirezione dell'output nella sua attività pianificata:

wget -q -O - "https://boutique.fr/modules/ps_cronjobs/cron.php?token=XXXX" >> /home/compte/logs/cron.log 2>&1

Senza log si diagnostica alla cieca. È la modifica più redditizia di tutto questo articolo.

La configurazione consigliata

Preferisca la chiamata HTTP all'esecuzione da riga di comando per le attività di PrestaShop. Con wget o curl lo script gira nello stesso contesto del sito: stessa versione di PHP, stesse variabili d'ambiente, stessi permessi. È la prima fonte di discrepanze eliminata.

Distanzi le attività. Tre export catalogo lanciati allo stesso minuto saturano il server e si fanno fallire a vicenda. Li sposti di qualche minuto l'uno dall'altro.

Scelga le ore di minor traffico per le elaborazioni pesanti, tenendo conto dei suoi orari di vendita reali.

Fissi un limite di tempo agli script pesanti e li spezzi in lotti. Un export da 50.000 referenze va trattato a blocchi, con un punto di ripresa.

Monitorare, altrimenti niente

Un cron muto resta un guasto invisibile, anche quando è configurato bene. L'unica protezione è monitorarne l'esecuzione.

Il principio è semplice: al termine dell'esecuzione la sua attività richiama un URL di controllo fornito da un servizio di monitoraggio. Se la chiamata non arriva nella finestra prevista, riceve un avviso. Viene avvisato della mancata esecuzione, non soltanto dell'errore — ed è esattamente ciò che qui manca.

In mancanza di uno strumento esterno, un controllo settimanale basta a contenere i danni: verificare la data dell'ultimo feed generato, la data dell'ultimo export contabile e l'aggiornamento della sincronizzazione delle giacenze.

Sullo stesso tema: le email di sollecito che non partono dipendono spesso da un cron muto più che da un problema di invio; veda la diagnosi delle email PrestaShop.

Rendere affidabili le sue attività pianificate

Analizziamo le sue attività, correggiamo il loro innesco e mettiamo in piedi il monitoraggio. Scopra la nostra offerta di gestione del sito e-commerce.