PHP functie (automatisch) periodiek laten uitvoeren
Ik zit weer met een nieuw probleem...
Ik heb een (webshop)systeem gemaakt waarbij leden bestellingen kunnen posten.
- Men krijgt tijdens het plaatsen (net voor de betaling) een bevestigingsmail waarin staat dat de bestelling is opgeslagen in de database. (De bestelling heeft op dit moment de status 'in behandeling')
- Vervolgens dient men via Paypal of iDeal de betaling af te ronden en wordt men terug naar de website gestuurd.
Het kan nu dus zijn dat een klant een bestelling plaatst maar (met opzet of per ongeluk) nooit zal betalen. Het lijkt mij daarom ideaal om periodiek de database door te lopen op bestellingen die niets anders doen dan stof vangen (bij wijze van spreken) en om deze uit het systeem te gooien.
Voor het bewerken van de database (en het eventueel versturen van een notificatie email) heb ik geen hulp nodig, ik vroeg mij alleen af of het mogelijk is om dit proces puur automatisch te laten lopen.
Ik heb gelezen dat cronjob periodiek scripts kan uitvoeren, maar aangezien ik hier nog nooit mee heb gewerkt wil ik eerst naar mijn mogelijkheden binnen de PHP omgeving zoeken. Daarbij maak ik geen gebruik van cPanel, dus ik hoop dat er ook een open-source oplossing voor dit probleem is.
In het kort ziet het scenario er dus zo uit:
1. Klant plaatst bestelling [database wordt geüpdate met een bestelling]
2. Klant 'vergeet' te betalen.
(2 weken gaan voorbij)
3. Script loopt automatisch na welke bestellingen ouder of even oud als 2 weken zijn en verwijderd deze.
Optioneel ben ik van plan om de webadmin en de klant een mail te sturen na 1 week om ze nogmaals op de hoogte te stellen van de onbetaalde bestelling.
====
Mijn deskresearch:
Ik ben ervan op de hoogte hoe ik moet 'rekenen met datums', maar ik weet niet of ik een functie kan maken waarbij ik zeg:
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
2
3
4
5
6
7
8
9
10
11
12
13
14
15
<?
///in UNIX
$nu = time ();
$deadline = strtotime ("+7 weeks", $nu);
// Dit zou ik automatisch op de deadline willen laten lopen.
/* Alternatief zou ik een maandelijkse check kunnen houden
om de database op te schonen. Maar dan wel automatisch
zodat er geen administrator hoeft te zijn om deze check
zelf uit te voeren. */
if($record['datum_geplaatst'] >= $deadline)
{
// Delete record uit SQL database
}
?>
///in UNIX
$nu = time ();
$deadline = strtotime ("+7 weeks", $nu);
// Dit zou ik automatisch op de deadline willen laten lopen.
/* Alternatief zou ik een maandelijkse check kunnen houden
om de database op te schonen. Maar dan wel automatisch
zodat er geen administrator hoeft te zijn om deze check
zelf uit te voeren. */
if($record['datum_geplaatst'] >= $deadline)
{
// Delete record uit SQL database
}
?>
Weer iemand hoe ik een dergelijke functie zonder (directe) interactie van de gebruiker kan laten lopen?
Of moet dit met cronjob? Zo ja, heeft iemand een bron voor mij waarmee ik kan leren hoe cronjob werkt (zonder cPanel, als dat bestaat)? http://www.cronjob.nl/ ken ik (dit gaat over cPanel, voor de rest: tl;dr), maar het liefst heb ik een bron met voorbeelden of oefeningen.
================
EDIT: tl;dr was een domme keuze. Ik zie dat DirectAdmin ook wordt behandeld. Ik weet niet of alle web panelen cronjob wizards hebben, maar als dat wel zo is dan is dit appeltje eitje!
Gewijzigd op 29/08/2012 22:08:04 door Christopher A
Ik zet zo elke 15 minuten een voorbeeld database terug, die gebruikers hebben mogen testen.
Je php mag wel echo's gebruiken om dingen te laten zien tijdens het debuggen, maar geen html sturen.
In je query kun je rekenen met interval.
Gewijzigd op 29/08/2012 22:07:14 door Obelix Idefix
John Berg op 29/08/2012 22:03:24:
Je php mag wel echo's gebruiken om dingen te laten zien tijdens het debuggen, maar geen html sturen.
Bedankt voor de tip! Dat wist ik nog niet. Het is de bedoeling dat het script alleen mails verzend en de database bijwerkt zonder echo's oid.
Obelix en Idefix op 29/08/2012 22:05:57:
Wat je met cronjob kunt doen is het aanroepen van een (php)bestand om dat uit te voeren. Je kunt er ook voor kiezen om, zodra bv je index-pagina wordt aangeroepen een scriptje te starten wat de database opschoont.
Ik ben er bang voor dat wanneer ik het script telkens via de index pagina aanroep mijn admin en/of de klant(en) vol worden gespamt met mails wanneer er bestellingen binnen de uitzondering vallen.
Christopher A op 29/08/2012 22:12:09:
Ik ben er bang voor dat wanneer ik het script telkens via de index pagina aanroep mijn admin en/of de klant(en) vol worden gespamt met mails wanneer er bestellingen binnen de uitzondering vallen.
Obelix en Idefix op 29/08/2012 22:05:57:
Wat je met cronjob kunt doen is het aanroepen van een (php)bestand om dat uit te voeren. Je kunt er ook voor kiezen om, zodra bv je index-pagina wordt aangeroepen een scriptje te starten wat de database opschoont.
Ik ben er bang voor dat wanneer ik het script telkens via de index pagina aanroep mijn admin en/of de klant(en) vol worden gespamt met mails wanneer er bestellingen binnen de uitzondering vallen.
Je hoeft ook niet telkens alle code uit te voeren. Je kan bijvoorbeeld ergens bijhouden in de database wanneer de schoonmaak het laatst is uitgevoerd. Als je dan ziet, hé, het is al 24 uur geleden, dan mag de schoonmaak weer beginnen.
Persoonlijk zou ik echter wel voor een CronJob gaan in dit geval.
Christopher A op 29/08/2012 22:12:09:
Bedankt voor de tip! Dat wist ik nog niet. Het is de bedoeling dat het script alleen mails verzend en de database bijwerkt zonder echo's oid.
Ik ben er bang voor dat wanneer ik het script telkens via de index pagina aanroep mijn admin en/of de klant(en) vol worden gespamt met mails wanneer er bestellingen binnen de uitzondering vallen.
John Berg op 29/08/2012 22:03:24:
Je php mag wel echo's gebruiken om dingen te laten zien tijdens het debuggen, maar geen html sturen.
Bedankt voor de tip! Dat wist ik nog niet. Het is de bedoeling dat het script alleen mails verzend en de database bijwerkt zonder echo's oid.
Obelix en Idefix op 29/08/2012 22:05:57:
Wat je met cronjob kunt doen is het aanroepen van een (php)bestand om dat uit te voeren. Je kunt er ook voor kiezen om, zodra bv je index-pagina wordt aangeroepen een scriptje te starten wat de database opschoont.
Ik ben er bang voor dat wanneer ik het script telkens via de index pagina aanroep mijn admin en/of de klant(en) vol worden gespamt met mails wanneer er bestellingen binnen de uitzondering vallen.
Dat hangt geheel van je script af, echter zou ik toch gaan voor de cronjob anders ben je namelijk afhankelijk van wanneer en hoevaak de website bezocht wordt. Wat bijvoorbeeld snachts minder vaak zal zijn. Zo zou je hier dus geen invloed meer op hebben.
Stefan van den Broek op 30/08/2012 08:52:13:
Dat hangt geheel van je script af, echter zou ik toch gaan voor de cronjob anders ben je namelijk afhankelijk van wanneer en hoevaak de website bezocht wordt. Wat bijvoorbeeld snachts minder vaak zal zijn. Zo zou je hier dus geen invloed meer op hebben.
Christopher A op 29/08/2012 22:12:09:
...
Dat hangt geheel van je script af, echter zou ik toch gaan voor de cronjob anders ben je namelijk afhankelijk van wanneer en hoevaak de website bezocht wordt. Wat bijvoorbeeld snachts minder vaak zal zijn. Zo zou je hier dus geen invloed meer op hebben.
Dat klopt, ik denk dat achteraf gezien cronjob betrouwbaarder is, met de gedachte dat de taak wordt uitgevoerd ondanks het aantal bezoekers.
Om de spam tegen te gaan had ik al bedacht om een bestelling waarop een mail is gestuurd bijvoorbeeld de waarde '1' te geven in de database in het veld 'checked'. Als dit veld op 0 staat is er nog geen mail gestuurd, maar wanneer dit een 1 is wel. Op die manier voorkom ik die redundante berichten. (Vergelijkbaar met een account-verificatie wanneer gebruikers via hun mail op een link moeten klikken om het te activeren.)
Desalniettemin zal ik via DirectAdmin de cronjob uitvoeren. Bedankt voor de tips iedereen!
Ik maak dus een script dat elke week wordt nagelopen:
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
2
3
4
5
6
7
8
9
10
11
12
if ((record >= 1 week oud) && status == '1' && delete_mail == '0')
{
stuur mail;
}
elseif ((record >= 2 weken oud) && status == '1' && delete_mail == '1')
{
verwijder gegevens/records;
}
elseif (status != '1' && delete_mail == '1')
{
Verander delete_mail terug naar '0';
}
{
stuur mail;
}
elseif ((record >= 2 weken oud) && status == '1' && delete_mail == '1')
{
verwijder gegevens/records;
}
elseif (status != '1' && delete_mail == '1')
{
Verander delete_mail terug naar '0';
}
In het kort ziet het er zo uit. Ik zal er uiteindelijk nog wat aan toevoegen om ervoor te zorgen dat er geen mails worden gestuurd of records worden verwijderd wanneer dat niet hoort.
Gewijzigd op 30/08/2012 16:52:53 door Christopher A
ik neem aan dat je 24/7 kan bestellen? dus de weken lopen verschillend van elke klant zeker? ik zal zeggen doe elke uur een controle pas natuurlijk wel op dat de script niet de server over belast wat ik dus had met een check voor mensen die hun email nog niet hadden bevestigt!
Maar cronjob met directadmin gaat vrij wel simpel hou wel deze code er voor:
/usr/local/bin/php -q -f
want daar had ik een fout waardoor de script niet werd uitgevoerd XD
Ik ben zelf reseller, en de mailserver die komt echt niet klagen over 1000 mails meer of minder hoor :-)
Toevoeging op 30/08/2012 21:29:18:
Als het om grote hoeveelheden mails zou gaan, kan het interessant zijn een batch oplossing uit te werken / te gebruiken. Maar al moet ik zegen dat een beetje host tegenwoordig toch veel kan verwerken.
Ik ben zelf reseller, en de mailserver die komt echt niet klagen over 1000 mails meer of minder hoor :-)
ScrapZz nl op 30/08/2012 20:55:35:
Elke week??
ik neem aan dat je 24/7 kan bestellen? dus de weken lopen verschillend van elke klant zeker? ik zal zeggen doe elke uur een controle pas natuurlijk wel op dat de script niet de server over belast wat ik dus had met een check voor mensen die hun email nog niet hadden bevestigt!
ik neem aan dat je 24/7 kan bestellen? dus de weken lopen verschillend van elke klant zeker? ik zal zeggen doe elke uur een controle pas natuurlijk wel op dat de script niet de server over belast wat ik dus had met een check voor mensen die hun email nog niet hadden bevestigt!
Hij stuurt wel pas een mail wanneer de bestelling al langer dan een week onbetaald is, dus klanten hebben vanaf de mail al een week of langer de tijd gehad om te betalen. De periode waarin een klant een mail kan verwachten is dus tussen de 7 en 13 dagen na een bestelling. Ik besef dat dit ook betekend dat klanten die de mail pas na 13 dagen ontvangen maar 1 dag hebben tot de volgende check plaatsvindt. Daardoor is het idd handiger om de check vaker te laten plaatsvinden. Misschien is 2-3x per week een uitkomst om de server niet te veel te laten belasten.
In de mail staat dus niet dat er wezenlijk nog maar 1 week over is, maar bijvoorbeeld dat deze klant een bestelling heeft die al langer dan een week onbetaald is gebleven. Ze hebben uiteraard een pagina waarop zij hun bestel geschiedenis kunnen terugvinden, dus worden er in de praktijk wel minimaal 2 weken aan alle klanten gegund om hun bestellingen af te ronden.
ScrapZz nl op 30/08/2012 20:55:35:
Maar cronjob met directadmin gaat vrij wel simpel hou wel deze code er voor:
/usr/local/bin/php -q -f
want daar had ik een fout waardoor de script niet werd uitgevoerd XD
/usr/local/bin/php -q -f
want daar had ik een fout waardoor de script niet werd uitgevoerd XD
Bedankt! Dit soort dingetjes wist ik nog niet omdat ik nog nooit met cronjob heb gewerkt. Dit voorkomt mij weer een dag of twee vol ergernis omdat ik niet er maar niet achter kan komen waarom m'n script niet werkt :P
Write Down op 30/08/2012 21:29:12:
Als het om grote hoeveelheden mails zou gaan, kan het interessant zijn een batch oplossing uit te werken / te gebruiken. Maar al moet ik zegen dat een beetje host tegenwoordig toch veel kan verwerken.
Ik ben zelf reseller, en de mailserver die komt echt niet klagen over 1000 mails meer of minder hoor :-)
Toevoeging op 30/08/2012 21:29:18:
Als het om grote hoeveelheden mails zou gaan, kan het interessant zijn een batch oplossing uit te werken / te gebruiken. Maar al moet ik zegen dat een beetje host tegenwoordig toch veel kan verwerken.
Ik ben zelf reseller, en de mailserver die komt echt niet klagen over 1000 mails meer of minder hoor :-)
Ik ben zelf reseller, en de mailserver die komt echt niet klagen over 1000 mails meer of minder hoor :-)
Toevoeging op 30/08/2012 21:29:18:
Als het om grote hoeveelheden mails zou gaan, kan het interessant zijn een batch oplossing uit te werken / te gebruiken. Maar al moet ik zegen dat een beetje host tegenwoordig toch veel kan verwerken.
Ik ben zelf reseller, en de mailserver die komt echt niet klagen over 1000 mails meer of minder hoor :-)
Dat vermoed ik ook. Daarbij heeft mijn klant maar 1 domein (zonder subdomeinen) in gebruik, dus wanneer het zover komt heb ik gewoon weer een nieuwe klus binnen! :)
Gewijzigd op 30/08/2012 22:02:42 door Christopher A
Christopher A op 30/08/2012 22:00:10:
Hij stuurt wel pas een mail wanneer de bestelling al langer dan een week onbetaald is, dus klanten hebben vanaf de mail al een week of langer de tijd gehad om te betalen. De periode waarin een klant een mail kan verwachten is dus tussen de 7 en 13 dagen na een bestelling. Ik besef dat dit ook betekend dat klanten die de mail pas na 13 dagen ontvangen maar 1 dag hebben tot de volgende check plaatsvindt. Daardoor is het idd handiger om de check vaker te laten plaatsvinden. Misschien is 2-3x per week een uitkomst om de server niet te veel te laten belasten.
In de mail staat dus niet dat er wezenlijk nog maar 1 week over is, maar bijvoorbeeld dat deze klant een bestelling heeft die al langer dan een week onbetaald is gebleven. Ze hebben uiteraard een pagina waarop zij hun bestel geschiedenis kunnen terugvinden, dus worden er in de praktijk wel minimaal 2 weken aan alle klanten gegund om hun bestellingen af te ronden.
In de mail staat dus niet dat er wezenlijk nog maar 1 week over is, maar bijvoorbeeld dat deze klant een bestelling heeft die al langer dan een week onbetaald is gebleven. Ze hebben uiteraard een pagina waarop zij hun bestel geschiedenis kunnen terugvinden, dus worden er in de praktijk wel minimaal 2 weken aan alle klanten gegund om hun bestellingen af te ronden.
Is dit niet beetje dubbel zinnig? Je gunt een klant op de pagina 2 weken om een betaling af te ronden. Maar via de mail lopen ze de kans of nog maar 1 dag te hebben of de volgende keer 9 dagen.
Vind je niet persoonlijk als klant zijnde, dat je altijd ongeacht wanneer je besteld altijd de zelfde hoeveelheid dagen over hebt om een bestelling af te ronden. Maar ook dat je via een mail herindering krijgt ook altijd nog de zelfde dagen hebt.
Ik zou persoonlijk een mail opstellen waarin je de volgende zaken opneemt:
- Klant nr
- Klant naam
- Adres
- Factuur nr
- Bestelling datum
- Bestelde goederen
- Totaal bedrag
- Indien al een bedrag is voldaan, dit melden
- Link na betaal mogelijkheden (Indien aanwezig anders betaal mogelijkheden vermelden)
- En dan een korte uitleg dat er indien binnen 7 dagen niet de factuur is voldaan, de bestelling zal worden gedelete.
Zo weet je klant direct van: Heej oeps, die moet ik snel betalen. Wat heb ik ook al weer besteld en wat kost het mij. Ook is het altijd duidelijk dat hij nog 7 dagen heeft en niet hoeft te gissen van. Go heb ik nu nog 1 dag of 9 dagen.
Stuur een mail na 7 dagen. Dat is prima te scripten (en met cronjob uit te voeren).
Dus niet 6 dagen geleden (die komt morgen aan de beurt) of 8 dagen (die was gisteren aan de beurt).
Dan voer je die cronjob elke dag uit, maar heb je wel minder records te verwerken (theoretisch 7x zo weinig als wanneer je het 1x in de week doet).
Je hebt de DATE(TIME) vast wel in de database staan, dan is daar prima op te selecteren met DATE_SUB.
Het zou idd beter zijn om de cronjob elke dag te laten lopen, maar dan loop ik het risico dat de server overbelast raakt zoals eerder in dit topic wordt aangegeven.
Ik voer de cronjob vanaf nu elke dag (middernacht) uit, dan heeft elke klant gelijke kansen. Als dit de server overbelast probeer ik eerst het script te verlichten en verminder anders de frequentie hoe vaak het wordt uitgevoerd.
Gewijzigd op 31/08/2012 12:52:15 door Christopher A
Christopher A op 31/08/2012 09:41:16:
Bij het plaatsen van de bestelling krijgen klanten ook een mail met uitleg over de 2 weken, en de periode is dan tussen 7 en 1 dagen lang. Dat is gewoon de factuur mail waar tevens de uitleg over dit systeem staat uitgelegd.
Ja je moet het zelf weten natuurlijk. Maar ik zou al die info niet eens in je mail stoppen bij een geposte bestelling. Wat heeft die info te maken met de daadwerkelijke bestelling. Ja je moet het zelf weten hoor.
Maar als ik bij je bestel en ik vergeet te betalen, wat altijd kan gebeuren.
Als ik dan merk eerste keer heb ik 4 dagen om te betalen en de volgende keer ma 1 dag. Dan kan ik je nu al zeggen dat de 2e bestelling gelijk de laatste was.
Want als ik merk dat een webshop niet gelijk matig met de betaal tijden om gaat, dan weet ik genoeg en gooi de link in het vergeet me "heel erg" snel prullebak.
Kortom: Mijn mening is dat je daar de plank gewoon heel erg misslaat. Neem meer tijd voor je webshop en bouw het zoals een klant mag verwachten en werk overal waar je melding mails wilt sturen met de zelfde tijds aanduiding. Wat je nu wilt lijkt er in mijn ogen gewoon niet op.
Gewijzigd op 31/08/2012 10:31:00 door Frank WD
Christopher A op 31/08/2012 09:41:16:
Als dit de server overbelast probeer ik eerst het script te verlichten en verminder anders de frequentie hoe vaak het wordt uitgevoerd.
Gebeurt niet!
Of je nou 7x 100 records doet of 1x 700.... blijft even veel.
Voor je load kan je hetzelfs beter verdelen.
Ik run op mijn server ook een cronjob om de 10 minuten. Die duurt ongeveer 20 seconden.
Alsof de server er ook maar iets van merkt... nee.
Zoals anderen ook zeggen: wees snel en op vaste tijden.
Ik zou persoonlijk zoiets zelfs om het uur runnen. Na bestellen en in het uur niet betaald: mailen!
En daarna elke 3 dagen of zo. Desnoods om de 7 dagen (dus 3x: 1x na een uur, 1x na een week, 1x na 2 weken >> verwijderen en melden dat de bestelling geannuleerd is).
Zo'n cronjob is net zo zwaar als 1 http-request van een klant. Dus of er nou 1 bezoeker of 1 cronjob iets doet... maakt niets uit.
Christopher A op 31/08/2012 09:41:16:
Ik voer de cronjob vanaf nu elke dag (middernacht) uit
Dat is het tijdstip waarop de meeste een cronjob (lijken te) starten. Als je het dan over serverbelasting hebt: voer de cronjob dus niet om middernacht uit, maar bv. om 4.21 uur.
Eddy Erkelens op 31/08/2012 10:57:14:
Gebeurt niet!
Of je nou 7x 100 records doet of 1x 700.... blijft even veel.
Voor je load kan je hetzelfs beter verdelen.
Ik run op mijn server ook een cronjob om de 10 minuten. Die duurt ongeveer 20 seconden.
Alsof de server er ook maar iets van merkt... nee.
Zoals anderen ook zeggen: wees snel en op vaste tijden.
Ik zou persoonlijk zoiets zelfs om het uur runnen. Na bestellen en in het uur niet betaald: mailen!
En daarna elke 3 dagen of zo. Desnoods om de 7 dagen (dus 3x: 1x na een uur, 1x na een week, 1x na 2 weken >> verwijderen en melden dat de bestelling geannuleerd is).
Zo'n cronjob is net zo zwaar als 1 http-request van een klant. Dus of er nou 1 bezoeker of 1 cronjob iets doet... maakt niets uit.
Of je nou 7x 100 records doet of 1x 700.... blijft even veel.
Voor je load kan je hetzelfs beter verdelen.
Ik run op mijn server ook een cronjob om de 10 minuten. Die duurt ongeveer 20 seconden.
Alsof de server er ook maar iets van merkt... nee.
Zoals anderen ook zeggen: wees snel en op vaste tijden.
Ik zou persoonlijk zoiets zelfs om het uur runnen. Na bestellen en in het uur niet betaald: mailen!
En daarna elke 3 dagen of zo. Desnoods om de 7 dagen (dus 3x: 1x na een uur, 1x na een week, 1x na 2 weken >> verwijderen en melden dat de bestelling geannuleerd is).
Zo'n cronjob is net zo zwaar als 1 http-request van een klant. Dus of er nou 1 bezoeker of 1 cronjob iets doet... maakt niets uit.
Ah mooi, in dat geval blijf ik het script elke dag nalopen.
Ik voer de cronjob rond een uur of 4-5 's ochtends uit, dat lijken mij de minst voorkomende tijdstippen waarop klanten een bestelling zullen plaatsen (uit Nederland).
Daarbij wordt de eerste mail gestuurd omdat de bestelling in de database wordt opgeslagen voordat de betaling is gemaakt (via iDeal of Paypal). Om er voor te zorgen dat de database niet vol raakt met openstaande bestellingen wil ik dit systeem gebruiken.
Nadat de betaling heeft plaatsgevonden krijgt de klant uiteraard weer een mail dat de bestelling is afgerond en deze zsm wordt verzonden.
Frank WD op 31/08/2012 10:28:28:
Ja je moet het zelf weten natuurlijk. Maar ik zou al die info niet eens in je mail stoppen bij een geposte bestelling. Wat heeft die info te maken met de daadwerkelijke bestelling. Ja je moet het zelf weten hoor.
Het hoofdonderwerp van de mail is natuurlijk de factuur. De 'regels' over het betalen van de rekening worden in het kort (1 a 2 zinnen) uitgelegd en zijn anders bij de Algemene Voorwaarden terug te vinden.
Frank WD op 31/08/2012 10:28:28:
Maar als ik bij je bestel en ik vergeet te betalen, wat altijd kan gebeuren.
Als ik dan merk eerste keer heb ik 4 dagen om te betalen en de volgende keer ma 1 dag. Dan kan ik je nu al zeggen dat de 2e bestelling gelijk de laatste was.
Want als ik merk dat een webshop niet gelijk matig met de betaal tijden om gaat, dan weet ik genoeg en gooi de link in het vergeet me "heel erg" snel prullebak.
Kortom: Mijn mening is dat je daar de plank gewoon heel erg misslaat. Neem meer tijd voor je webshop en bouw het zoals een klant mag verwachten en werk overal waar je melding mails wilt sturen met de zelfde tijds aanduiding. Wat je nu wilt lijkt er in mijn ogen gewoon niet op.
Als ik dan merk eerste keer heb ik 4 dagen om te betalen en de volgende keer ma 1 dag. Dan kan ik je nu al zeggen dat de 2e bestelling gelijk de laatste was.
Want als ik merk dat een webshop niet gelijk matig met de betaal tijden om gaat, dan weet ik genoeg en gooi de link in het vergeet me "heel erg" snel prullebak.
Kortom: Mijn mening is dat je daar de plank gewoon heel erg misslaat. Neem meer tijd voor je webshop en bouw het zoals een klant mag verwachten en werk overal waar je melding mails wilt sturen met de zelfde tijds aanduiding. Wat je nu wilt lijkt er in mijn ogen gewoon niet op.
Door het script elke dag uit te voeren heeft iedereen dus 7 dagen de tijd (vanaf de herinneringsmail) om hun zaken in orde te krijgen.