Dragging posts to a different day in Calendar leaves post_date_gmt on the old date

[jerclarke]

Just had to add this to our gv-editflow.php plugin hacks file when my editors and I tracked down some really strange behavior:

/**
 * WEIRD: Fix moving posts to different days on the calendar by "allowing AJAX to set timestamp"
 *
 * Bug: When moving a post on the calendar, the post_date field would update, but not the post_date_gmt, resulting
 * in an invalid DB state where the two don't match and behavior is random: Scheduled posts publish on post_date_gmt
 * but display the time of post_date.
 *
 * Replicate the bug:
 *  - Created a scheduled post for e.g. 5 days in the future
 *  - Look at the database directly to confirm the post has matching post_date and post_date_gmt
 *  - Open the EF calendar and drag the post to a different day
 *  - Refresh the direct database view and see that post_date updated but not post_date_gmt
 *  - Wait for the scheduled post to self-publish, which will happen at post_date_gmt, leaving an inaccurate time display based on post_date (it will be in the future!)
 *
 * For some reason, this hook exists in core EF and disables the updating of post_date_gmt, which causes the problem. I
 * can't explain why it exists and the comments don't really explain it either. Either way, returning true this way fixes it for us.
 */
add_filter( 'ef_calendar_allow_ajax_to_set_timestamp', '__return_true' );

Here's the code from calendar.php:

			// By default, changing a post on the calendar won't set the timestamp.
			// If the user desires that to be the behaviour, they can set the result of this filter to 'true'.
			// With how WordPress works internally, setting 'post_date_gmt' will set the timestamp.
			if ( apply_filters( 'ef_calendar_allow_ajax_to_set_timestamp', false ) ) {
				$new_values['post_date_gmt'] = date( 'Y-m-d', $next_date_full ) . ' ' . $existing_time_gmt;
			}

The comments try to explain it but I can't make sense of it. From what I can tell, that filter being false by default simply breaks the date saving. It seems to work, because most of WP uses post_date, so if you go to edit the post you'll see the same date you moved it to on the calendar, but because the scheduling system seems to use post_date_gmt it exposes that EF has left the two date values on different days.

It seems to me the solution is to simply remove the filter, or at least change the default value, but I can't make sense of why it exists, so I leave it up to the maintainers.

What I know is that on a default site with Twenty Twenty-Five and Edit Flow installed, the default behavior of that filter leaves post_date_gmt in an invalid state.

[GaryJones]

Thanks for the thorough report, @jerclarke — the replication steps and DB screenshots made this easy to confirm. For what it's worth, this behaviour is unchanged since 2011, so it applies to every version.

You're right that the default leaves post_date_gmt in an invalid state for scheduled posts. The history the comments don't quite explain: Edit Flow deliberately keeps post_date_gmt zeroed ("floating") for unpublished posts, so they publish immediately when you eventually hit Publish. Dragging a pitch or draft around the calendar was meant to be a planning action, not scheduling — and since setting post_date_gmt is what tells WordPress "publish at exactly this time", that's why the filter defaults to off.

That reasoning only holds for floating dates, though. The calendar also allows dragging scheduled (future) posts, which already have a concrete post_date_gmt — and for those, leaving it on the old date is exactly the broken state you found: core publishes on post_date_gmt while displaying post_date.

I've fixed this in #1009. Scheduled posts now always have post_date_gmt kept in sync — no filter needed — and the publish_future_post cron event is rescheduled to match. That second part is worth noting for your workaround: the calendar writes directly to the database, so the cron event was never moved, meaning even with __return_true a post dragged to an earlier day wouldn't publish until the originally scheduled moment. Floating-date posts keep their current behaviour, and the filter remains for sites like yours that want drag-to-schedule for those too.

Once this ships in the next release, you can drop the hack for scheduled posts — keep the filter only if you also want dragging unscheduled posts to set their publish timestamp.

[jerclarke]

Once this ships in the next release, you can drop the hack for scheduled posts — keep the filter only if you also want dragging unscheduled posts to set their publish timestamp.

Ok I think I understand this behavior now, maybe it's not very evident, I wonder if our editors had any idea it worked like this with/without the filter. Sounds like both keeping it on and off would be valid choices, but I should at least update my documentation of why the filter is there.

Thanks for fixing the bug and adding tests!