Skip to content

Show "Immediately" for custom status posts in block editor#938

Merged
GaryJones merged 2 commits intodevelopfrom
GaryJones/review-issue-925
Apr 23, 2026
Merged

Show "Immediately" for custom status posts in block editor#938
GaryJones merged 2 commits intodevelopfrom
GaryJones/review-issue-925

Conversation

@GaryJones
Copy link
Copy Markdown
Contributor

@GaryJones GaryJones commented Apr 23, 2026

Summary

Closes #925.

When a post sits in an Edit Flow custom status (Pitch, Assigned, In Progress, and so on), the block editor's Publish field displays a concrete date like "Today at 2:44 pm" rather than "Immediately". Without Edit Flow active, the same underlying post correctly shows "Immediately" — so this is a regression introduced by the REST API round-trip, not the database layer.

The root cause lives in WP core. WP_REST_Posts_Controller::prepare_item_for_response() only returns null for date_gmt when a post's status is draft or pending. Any other status — including every Edit Flow custom status — falls through to the branch that converts 0000-00-00 00:00:00 into a concrete ISO 8601 date derived from post_date. The block editor reads that value, interprets it literally, and renders the confusing concrete date.

The existing fix_custom_status_timestamp() already preserves 0000-00-00 00:00:00 in the database on save, and update_post_date_on_publish_from_custom_status() handles the publish transition correctly, so posts do publish at the right time. The bug is purely cosmetic — but it still undermines editorial trust in what the Publish field is telling them.

The fix adds a rest_prepare_{post_type} filter, registered for every post type that supports custom statuses, which restores parity with core's draft/pending handling. When the post is in a custom status and post_date_gmt is unset, the response's date_gmt is nulled so Gutenberg's PostScheduleLabel falls back to "Immediately". Posts with an explicitly scheduled GMT date are left alone, and draft/pending posts continue to flow through core's own logic untouched.

A new integration test file (CustomStatusRestApiDateTest) covers the happy path plus the obvious regression traps: published posts keeping their concrete date, draft posts still getting null from core, scheduled pitches preserving their explicit GMT date, and pending posts remaining unaffected.

Test plan

  • CI: integration tests and PHP lint pass on the branch
  • Manual: on a fresh WP install with Edit Flow active, create a post and save it with the default "Pitch" status; confirm the block editor sidebar shows "Immediately" rather than a concrete date
  • Manual: schedule a post in a custom status with an explicit future GMT date; confirm that scheduled date is still shown
  • Manual: confirm published posts continue to show their publish date in the sidebar
  • Manual: deactivate Edit Flow and reload the same post; behaviour matches core (unchanged)

WP core's REST controller only nulls date_gmt for 'draft' and 'pending',
so posts in Edit Flow custom statuses were serialised with a concrete ISO
date derived from post_date. The block editor then displayed that date in
the Publish field instead of "Immediately", confusing editorial users who
expect the same behaviour as a draft.

Add a rest_prepare_{post_type} filter, registered for each post type that
supports custom statuses, that restores parity with core's draft/pending
handling when post_date_gmt is '0000-00-00 00:00:00'.

Fixes #925
@GaryJones GaryJones requested a review from a team as a code owner April 23, 2026 15:00
Nulling date_gmt alone proved insufficient in practice. Gutenberg's
isEditedPostDateFloating selector hardcodes the status whitelist to
'draft', 'auto-draft', and 'pending', so for any custom Edit Flow
status it short-circuits to false and the Publish field renders the
concrete date rather than "Immediately".

Nulling date in addition pushes Gutenberg's label renderer into its
"Immediately" branch (triggered when date itself is null), which
avoids modifying core behaviour or shipping a JS workaround. The
database post_date is unaffected because Gutenberg only sends changed
fields on save, so a nulled date in the response does not propagate
back unless the user actively edits the schedule.
@GaryJones GaryJones self-assigned this Apr 23, 2026
@GaryJones GaryJones merged commit e4375d0 into develop Apr 23, 2026
12 of 14 checks passed
@GaryJones GaryJones deleted the GaryJones/review-issue-925 branch April 23, 2026 22:27
@GaryJones GaryJones added this to the Next milestone Apr 23, 2026
@GaryJones GaryJones mentioned this pull request Apr 24, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Custom statuses: block editor shows concrete date instead of 'Immediately' due to REST API date_gmt serialization

1 participant