Scheduled posts are sent out 2 hours after I scheduled them
Scheduled posts are sent out 2 hours after I scheduled them. How can I fix this?
I set the correct timezone inside Wordpress. And did try to add it inside .htaccess and user.ini file. But it still is wrong. Where is FC getting the timezone from? But the scheduled posts keep sending out 2 hours later than planned.
How can this be fixed?
Need fix ASAP. Thanks.
Do you mean the post appears in the space 2 hours late or the email notifications for the post get sent 2 hours late? Or both?
Thomas OatesΒ Both
Thomas OatesΒ Also with the emails from the Courses they are sent out 2 hours late also
Thomas OatesΒ The scheduled posts emails seem to be not sent out at all sometimes it looks like
Are you using a server CRON or the WordPress built-in CRON? https://github.com/WPManageNinja/fluent-community-docs/blob/master/recommended-server-config.md#server-side-cron
Thomas OatesΒ How can I check this? This website is on a simple envirement
Sam JansenΒ There may be easier/better ways but one way would be to check your wp-config.php file to see if you have the following:
define( 'DISABLE_WP_CRON', true );
If that isn't there or is set to false, that could be your problem. The built-in WordPress CRON isn't at robust as a server side CRON job.
Thomas OatesΒ fluent_community/course/scheduled/send_notification_async
Niet-herhalend β 2025-10-17 06:00:00 +0000
I found this. And my timezone inside Wordpress is set to Amsterdam.
Chatgpt said this:
It seems FluentCommunity schedules course notifications (send_notification_async) in UTC without converting from the WordPress timezone setting. For example, when my site timezone is set to Europe/Amsterdam, a task scheduled for 06:00 runs at 07:00/08:00 local time.
Thomas OatesΒ ChatGPT is giving me this code to fix it, not sure if it works:
add_filter('action_scheduler_before_schedule_single', function($timestamp, $hook, $args, $group) {
// Pas alleen toe op FluentCommunity-taken
if (strpos($hook, 'fluent_community') === 0) {
// Gebruik de site-tijdzone (zoals ingesteld in WP)
$tz = wp_timezone();
// Zet de oorspronkelijke UTC timestamp om naar lokale tijd
$dt_local = new DateTime('@' . $timestamp);
$dt_local->setTimezone($tz);
// Zet vervolgens de lokale tijd weer om naar correcte UTC
// (Action Scheduler verwacht UTC-tijd)
$timestamp = (clone $dt_local)
->setTimezone(new DateTimeZone('UTC'))
->getTimestamp();
}
return $timestamp;
}, 10, 4);
Not sure if that code is necessary. I just did a test on my site for a scheduled post and it posted as expected. I'm in Eastern time zone. This might be a case where getting support involved is needed.
This fixed it:
add_action('admin_init', function() {
if ( ! current_user_can('manage_options') ) return;
if ( isset($_GET['dryrun_fluentcommunity_fix']) || isset($_GET['fix_fluentcommunity_fix']) ) {
if ( ! class_exists('ActionScheduler') ) wp_die('β Action Scheduler not available.');
$do_fix = isset($_GET['fix_fluentcommunity_fix']);
$store = ActionScheduler::store();
$actions = $store->query_actions([
'status' => ActionScheduler_Store::STATUS_PENDING,
'per_page' => 500,
]);
$tz_amsterdam = new DateTimeZone('Europe/Amsterdam');
$count = 0;
$table = "<h2>π§ͺ " . ($do_fix ? "Fixed" : "Dry Run") . " FluentCommunity Summer/Winter Time Corrections</h2>";
$table .= "<table style='border-collapse:collapse;width:100%;border:1px solid #ccc'>";
$table .= "<tr>
<th>Hook</th>
<th>Huidige UTC</th>
<th>Huidige lokale tijd</th>
<th>Nieuwe UTC (Corrected)</th>
<th>Nieuwe lokale tijd</th>
<th>Verschoven (uur)</th>
</tr>";
foreach ( $actions as $action_id ) {
$action = $store->fetch_action($action_id);
$hook = $action->get_hook();
if ( strpos($hook, 'fluent_community') !== false ) {
$scheduled_date = $action->get_schedule()->get_date();
if ( ! $scheduled_date ) continue;
// Huidige lokale tijd
$current_local = clone $scheduled_date;
$current_local->setTimezone($tz_amsterdam);
// Check zomertijd/wintertijd
$is_dst = (bool) $current_local->format('I'); // 1 = zomertijd
$offset_hours = $is_dst ? -2 : -1;
// Nieuwe UTC berekenen
$new_utc = clone $scheduled_date;
$new_utc->modify("{$offset_hours} hour");
// Nieuwe lokale tijd
$new_local = clone $new_utc;
$new_local->setTimezone($tz_amsterdam);
$diff = ($new_utc->getTimestamp() - $scheduled_date->getTimestamp()) / 3600;
$style = abs($diff) > 0 ? "background:#ffe5e5" : "";
$table .= sprintf(
"<tr style='%s'>
<td>%s (ID %d)</td>
<td>%s</td>
<td>%s</td>
<td>%s</td>
<td>%s</td>
<td style='text-align:center;'>%+.1f</td>
</tr>",
$style,
esc_html($hook),
$action_id,
$scheduled_date->format('Y-m-d H:i:s T'),
$current_local->format('Y-m-d H:i:s T'),
$new_utc->format('Y-m-d H:i:s T'),
$new_local->format('Y-m-d H:i:s T'),
$diff
);
if ( $do_fix ) {
// β
Herplan actie correct via ActionScheduler helper
as_unschedule_action($hook, $action->get_args()); // Verwijder oude
as_schedule_single_action(
$new_utc->getTimestamp(),
$hook,
$action->get_args(),
'fluent_community'
);
$count++;
}
}
}
$table .= "</table><p>β
" . ($do_fix ? "Fixed" : "Checked") . " {$count} FluentCommunity actions corrected for summer/winter time.</p>";
wp_die($table);
}
});
It could be that the timezone was not correct when the tasks where planned
I hope future tasks will be correct when I plan them
Sam JansenΒ Weβre using the WordPress timezone, so notifications should be sent according to your siteβs time settings. If youβre not getting the expected result, please create a support ticket with temporary access. Thank you!
https://wpmanageninja.com/support-tickets/
Raiyan MarzanΒ Hello, I believe the timezone was wrong when the posts and course notifications where scheduled. I adjusted it in the Wordpress settings. But the notifications where still scheduled on the wrong time. So to fix it a run a code above to change all the planned notifications. I only don't know 100% if I plan a new notification they are planned on the correct time.
Sam Jansen Just disable and then re-enable the notification. When you enable it again, it will use the current WordPress timezone.
Raiyan MarzanΒ Hello, In my case there where 50 notifications. So that was not so easy. The code did it in bulk. But was not so easy to get the code working.
Sam JansenΒ Good to know that, it's working now