Keep post_date_gmt in sync when dragging posts on the calendar - #1009
Merged
Conversation
Dragging a post to a different day only updated post_date, leaving a scheduled post's post_date_gmt on the old date. Core publishes on post_date_gmt, so the post went live at the old time while displaying the new date. The direct database update also bypasses _future_post_hook(), so the publish cron event still fired at the old time regardless of direction. The ef_calendar_allow_ajax_to_set_timestamp filter (default false) was added in 2011 so that moving a floating-date post on the calendar stays a planning action rather than scheduling it. That remains the behaviour for floating dates, but a post with a concrete publish timestamp now always has it kept in sync — a mismatched pair is never a valid state — and its publish cron event is rescheduled to match. The new GMT value is derived with get_gmt_from_date() rather than reusing the old GMT time-of-day, which mishandled posts whose local and GMT dates fall on different days and DST changes between the two dates. Fixes #1008
When the ef_calendar_allow_ajax_to_set_timestamp filter is enabled, quick-created posts had post_date_gmt set to the site-local time verbatim, so the stored timestamp was wrong by the site's UTC offset. Derive it with get_gmt_from_date() instead, matching how the drag-and-drop handler now sets it.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #1008
Dragging a post to a different day on the calendar only updated
post_date, leavingpost_date_gmtbehind on the old date. For scheduled posts that pairing is never valid: core publishes onpost_date_gmt, so the post went live at the old time while displaying the new date. Because the handler writes via a direct database update (the long-standing core #18362 workaround),_future_post_hook()never fired either, so thepublish_future_postcron event kept its old time regardless of which direction the post was moved.The
ef_calendar_allow_ajax_to_set_timestampfilter (default false) dates from 2011 and exists so that moving a floating-date post (pitch, draft) on the calendar stays a planning action — the post still publishes "now" when it's eventually published. That behaviour is preserved. What changes is that a post which already has a concrete publish timestamp now always has it kept in sync with the new date, and its publish cron event is rescheduled to match, so a scheduled post moved earlier or later actually publishes when the calendar says it will.The new GMT value is derived with
get_gmt_from_date()rather than reusing the old GMT time-of-day, which mishandled posts whose local and GMT dates fall on different days, and DST changes between the old and new dates. The opt-in path in quick-create gets the same treatment, as it previously stored site-local time as GMT verbatim.Integration tests cover the scheduled-post sync and cron rescheduling, the moved-to-the-past case, and both floating-date behaviours (default, and opted in via the filter), running under a non-UTC site timezone so the GMT conversion is genuinely exercised.