I cron di PrestaShop si fermano in silenzio se rinomini la cartella admin

Il sintomo: tutto sembra a posto, e non succede più niente

Nessun errore in nessun pannello. Nessuna mail di avviso. Il negozio, un PrestaShop, funzionava, vendeva, rispondeva normalmente. Il problema è emerso solo guardando una colonna che quasi nessuno controlla mai: updated_at nella tabella ps_cronjobs. Ogni task pianificato del gestionale, dalla rigenerazione della sitemap all'aggiornamento dell'indice di ricerca, riportava la stessa identica data, ferma da settimane. Tutte le procedure automatiche del negozio si erano fermate nello stesso momento, e nessuno se n'era accorto perché fermarsi in silenzio è esattamente quello che fanno: non c'è un errore da vedere, c'è solo l'assenza di qualcosa che dovrebbe succedere e non succede.

Cosa sembrava e non era

Quando ci si accorge che "qualcosa non gira più", il rischio è di concludere troppo in fretta che sia rotto tutto quanto insieme. Non era così, e vale la pena raccontare cosa è stato verificato e scartato prima di arrivare alla causa:

• Gli ordini da un canale di vendita esterno sembravano fermi anche loro. Non lo erano: giravano su una riga separata del crontab, indipendente dal modulo di pianificazione interno di PrestaShop, e non aveva mai smesso di funzionare. Il sospetto iniziale era sbagliato perché si guardava l'effetto (pochi ordini in quel periodo) invece della causa.
• L'indice di ricerca interno sembrava ammuffito. Non lo era: PrestaShop aggiorna l'indice di un prodotto nel momento in cui viene salvato, indipendentemente dal cron. Il task pianificato che "aggiorna l'indice di ricerca" è solo un ricalcolo completo di manutenzione, utile ma non l'unica via con cui i prodotti nuovi finiscono in ricerca. Controllato a campione: i prodotti aggiunti dopo lo stop del cron risultavano già tutti indicizzati.
• Si poteva pensare a un problema di permessi o al servizio di cron del sistema operativo. Anche questo escluso: il crontab esisteva, la riga era lì, e non produceva nessun errore visibile nei log del sistema. Il problema non era che il cron non partisse: era che, quando partiva, non otteneva quello che si aspettava.

La causa vera: la cartella /admin è cambiata, e nessuno ha aggiornato chi la chiama

Rinominare la cartella di amministrazione di PrestaShop (da /admin a qualcosa di imprevedibile) è un consiglio di sicurezza comune, che si trova in praticamente ogni guida su come proteggere un negozio PrestaShop. È anche, quasi sempre, un'operazione fatta una volta e poi dimenticata.

Il meccanismo che esegue i task pianificati di PrestaShop, però, normalmente non è un processo interno che gira da solo: è una chiamata HTTP schedulata (un cron di sistema, o un servizio esterno di scheduling) che ogni ora, o ogni intervallo configurato, richiama un URL preciso, del tipo:

0 * * * * curl -k \
  "https://negozio.esempio/
   admin<vecchionome>/index.php
   ?controller=AdminCronJobs
   &token=..."

Quando la cartella /admin<vecchionome> viene rinominata per sicurezza, quella chiamata prende un 404. Il controller AdminCronJobs non viene mai invocato, e quindi nessun task pianificato viene mai eseguito. Non c'è nessun messaggio d'errore da nessuna parte, perché dal punto di vista di PrestaShop non è successo niente: semplicemente, nessuno ha mai bussato alla porta giusta. La data in cui la cartella è stata rinominata e la data in cui i task hanno smesso di aggiornarsi, controllate, combaciavano esattamente.

Il dettaglio che rende questa causa pericolosa è proprio che rinominare la cartella admin è un'ottima pratica di sicurezza, non un errore. Nessuno la associa istintivamente a "i cron si sono fermati", perché sembrano due argomenti che non hanno niente in comune: uno riguarda la sicurezza del pannello, l'altro riguarda le procedure automatiche in background. Il collegamento esiste solo perché il trigger dei cron, tecnicamente, passa dallo stesso indirizzo del pannello di amministrazione.

C'è stato anche un secondo problema, emerso solo lanciando manualmente il task più importante per verificare che tutto funzionasse una volta corretto l'indirizzo: il token di validazione usato dall'URL della rigenerazione della sitemap non corrispondeva più a quello atteso dallo script. Anche con l'indirizzo giusto, quel singolo task avrebbe continuato a rispondere "token non valido" e a non fare nulla. Sistemare solo il trigger non basta: va verificato che ogni singolo task, chiamato a mano, risponda davvero come dovrebbe, non solo che il crontab punti al posto giusto.

La correzione

1. Aggiornare il crontab con il nome corretto della cartella di amministrazione, dopo aver fatto un backup della riga precedente.
2. Correggere il token del task specifico che risultava non valido, così che riparta da solo al prossimo giro schedulato.
3. Rigenerare a mano l'output fermo, senza aspettare il prossimo giro automatico: nel caso della sitemap, il file era rimasto fermo a settimane prima, e Google nel frattempo continuava a leggere un file che diceva "nessuna novità".
4. Controllare anche il contenuto del file generato, non solo la sua esistenza: il file indice della sitemap riportava una data di ultima modifica vecchia di anni, ereditata da quando era stato creato la prima volta, non aggiornata automaticamente a ogni rigenerazione. Anche quella andava corretta a mano perché tornasse a dire la verità ai motori di ricerca.

Come verificare che tenga

• Chiamare a mano l'URL corretto e controllare che risponda 200 con il contenuto atteso, non fermarsi a "il crontab è aggiornato".
• ps_cronjobs.updated_at che si muove davvero, e nell'ora giusta. PrestaShop esegue ogni task solo nella finestra oraria per cui è stato programmato: un task programmato per la notte non parte se lo si chiama di pomeriggio. Quindi la verifica corretta non è "ho chiamato l'URL e sembra funzionare", ma "il giorno dopo, alla sua ora, quel task ha davvero aggiornato la sua data".
• Verificare l'output dal punto di vista di chi lo consuma: per una sitemap, questo significa controllarla con un browser normale (200) e, nei log del server, controllare che il crawler vero del motore di ricerca la stia effettivamente scaricando con successo, non solo che il file esista sul disco.

La regola da portarsi via, valida per qualunque negozio PrestaShop: se in futuro si rinomina di nuovo la cartella di amministrazione, va aggiornato anche ogni punto che la richiama dall'esterno, crontab compreso. Altrimenti tutte le procedure pianificate si fermano di nuovo, in silenzio, e il primo segnale arriva mesi dopo, quando qualcuno nota per caso una data vecchia in un pannello che di solito non guarda nessuno.

Vale la pena dirlo con onestà, perché rende il problema più credibile di qualunque numero: è successo anche a noi, sul nostro stesso negozio. I solleciti di recensione automatici dopo un acquisto non sono mai partiti, per lo stesso identico motivo di fondo, il cron non c'era e l'indirizzo giusto da chiamare non era scritto da nessuna parte finché non lo abbiamo corretto. Non è un caso isolato che capita solo ai clienti: è un errore facile da fare a chiunque gestisca un negozio PrestaShop, compreso chi scrive questo articolo.