Feature request: On This Day dashboard widget

[alshakero]

When an author lands on their Dashboard, the widget would show posts they published on the same month and day in previous years, grouped by year with the most recent first. Each entry links to the post for quick edit or view. This is especially cool for drafts and unfinished posts.

This gives long-time authors a gentle nudge to revisit old work, spot patterns in what they write about on certain days, or republish/refresh content that has aged well. For new authors or on days with no history, the widget shows a friendly empty state.

This would hopefully delight users and encourage them to comment on their post pasts with new posts.

## 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

#### Different color scheme

#### RTL

### Testing

• Open this PR via the Playground: ​https://playground.wordpress.net/wordpress.html?pr=11630
• Go to Dashboard to see the empty state.
• Import this file to create backdated posts: filexml](​https://github.com/user-attachments/files/26987112/wordpressdevelop.WordPress.2026-04-22.3.xml)
• If the import process times out, don't refresh the page. Click the simulated URL bar of the playground and click Homepage. The import will have succeeded nonetheless.
• 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() (mirroring the Site Health loader) so it has no cost on non-dashboard admin screens.
• tools/seed-otd-posts.php is a dev convenience, not autoloaded; feedback welcome on whether it belongs in /tools or should be dropped from the commit entirely.

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.

[eclev91]

This is fun, but does it belong in core?

I haven't seen the admin reskin, but presumably that's where some of these shadows and gradients comes from?

[annezazu]

This came up in a core committer meeting in November 2025: ​https://make.wordpress.org/core/2025/11/26/core-committers-check-in-november-2025/

Are there new widgets that can be added, such as “on this day” or “new/unresolved notes” for sites making use of the Notes feature.

It also came up in the 7.0 Product review with Matt: ​https://make.wordpress.org/core/2026/02/18/wordpress-7-0-product-review-meeting-with-matt/

“On this day / previous years” widget discussed as a simple, useful candidate to bring in.

Here's the exact timestamp for the conversation if you want to listen @eclev91 ​https://youtu.be/F-xMPY9WqG4?si=Cci4dbtu08rT0lly&t=3326

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

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.

Tested locally and it loads just fine!

[eclev91]

I just don't think "how cool would it be" (Matt's words regarding changes to the dashboard) is a good criteria for what should go into core.

"There was a lot of excitement...it didn't get picked up."

So not that much excitement.

Matt goes on to talk about the low complexity of doing it, which is certainly true. But many things are easy without being worthy of doing.

Maybe I'm missing context. The core committer minutes simply say "Are there new widgets that can be added..." with a couple of examples, which says to me "We think the dashboard could be more useful. There should be discussion around what makes it not useful. What would make it more useful?" The minutes don't suggest that conversation happened, but Matt, in the video meeting, mentions people "making the dashboard their own", which is an actionable goal and maybe even an important one.

But this widget creates an additional query on the dashboard and loads yet another stylesheet, which is far from the experience I want on the dashboard if I'm making it my own. If you disable the widget with Screen Options, it just hides it with CSS. It doesn't remove the box and improve performance related to its inclusion. It's relevant to one subset of users and contributing to a noise problem for the rest. Does its default inclusion help people "make the dashboard their own", or does this serve only a subset of users rather than create a user experience pattern that actually serves the stated goal?

I'm far from well plugged into core development, and the code is already written, but can this at least be something you opt into rather than have to disable on sites where it's irrelevant?

Redesigned following ​this.

[annezazu]

I just don't think "how cool would it be" (Matt's words regarding changes to the dashboard) is a good criteria for what should go into core.

Matt asked what happened to it and wanted to see it in Core. @matt if you would like to chime in. I will let what's there speak for itself for now.

In the same way default dashboard widgets, like site health status, can be controlled by screen options, this can also be something that can be turned on/off.

The redesign looks great! Thank you.

[westonruter]

Replying to annezazu:

In the same way default dashboard widgets, like site health status, can be controlled by screen options, this can also be something that can be turned on/off.

Regarding the query performance concern, it seems the issue is that the screen options checkboxes just hide/show the dashboard widget. Ideally unchecking a screen options checkbox would omit the widget from being rendered in the first place. This would require a page reload to see the changes.

That said, I don't think the additional query would be so expensive so I don't think that should be a blocker for adding this. The widgets could also be removed programmatically which would prevent them from being rendered or appearing in the screen options checkboxes for sites that are particularly concerned about this. But for scaling up the dashboard to have many more widgets, we should keep an eye on how we can do so performantly.

[alshakero]

Replying to eclev91:

Hi there!

So not that much excitement.

Well it is picked up now 😄 FWIW, I genuinely think it is cool and useful and I proposed it without knowing about the past discussions about it.

But this widget creates an additional query on the dashboard and loads yet another stylesheet, which is far from the experience I want on the dashboard if I'm making it my own.

I hear you and I really want wp-admin to be fast. That's why the widget does one query per day unless you modify your posts. It's heavily cached; even the HTML generation is cached for the duration of the day. When it's cached, it doesn't do any DB connections at all.

The CSS is 1.9 KB gzipped and is cached across days. I don't think it will move the needle at all.

