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.

Thank you so much @peterwilsoncc! I addressed all your feedback.

Quick thoughts:

• Can we not show anything if there's nothing on this day in the past?
• I have used this plugin for a while and prefer it as a starting point to the above: ​https://wordpress.org/plugins/years-ago-today/

Can we not show anything if there's nothing on this day in the past?

It might be tricky to show nothing at all. Because the widgets are customizable by the user and dynamically hiding them may mess up the ordering. This is what Years Ago Today shows.

I have used this plugin for a while and prefer it as a starting point to the above: ​wordpress.org/plugins/years-ago-today

Happy to adopt that, the UI is simpler and more performant (no carousel CSS and JS). But I'm curious which part would you like me to bring over?

• The window size? Keep it to a day instead of a week?
• The UI design?

Can we not show anything if there's nothing on this day in the past?

A new, separate widget would not be very valuable on a site with zero published posts, and it would be inappropriate for sites that _never_ have any published posts.

The existing Activity widget has a 'No activity yet!' fallback when there are no future or published posts and no recent comments. I think the Published On This Day list could fit inside that widget, possibly with the same styling and similar links. A made a quick ​proof of concept on my fork.

@m

Can we not show anything if there's nothing on this day in the past?

Yes. Apparently the grid reflows nicely when an item is removed. We now don’t render anything for empty days.

I have used this plugin for a while and prefer it as a starting point to the above: ​years-ago-today

Yes, I took a lot of inspiration from that widget. Here’s how it’s looking now:

I have two questions:

1. This plugin sends daily emails too, do we want that too?
2. The plugin adds a Gutenberg block

@peterwilsoncc thank you so much for your generous feedback. I addressed all the parts that apply to

Let's merge it!

[joedolson]

I'm going to accept this to review and merge if I think it's ready. I have a few things based on what I'm seeing that I want to raise, though nothing blocking; just places I think it could be improved.

@alshakero, Do you have the bandwidth to address the feedback? If not, someone else can help with the task 🙂

Hi @t-hamano! I'm on this now. I was on a short holiday.

Thank you for the feedback. I admit, this is much neater now. Summary of the changes.

@peterwilsoncc's review:

• Removed the custom caching layer (cache constants, salted markup/posts cache, get_cached_posts()) in favor of WP_Query's native post-queries caching.
• Made the widget available to all users by removing the current_user_can( 'edit_posts' ) check in dashboard.php
• Fixed author attribution edge cases — the "by X" span is skipped when post_author is 0 or the display name is empty
• Restructured the leap-day logic in the date query clause to put the special case inside an if instead of an early return
• Moved escaping of the author next to the echoing.

@t-hamano's review:

• Converted the class-based implementation to plain functions matching other dashboard widgets (wp_dashboard_on_this_day() etc.), kept in a separate file, with internal helpers made private via underscore prefix and @access private
• Capped the post list at 10 (was unlimited), still adjustable via the query-args filter; added a test for the cap
• Deleted the dedicated on-this-day.css file and its script-loader registrations, folding the styles into dashboard.css
• Fixed the date pill accessibility by rendering the date as a real <span> in the title instead of CSS content: attr()
• CSS cleanups: removed one-use custom properties, trimmed the year-heading rule to font-weight: 600, simplified selectors to element-based where unambiguous, and replaced vertical-align with flexbox.

@joedolson's comments:

• Changed the phrasing to the cleaner "N posts has been published on this day", without "previous years".
• Moved the date pill into its own span. My mistake was testing two elements which broke the layout when I tried it. With nesting it works great.

@t-hamano addressed all.

@alshakero Thanks for the update. I have no further feedback from my end, but we might need to address the following outstanding points.

---

Disable the meta cache for the query: ​https://github.com/WordPress/wordpress-develop/pull/11630#discussion_r3547847240
@peterwilsoncc

---

If the widget itself is not registered due to an early return, the dashboard's sort order will be reset: ​https://github.com/WordPress/wordpress-develop/pull/11630#discussion_r3548041191
@peterwilsoncc

---

Should we hide my author name on my posts? ​https://github.com/WordPress/wordpress-develop/pull/11630#discussion_r3532104633
@joedolson

---

The date badge has been moved from the title area to the content area

This was my suggestion, but if we want to maintain the previous design, I think we should hide the badge displayed in the screen options.

​https://github.com/WordPress/wordpress-develop/pull/11630#discussion_r3548076290
@peterwilsoncc

Addressed all @peterwilsoncc's feedback.

Should we hide my author name on my posts? ​https://github.com/WordPress/wordpress-develop/pull/11630#discussion_r3532104633

I addressed that ​here. IMO yes, the vast majority of sites are single-author so rendering the author will be noise for most users.

[joedolson]

Marking for commit. While there may be tweaks, I think this is in good shape.

[joedolson]

In 62681:

Widgets: Add "On This Day" dashboard widget.

Add a dashboard widget that shows users past entries published on the same month and day from previous years. The widget is hidden if there are no history to show for the date.

Props alshakero, eclev91, annezazu, westonruter, kellychoffman, simison, joen, retrofox, audrasjb, desrosj, peterwilsoncc, matt, sabernhardt, wildworks, jeherve, apermo, dmsnell, jonsurrell, jorbin, talldanwp, retrofox, joedolson.
Fixes #65116.

Great work, all. Thanks for the continued effort in particular @alshakero 👏🏼.

Refactor tests to use static user IDs for consistency and clarity.

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

Follow-up to https://core.trac.wordpress.org/changeset/62681, which added the On This Day dashboard widget along with its test coverage. This PR is a test-only maintenance pass on Tests_Admin_wpOnThisDay:

• Adds the missing @ticket 65116 annotation to each test method, so the tests are discoverable via the ticket group as required by the ​core test conventions.
• Moves the repeated author user creation into shared wpSetUpBeforeClass() fixtures (self::$user_id and self::$other_user_id), replacing the per-test self::factory()->user->create() calls. The two users now carry the Current Writer / Guest Writer display names that test_widget_labels_posts_from_other_authors() previously created inline, so every test shares one consistent set of authors.

No production code is touched and no test assertions change; this only reduces duplicated setup and the number of users created per test run.

## Use of AI Tools

Use for drafting PR details.

[SergeyBiryukov]

In 62852:

Tests: Improve On This Day dashboard widget tests.

Includes:

• Adding the missing @ticket 65116 annotation to each test method, so the tests are discoverable via the ticket group as required by the core test conventions.
• Moving the repeated author user creation into shared wpSetUpBeforeClass() fixtures.
• Renaming the test class to match the wp_dashboard_on_this_day() function name.

No production code is touched and no test assertions change; this only reduces duplicated setup and the number of users created per test run.

Developed in ​https://github.com/WordPress/wordpress-develop/pull/12634.

Follow-up to [62681].

Props mukesh27, westonruter, joedolson, SergeyBiryukov.
See #65116, #64894.

I attempted to resolve the code conflicts, and the diff became zero. It seems this was caused by the PR already being committed. This PR can now be closed.

https://core.trac.wordpress.org/changeset/62852