Editor: Enhance classic editor timestamp fields with native controls (continues #12275)

[j111q]

Summary

Continues the work in #12275 (opened by @poligilad-auto, who is currently out) to enhance the classic editor Publish timestamp with server-rendered native date and time controls, keeping the existing granular aa/mm/jj/hh/mn fields as the source of truth and fallback.

This branch carries Poli's original commit unchanged and adds a follow-up commit addressing @tyxla's code review:

• Removed a duplicated CSS rule. .misc-pub-curtime #timestamp:before { content: none } was declared twice; kept the later declaration so it still overrides .curtime #timestamp:before (equal specificity, so source order decides which wins).
• Consistent invalid-state selectors. The form-invalid class is now added and removed on both native inputs via .timestamp-native-wrap input, rather than being added to only #publish-date-native by ID while being removed from both.
• UTC instead of UTC+0. A zero timezone offset now renders as UTC in the site-time note; non-zero offsets are unchanged (UTC+5:30, etc.).
• Aligned the timestamp row with its siblings. The Publish-box icon column used a fixed 27px, which pushed the timestamp label ~10px further right than the Status / Visibility / Revisions rows. Sizing the column with auto lets it match the sibling dashicon advance, so all rows line up. All new layout CSS remains scoped to .misc-pub-curtime, so the other meta boxes are unaffected.

Trac ticket: https://core.trac.wordpress.org/ticket/61652

Still open from the review

The two higher-level points @tyxla raised on #12275 are not resolved here and still need discussion:

• Confirming this is the design direction the project wants for the classic editor timestamp. @jasmussen - could you take a look?

• Confirming the markup changes don't break plugins that integrate with the existing controls. -- I'll dig into this

Testing

• Opened the classic post editor and confirmed the Publish timestamp renders as native date and time inputs with the site-time note, and that the timestamp row aligns with the other Publish-box rows.
• Confirmed changing the native inputs updates the legacy timestamp fields, and an invalid value keeps the editor open and marks both native inputs invalid.
• php -l src/wp-admin/includes/template.php — no syntax errors.
• Measured the Publish-box row alignment before and after the CSS change (sibling rows and the timestamp row now share the same 16.5px label indent).

The follow-up commit was drafted with AI assistance and reviewed by me.

Props poligilad, tyxla.

[github-actions]

Test using WordPress Playground

The changes in this pull request can previewed and tested using a WordPress Playground instance.

WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser.

Some things to be aware of

• All changes will be lost when closing a tab with a Playground instance.
• All changes will be lost when refreshing the page.
• A fresh instance is created each time the link below is clicked.
• Every time this pull request is updated, a new ZIP file containing all changes is created. If changes are not reflected in the Playground instance,
  it's possible that the most recent build failed, or has not completed. Check the list of workflow runs to be sure.

For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation.

Test this pull request with WordPress Playground.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

Core Committers: Use this line as a base for the props when committing in SVN:

Props poligilad, jillq, joen.

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[jasmussen]

Nice, thanks so muc for contributing! From a quick glance it looks good to me, but honestly I'll also defer a bit to you and Poli on the design side. I understand this is motivated by good reasons, and thus I mostly want to support it with my own thumbs up.

The changeset looks reasonable to me, so I'm wondering: how can we help this ship? Let's see if some developers check in on this with input, otherwise if nothing happens, ping me again and we'll try and see if a @WordPress/wordpress-core ping can help.

[j111q]

Thanks @jasmussen (and for the quick reply)! 🙏

@tyxla -- following up on your point about not breaking plugins that integrate with the existing controls. To investigate this, I was directed by Claude to run the change through WPDirectory (regex across all current plugins + themes on .org)

The results:

Pattern	Plugins	Themes
misc-pub-curtime\s*> (CSS child selectors into the old structure)	0	0
siblings(…a.edit-timestamp (the JS relationship)	~14 plugins	0
edit-timestamp-label|timestamp-native-wrap|timestamp-display (new class names)	1 (unrelated plugin's own class)	0

So the CSS changes look safe, and no themes are affected. The one real compatibility surface is the JS: wrapping the display + Edit link moved a.edit-timestamp out from being a sibling of #timestampdiv, so $('#timestampdiv').siblings('a.edit-timestamp') stops resolving.

Triaging the ~14 hits:

• Classic Editor (9M installs) looks alarming but is a false alarm — it ships a vendored copy of core's post.js under scripts/, but nothing in the plugin enqueues it (the classic editor runs on core's own post.js). So the matched code doesn't execute. (TCD Classic Editor, 4k, vendors it the same way.)
• The genuinely-at-risk set is a handful of status/scheduling plugins that enqueue their own script targeting core's #timestampdiv — e.g. Media Library Assistant (70k, on the attachment screen), PublishPress Statuses (1k), LH Archived Post Status (4k), plus a few with tens of installs. Real, but niche.
• One match (Depublish Posts) is a false positive — it uses its own edit-timestamp-depublish class.

Mitigation which has been pushed: rather than accept even a small break, I kept #timestamp and a.edit-timestamp as direct children of .misc-pub-curtime (so the sibling relationship is preserved) and laid the label row out with a three-column grid instead of the .timestamp-display wrapper (from Poli's original PR).

The rendered result and alignment are unchanged; $('#timestampdiv').siblings('a.edit-timestamp') resolves again. That takes the compatibility question off the table at no visual cost.

Pls LMK if there's something else you think I could do to ensure backward compatibility here! 🙏