incorrect "Next campaigns to process" times vs. gmt_offset (fixed)
I’ve been using WP-o-matic for a while and first of all I think it’s a great plugin. So thanks to all who made this possible.
Unfortunately, I experienced a problem with GMT offset like many others did. Other topics showed suggested solutions like “turn off GMT offset in Settings”. This sounds more like a workaround. Maybe the right answer has been going around here, but I couldn’t find it.
The problem I have is that the time remaining to fetch the campaigns is added with the GMT offset. In my opinion, the GMT offset doesn’t have to do anything with remaining time to fetch. Because 1 hour in Europe still remains 1 hour in Australia.
So when I change the GMT offset to Australia, all my campaigns are changed with a remaining time to fetch of 9 a 10 hours. I made some little changes in the next file:
The getCampaignRemaining function should be adjusted a little bit.
return mysql2date('U', $campaign->lastactive) + $campaign->frequency - current_time('timestamp', true) + ($gmt ? 0 : (get_option('gmt_offset') * 3600));
return mysql2date('U', $campaign->lastactive) + $campaign->frequency - current_time('timestamp', true);
But that only manipulates the remaining time shown in the interface. Not the time the cron job relies on. So we also need to change the getCampaign query in the same file:
$where .= " AND active = 1 AND (frequency + UNIX_TIMESTAMP(lastactive)) < ". (current_time('timestamp', true) - get_option('gmt_offset') * 3600) . " ";
$where .= " AND active = 1 AND (frequency + UNIX_TIMESTAMP(lastactive)) < ". (current_time('timestamp', true)) . " ";
For me this works, but the reason I posted this is because I’m curious if this is the right solution for the problem. This could also help other users experiencing the same problem and of course I want avoid to get customized plugin files (in case of WP-o-matic updates).
- The topic ‘incorrect "Next campaigns to process" times vs. gmt_offset (fixed)’ is closed to new replies.