PrestaShop-cron draait niet: de onzichtbare storing

De storing die niemand opmerkt

Een PrestaShop-cron die niet draait, geeft geen zichtbare fout. De webshop draait, bestellingen komen binnen. Alleen is de productfeed naar de vergelijkingssites drie weken oud, synchroniseert de voorraad niet meer met het ERP, gaan de herinneringen voor verlaten winkelwagens niet uit en is de boekhoudexport van de maand leeg.

De eigenaar hoort het van iemand anders: een klant die een uitverkocht product bestelt, of een boekhouder die om een bestand vraagt. Ondertussen is er weken schade opgelopen.

Het misverstand aan het begin

De module ps_cronjobs is een interne planner, geen aanjager. Hij houdt de takenlijst bij en weet welke taak aan de beurt is, maar hij wordt niet uit zichzelf wakker: er moet een echte geplande taak bij uw hostingpartij zijn ingesteld die zijn URL met vaste regelmaat aanroept.

Veel installaties houden daar op: de taken zijn in de back-office aangemaakt, alles ziet er goed uit, en er zal nooit iets draaien. De module biedt soms aan zich door het bezoekersverkeer te laten aanjagen, wat onvoorspelbaar is en onbruikbaar voor een taak die op een vast tijdstip moet lopen.

De vijf echte oorzaken

1. Er staat geen geplande taak bij de hostingpartij. Kijk in het beheerpaneel van uw hosting, bij "geplande taken" of "cron". Is de lijst leeg, dan hebt u de oorzaak gevonden.

2. De verkeerde PHP-versie. Dat is de valkuil van gedeelde hosting. Geplande taken draaien op PHP via de commandoregel, waarvan de versie vaak afwijkt van die van de site. Het script komt dan op een oude PHP terecht en faalt onmiddellijk, zonder dat iemand de uitvoer leest. Geef het absolute pad naar de juiste interpreter op:

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

3. Een ongeldig token. De URL van de taken bevat een beveiligingstoken. Dat verandert bij een herinstallatie van de module of bij een configuratiewijziging. Alle bij de hostingpartij vastgelegde taken geven dan stilzwijgend een autorisatiefout.

4. Een geblokkeerde aanroep. Een webshop achter HTTP-authenticatie, een regel van de web application firewall of een IP-beperking geeft een fout nog voordat PrestaShop wordt bereikt.

5. Overschrijding van de uitvoeringstijd. Een zware taak, zoals het herindexeren van de zoekfunctie of een omvangrijke catalogusexport, gaat over de toegestane limiet heen en breekt halverwege af. Het ergste geval: er blijven half verwerkte gegevens achter.

De diagnose in drie minuten

Test 1: werkt de taak via HTTP? Kopieer de volledige URL van de taak, inclusief token, en open die in een privévenster. Draait hij, dan ligt het niet aan PrestaShop maar aan de externe aansturing.

Test 2: werkt de commandoregel? Voer hem via SSH uit met het absolute pad naar de PHP-interpreter. Een syntaxisfout wijst op een ongeschikte PHP-versie.

Test 3: wat zegt het logboek? Voeg in uw geplande taak standaard een omleiding van de uitvoer toe:

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

Zonder logboek stelt u blind een diagnose. Dit is de meest rendabele aanpassing uit dit hele artikel.

De aanbevolen configuratie

Geef voor PrestaShop-taken de voorkeur aan een HTTP-aanroep boven uitvoering via de commandoregel. Met wget of curl draait het script in dezelfde context als de site: dezelfde PHP-versie, dezelfde omgevingsvariabelen, dezelfde rechten. Daarmee valt de eerste bron van verschillen weg.

Zet taken uit elkaar. Drie catalogusexports die op dezelfde minuut starten, lopen de server vast en laten elkaar mislukken. Verschuif ze een paar minuten.

Kies de daluren voor zware verwerkingen, rekening houdend met uw werkelijke verkooptijden.

Stel een tijdslimiet in voor zware scripts en knip ze op in batches. Een export van 50.000 referenties hoort in delen te worden verwerkt, met een hervattingspunt.

Bewaken, anders heeft het geen zin

Een zwijgende cron blijft een onzichtbare storing, ook als hij goed is ingesteld. De enige bescherming is de uitvoering bewaken.

Het principe is eenvoudig: uw taak roept aan het einde van zijn uitvoering een controle-URL aan die een monitoringdienst levert. Blijft die aanroep binnen het verwachte tijdvenster uit, dan krijgt u een melding. U wordt dus gewaarschuwd bij het uitblijven van de uitvoering, niet alleen bij een fout — precies wat hier ontbreekt.

Hebt u geen externe tool, dan beperkt een wekelijkse controle de schade al: kijk naar de datum van de laatst gegenereerde feed, de datum van de laatste boekhoudexport en hoe vers de voorraadsynchronisatie is.

In hetzelfde verband: herinneringsmails die niet uitgaan, komen vaker door een zwijgende cron dan door een verzendprobleem. Zie de diagnose van PrestaShop-e-mails.

Uw geplande taken betrouwbaar maken

Wij controleren uw taken, herstellen de aansturing en zetten de bewaking op. Bekijk ons aanbod voor webshopbeheer.