Scheduling emails with cron jobs from a mysql table - php

I am trying to set up a system where a user enters some information in a form and an email will be constructed where the information is saved into mysql.
I am trying to figure out how to make it so the email will be sent, for example, 20 minutes after the user makes their input. (Without the user staying on the browser).
I need this delay as I need the ability for an admin to log on to a page to look at the email and possibly edit it before it sends.
Is this possible through a cron job. Am I able to set one up that automatically checks sql table for an update and then sends the email after a certain time?
Or is it possible to delay a php script with the sleep function and then send the email. Can I make the PHP script still run when user has closed site and left?

you can use mySQL to store the data sent by the user. this data will be accessed later using another script triggered by a cron Job: if you have the ability to set cron jobs in the control panel or via access to the server, go ahead, use cron tab syntax to define when the job will be triggered, this website may help you:
https://crontab-generator.org/
another approach is to use external service to trigger an event every interval, the event could be accessing the cron job script via HTTP.
if you want your email to be sent exactly after 20 mins, please add a field to your mysql table indicating the desired send date(beware of timezones).
you may also want to add a flag indicating if the email is sent, so you do not send the same email twice.

You can't (easily) have a PHP script stay alive that long.
Your best strategy, IMO, would be to have the PHP script create the email file, and notify the human.
Then you can have PHP run a shell script which uses the "at" program to schedule a task to happen in 20 minutes. At is a cousin of cron, but is better suited for this job.
That scheduled task will be to take the e-mail message, move it some place else (like a "done" directory), and pipe it through your mailer. tip: /usr/sbin/sendmail -t < myEmailFile will work on most Linux boxen.

Related

PHP script in background without user waiting

I have a webform that sends data to PHP script.
PHP script may take a while to process the data. What I want to do is to send raw data to database, then redirect the visitor to "thank you" page and then continue processing the data in background. Important thing is that the script must continue working even if the visitor closes "thank you" page.
Can you advise which solution should I look into?
P.S. I use nginx + php-fpm if that matters.
UPDATE. I've found info about using ignore_user_abort(true). Could this be the way to go?
What I want to do is to send raw data to database, then redirect the visitor to "thank you" page and then continue processing the data in background.
That basically describes how I'd do it right there, actually.
Consider two separate applications. One is the web application, which saves the user input to the database and then continues to interact with the user. The other is a scheduled console application (a standalone script invoked by cron most likely) which looks for data in the database to be processed and processes it.
The user uploads the data, receives a "thank you" message, and his/her interaction is complete. The next time the scheduled task runs (every couple minutes, maybe?) it sees the pending data in the database, flags it as being processed (so if another instance of the script runs it doesn't also try to process the same data), processes it, flags it as being done (so it doesn't pick it up again next time), and completes.
You can notify the user of the completed process a couple of different ways. The back-end script can send the user an email (active notification), or perhaps the web application can examine the table for the flagged completed records the next time the user visits the page (passive notification).
Something like this should work :
pclose(popen('php script.php &', 'r'));
http://fr2.php.net/manual/fr/function.popen.php
You can also use more options or others functions to get more control over the execution :
http://fr2.php.net/manual/fr/function.proc-open.php
But use this carefully and be sure you need this way to resolve your problem.
Ajax would be nice.
You need to do the thing asynchronously. Use AJAX to achieve this

Run php file without wait for results

Let me try to explain to you what i need:
the user creates a post on the site and choose which users can have access to this post. When the user submits the information, each person chosen to have access to post receives an email warning.
To perform this I use ajax through jquery. The problem is that this process may be too long until all the emails have been sent.
So I thought the process would work as follows:
1rst - Save the post;
2snd - Save the information of emails (subject, recipient, etc.) in a database table;
3th - run a php file in "parallel" to fetch the information of emails and send them - with the goal of not having to wait for it to execute.
Is the third step possible?
I hope i explain me well :)
Thank you all.
If you have access to the server crontab, simply setup a new crontab to run every minute and execute the mail sending.
This way it's not related to your workflow, so you can store the emails somehow in files or database, etc.etc., and send out later from a different script.
crontab -e -u (webserver user)

Making Email Delivery delay

This is some type of funny question to ask here.
Well, I am using WordPress with registration. When a user signup. Wordpress send email containing user name and password to login.
I simply want that email to receive after delay of 10 minutes. Is there is something to do with server config OR with WP.
Any clues?
You would have to have multiple things to have it work, you will need to have access to cron in order to delay the job and you need to be able have enough knowledge to edit WordPress to stop the function from sending the email. If you can schedule the job to run a command with the parameters for the email in it 10 minutes later the rest should run on its own.

Delete user from database if email not confirmed

