Proposal: Add On This Day Widget

[alshakero]

Summary

Adds a new On This Day dashboard widget to WordPress core that surfaces the current user's posts published on today's month and day in previous years, so returning authors see a friendly nudge of what they wrote one, five, or ten years ago.

The widget is implemented as a first-class core feature, following the same pattern as Site Health.

User-facing behavior

• Widget title reads On This Day · <Month Day> and appears in the dashboard grid for users with edit_posts.
• Each year is shown with a year badge (e.g. 2023 · 3 yrs) and the posts published that day as cards with excerpt, time, categories, and Edit/View links.
• Draft and private posts are included for the author and visually distinguished; public posts link to the edit screen with a View link to the permalink.
• Empty state messaging encourages the author when today has no historical posts.

Screenshots

Testing

• Checkout this PR locally and run npm run env:start, then npm run env:install.
• Go to Dashboard (admin:password), you should see the widget.
• Insepect its empty state.
• Import this file to create backdated posts: filexml
• Use the widget.

Notes for reviewers

• The WP_Query call intentionally uses a posts_where filter scoped to a single query to match MM-DD in an index-friendly way rather than inflating meta_query/date_query.
• The class is loaded lazily inside wp_dashboard_setup() (basically copied the Site Health loader) so it has no cost on non-dashboard admin screens.

Trac ticket: https://core.trac.wordpress.org/ticket/65116#ticket

Use of AI Tools

AI assistance: Yes
Tool(s): Cursor
Model(s): Claude Opus 4.7
Used for: The code is 100% written with AI, but I guided it every step of the way and reviewed every line.

---

This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.

[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.

Unlinked Accounts

The following contributors have not linked their GitHub and WordPress.org accounts: @escapemanuele.

Contributors, please read how to link your accounts to ensure your work is properly credited in WordPress releases.

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

Props alshakero, jeherve, apermo.

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

[escapemanuele]

Nice, nice! I must have some CSS issue here as I do not see the dates on the left.

[alshakero]

Nice, nice! I must have some CSS issue here as I do not see the dates on the left.

It looks like the Playground is running an outdated build. I rebased to rebuilt. Hopefully that will fix it.

Edit: It's a playground issue, I updated the testing steps.

[escapemanuele]

Tested locally and it loads just fine!

[alshakero]

Redesigned following this.

[jeherve]

I've been poking at the query logic and comparing against my own little plugin. I thought I'd mention a few patterns I picked up from feedback from users.

Use date_query instead of raw SQL

Right now filter_posts_where() uses a posts_where filter with hand-rolled MONTH()/DAY()/YEAR() comparisons. It works, but WP_Query already supports this natively through date_query; it handles the escaping, uses the documented API surface, and is friendlier to anyone who later wants to extend the behavior. class-query.php from the plugin is a reasonable reference.

Consider widening the window beyond the exact day

Of note, most "memory" products — Google Photos, Apple's On This Day, Facebook Memories — don't restrict to the exact calendar day; they widen the window to nearby dates so something shows up even on slow days. The plugin started the same way this PR does, and I eventually moved to a week-long window by default, with exact-day matching as an opt-in.

A couple of reasons this matters:

• Feb 29. With exact matching, leap-day posts only surface once every four years, and on Feb 29 in a non-leap year… well, that day doesn't exist, so the widget is awkwardly blank.
• Sparse posters. Someone who publishes weekly but not daily will see the empty state on most days of the year; a small window (±3 days?) turns that into a useful recap instead.

I'm wondering if we could default to a modest window and leave exact-match behind a filter for folks who really want it. Closer to how the genre works in the wild.

<time datetime="…"> needs a timezone

Small thing on the post meta row:

$time_iso = get_the_time( 'Y-m-d H:i', $post );
// ...
<time datetime="<?php echo esc_attr( $time_iso ); ?>">

get_the_time() returns the post time in the site's timezone, but the emitted string has no offset or Z. Per the HTML spec that's a "local date and time" without context, so screen readers and timezone-aware tooling interpret it as the user's local time rather than the site's. Either drop to Y-m-d (a plain date is a valid datetime value), or switch to get_the_time( 'c', $post ), which gives you ISO 8601 with an offset attached.

[apermo]

Why is allow dynamic properties needed? As it is new code, I would refrain from adding this.

[alshakero]

Great point. I was undecided about this attribute tbqh. But I was mimicking Site Health and decided to keep it for consistency. But it's not needed for my class.

I removed it.

[alshakero]

Thanks for the amazing feedback, @jeherve!

Use date_query instead of raw SQL

Done.

Consider widening the window beyond the exact day

I added a minimal slider to keep the noise down the allows adjusting the range from 1 to 7 days.

needs a timezone

Fixed.