It's relevant to one subset of users and contributing to a noise problem for the rest.

For those who don't want it, I think the only noise is the checkbox in the screen options. Is that a lot? This plugin will also only register for those who can edit posts.

Can this at least be something you opt into rather than have to disable on sites where it's irrelevant?

I'm totally open to both options. I did try to make it opt-in and it seems the architecture doesn't support that by default and I would have to do some trickery, still open to it nonetheless.

Thanks for the amazing feedback!

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.

<time datetime="…"> needs a timezone

Fixed.

@dmsnell thank you so much for the review. Addressed all feedback.

Just noting that there might be a problem with the minimize button

I'll try to see what's wrong 👍

Hi @dmsnell! Anything more I can do on this?

@alshakero I think my review is done here; it might be good to bring this up tomorrow in the ​Weekly Developer Chat where more people can see it, comment, or help move it forward.

I’m not sure if I am in a position to merge it, but I’ll follow along and do what I can to help it get in.

@dmsnell I implemented the list of inline tags and added some tests.

Hi Aaron! I much appreciate your review. Thank you.

It's a bit jarring to jump to the top of the page when adjusting the slider.

Yes, I didn't want to add any JS to make this dynamic because it's performance-sensitive. I now added the element's ID in the URL hash to scroll back down to it when it's updated. Much nicer now.

What I'm seeing in the output seems to not be what is intended, so I haven't reviewed that at all:

I'm unable to reproduce this which makes it interesting. Maybe you have some special HTML in your posts that is breaking my escaping. If this is a testing site, would you mind sharing an export?

It feels like a lot of the functionality for excerpts isn't using core functionality. If core needs to work around core limitations, that is a good opportunity to make enhacements so they are available elsewhere.

I think Core has great tooling around excerpts. But we went a bit extreme with this one to optimize performance. You can see our discussion ​here.

Update: I managed to reproduce ​this. The minifier is mangling the CSS file because it doesn't support native CSS nesting. Even though ​it is supported everywhere now.

I fixed that now.

@alshakero Love this!

I have some thoughts and suggestions for the design of this. What if we pare it back a bit and ship a very clean, opinionated widget? Then, add more as people use it and you get feedback on the feature. I think its easier to add than to take away.

Suggested changes:

• Only show published posts. Remove drafts.

• Make Reblog the primary action. Secondary action is to view the post. Tertiary action is to Share, which would copy a link to the clipboard. I think we should encourage blogs and blogging with this!
• Most people will likely only have one blog post for any given day, if they even have any. Optimize the design for that.

Get rid of the slider at the bottom of the post and have the 7 day range be the default. This is what other competitors do as well.

• If there are multiple, still show only one at a time, but introduce a way to flip through each post.
• If there is a, a featured image, or gallery in the post, include the first image in the widget. People love photos and are more likely to engage with the widget.
• I'd further clean up the UI by only showing the date, title, excerpt or first few lines of the photo. Remove the rest of the post meta. Put the post date closer to the 'x years ago' ui.

Screenshots of suggested updates:

If only one post:

If multiple posts, no photo:

Still some UI details to work out, but what do you think? If you want to take it for a spin, I have a branch here: ​https://github.com/kellychoffman/wordpress-develop/tree/kelly/otd-carousel-alt

Hi @kellychoffman! Thank you so much, this is great. In retrospect, it's obvious that it won't be common to have multiple posts on a given day. I adopted your design.

The only missing thing is that I didn't add a reblog button. That is not supported by default and I would have to add some filters to post-new.php. It's a couple of lines but felt really out of scope.

I also added a native share button instead of just copying. There is a ​Web Share API now and it's perfect for this case. It takes care of copying too. I did failover to copying for older browsers and Firefox.

@kellychoffman @alshakero, have you also looked at designs proposed at ​https://github.com/WordPress/gutenberg/issues/74936 ?

There are some neat visual ideas

Thank you for the ping! Given the core context here, and that we've already on that other issue received some questions around what's plugin territory vs. core, that's a good nuance to unstick here as well.

Which is to say, it feels to me very appropriate to have an "On this day" widget, especially since it is being paired with a larger dashboard refresh that I know @retrofox has been looking into. But we probably shouldn't have two different ones. I happen to like quite a lot what @jarekmorawski did with the , though I wonder if there's a way to merge these two efforts? The prompt for an empty period feels like a nice addition.

The "reblog" button is an open question for extensibility, though, it'd be nice if plugins could tap into this widget.

Yes, I think we can join efforts here. Also, extensibility is a nice one.

Let's suppose you have a historical events plugin in which the data source isn't simply a post. We should allow consumers to extend the events of this day.

[audrasjb]

Removing trunk version as this is not going to be shipped with WP 7.0 but in the next releases.

[desrosj]

Since this is an enhancement, there's no first version of WordPress this can be reproduced in. Removing trunk version.

Hi @kellychoffman @jarekmorawski! It would be wonderful if we could reach an agreement on this, the momentum is great (for now).

I took inspiration from the empty state from Jarek's work, it's much better than the version that I had.