Turns out that the issue within the code was neither the WP CRON nor was it the function that performs a WP_Query and SQL query of a custom DB table. As standalone functions, they both worked perfectly.
The problem actually ended up being that I specified a timezone in the WP CRON using date_default_timezone_set( 'America/Los_Angeles' );.
I had added that because, once testing was finished, rather than running the WP CRON every 5 minutes the plan was to run it once daily at 9:00am PST because that’s where the client is physically located and where their staff all work.
I tend to save dates/times in the DB as Universal Time Codes because I find it’s a lot easier to run comparisons and not have to worry about how different utilities are formatting dates, etc. Anywhere I can, I convert dates using strtotime() before recording them.
So, all of the custom dates in the DB are stored using UTC in the GMT time zone. (Keeping it simple.)
However, in the CRON scheduler, when I specified PST as the time zone and THEN executed the second function to query the DB and send emails, what I was encountering was mis-matched ‘dates’ because the timezone shift generated different time codes, that were 8 hours behind.
$rems_prepare = $wpdb->prepare(
"SELECT * FROM {$custom_table} WHERE `sdate ` = %d AND `posid` IN (%d)",
$tomorrow, $remindlist
);
So where I’m checking if sdate is equal to $tomorrow, the timezone change I initiated in the CRON meant that I never found any matching results. Super obvious.
So the solution was actually quite simple and there were two of them… …I could either schedule the CRON using UTC/GMT to whatever the equivalent of 9:00am PST is (17:00:00 GMT) or I could just jump back into the UTC/GMT timezone at the start of the querying/emailing function like this:
function custom_reminders_cron_task() {
date_default_timezone_set( 'UTC' );
$today = date( 'Y-m-d' );
$tomorrow = strtotime( date( 'Y-m-d', strtotime( $today . ' +1 day' ) ) );
//run the rest of the code...
I have no idea if this will be of any use to anyone else because it’s a pretty specific issue of my own making. I only managed to find it because I started the process of converting the whole thing to an AJAX function and then, once again switching the time zone, I realized that my SQL query wasn’t returning any results and caught why pretty quickly when I was comparing the query parameters against what’s in the DB.
I had it temporarily set for 9:00am EST this morning and when I checked my inbox this morning the emails were there.