I am currently working on a registration based website, and I have the server sending an activation email to the user upon registration. This is all done in PHP so, as you can imagine, I am using the mail() function.
This is all fine and dandy, once the user gets the email and clicks the activation link, the 'active' field that is in the 'Users' table is set to true. Here's the problem though, in the case that a user does not confirm their email address, what am I to do?
I have thought of holding details like the date and time the user registers but I don't know how to proceed with this data. How do I have the server automatically delete the user from the database after a set amount of time?
That's what I think I should be asking, but in all honesty I don't know the usual protocol...
Conclusion: Since Cron is for Unix based servers I've had to pass on it, but I found it very interesting that I could just use the Windows Task Scheduler that is built into Windows. This at least means I can test it on my PC before any server hosting. Thank you all
You should definitely store the date and time that the activation link was sent.
There isn't really a way to tell the server to automatically delete stale user data, but it's easy enough to code up yourself. Assuming you have access to cron on your server, you can set up a cronjob to run (for example) every night at 2am and execute a PHP script that searches the database for users who were sent a link more than X days ago but never confirmed it
i think the solution would be Storing the timestamp while sending the mail.
now run a cron every 15minutes which would check that which values are having timestamp more than 24hrs or any timelimit you want and then delete it from db
Just call in your index.php file the following code. (Why index.php ? - because it is requested every time and can "act" as a cronjob.)
(Just Pseudo Code - might need some tweaks!)
mysql_query("DELETE FROM user WHERE active = 'false' AND registerTime < (NOW-60*60*24*7)")
This will delete all Users which have not been activated within 7 Days.
It's just a concept idea i think you can build on.
You should look into cronjobs that you run daily. Simply put in a field in your database with the time your user registered.

How can I send a daily email notification to users in PHP?

I have a simple user signup form with a checkbox that lets users get a daily email notification if there was activity on any of their projects...much like Stack Overflow has a "Notify xxx#example.com daily of any new answers".
My current thinking to implement this in a LAMP environment is as follows:
In the user database, set a boolean value if the user wishes to receive a daily email.
If there is any project activity, the project gets updated with the current timestamp.
Each night (midnight), a PHP file is executed (likely through a cron job) that scans through the project database to identify which projects had activity that day. For projects with activity, the project owner name is selected and the user table is scanned to check if the user wishes to receive a daily email notification. If yes, add to a recipient list; else, ignore.
Questions / concerns I have that would appreciate some guidance on before I start to implement:
I'm in a shared hosting environment. What precautions do I need to take from being misidentified as spam either by the hosting company or the receiving mail servers?
Do I need to "chunk" out the recipient list (50 emails at a time) and email each group? Is this as simple as putting a sleep(30); between each call to mail()?
I'm using the CodeIgniter framework and will have the cron job call the appropriate function in a controller to run this at midnight. How do I limit calls from only the cron job to prevent some unauthorized user from calling this function from the browser?
Thanks.
If you do change the "From" header in php, make sure you change it to the domain that's hosted on that server. It looks suspicious when mail #a.com is being sent by b.com's servers.
I would send the emails individually foreach ($Users as $User)..., since this allows you to personalize the email contents. Even if you don't need to personalize emails now, you might want to later, and the support for it will already be there when you need it.
First, I would store the script outside of the web root. I'm not sure if CodeIgniter will let you do this, but there is no need for the script to ever be served by Apache. Cron doesn't care where the script is stored. Additionally, I've checked the time when the script is executed. If it's not midnight, then don't blast out the emails. Also, you could keep a log around and also check to make sure the emails haven't already been sent that day before sending.
1) Start with an SPF record and a DKIM if you can that lets mail servers know to expect email from your servers
2) First, you need to put the recipients in the BCC field so that it not each user has the email addresses of 49 other users on your system. One step further is to do each email separately, putting only the recipient in the TO field. This approach also allows your to tailor each email to the user (perhaps putting in "Hi [First name]".
3) Have the cron job something like this
wget http://localhost/send-emails
Then in your script, check $_SERVER and make sure you only allow requests from 127.0.0.1
About the third question: You can either use an .htaccess file to prevent access to that specific page or you can call your script in cron with a command line parameter and check for that variable in $argv.
1) The SPF record is the most important thing. Use the email from the domain so whatever#whatever.com, where whatever.com has the SPF records set correctly.
2) It's always good to throttle email, especially when first starting out. You should check your shared servers policies, which are normally 200-500/hour. Calculate how many seconds that comes to. For example 300/hour is 1 every 12 seconds. After a few weeks of sending good emails, you should be ok to send larger amounts.
3) You can have the cron file outside the webroot or limit access via .htaccess or another method.

Categories