Administration: Always display the On This Day dashboard widget

[i-am-chitti]

Trac ticket

https://core.trac.wordpress.org/ticket/65647

Problem

The On This Day dashboard widget is hidden with the core hidden class when there are no posts to show for the current calendar day. This creates inconsistent, confusing behavior:

• The widget is not visible on the dashboard, but its Screen Options checkbox is still checked — so the reported state disagrees with what's actually shown.
• Unchecking and re-checking the option reveals the widget, because postbox.js calls jQuery's .show(), which injects an inline display: block that overrides the .hidden class.

The root cause is two independent hide mechanisms competing: a server-side hidden class vs. the persisted per-user Screen Options preference.

Fix

Take the "always show" approach (option 1 from the ticket):

• Remove the postbox_classes_dashboard_wp_dashboard_on_this_day filter and the wp_dashboard_on_this_day_postbox_classes() function that added the hidden class.
• The widget is now always registered and always visible. When there are no matching posts, the existing placeholder — "No posts were published on this day in previous years." — is shown.
• Hiding is deferred entirely to Screen Options, which persists correctly and keeps the checkbox state consistent with on-screen visibility.

This is consistent with other always-registered dashboard widgets (e.g. Activity, At a Glance) and avoids !important CSS hacks.

Testing instructions

1. Ensure there are no published posts dated on today's month/day in a previous year (a recent install satisfies this by default).
2. Visit the Dashboard.
3. Before this change: the widget is not visible, yet "On This Day" is checked in Screen Options; unchecking and re-checking reveals it.
4. After this change: the widget is always visible and shows the placeholder message; the Screen Options checkbox state matches its visibility. Unchecking hides it and the preference persists across reloads.

Screenshots

Before

After

Use of AI Tools

AI assistance: Yes
Tool(s): Claude Code
Model(s): Opus 4.8
Used for: update unit tests

[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 iamchitti, wildworks, joedolson, mukesh27, annezazu, paaljoachim, joen.

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

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

[mukeshpanchal27]

Thanks @i-am-chitti for the PR!

Overall look solid to me.

[Copilot]

Pull request overview

This PR updates the “On This Day” Dashboard widget behavior so it is always displayed (and therefore consistently represented in Screen Options), showing an existing placeholder message when there are no matching posts for the current calendar day.

Changes:

• Removes the postbox-class filter mechanism that previously added the core hidden class when there were no matching posts.
• Updates the widget setup/rendering documentation and inline comments to reflect the “always visible; placeholder when empty” behavior.
• Updates PHPUnit tests by removing coverage that asserted the old “hide when empty” behavior.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
tests/phpunit/tests/admin/wpDashboardOnThisDay.php	Updates tests to stop asserting the removed postbox-class filter behavior.
src/wp-admin/includes/dashboard-on-this-day.php	Removes the hidden-class filter and updates documentation/comments to match always-visible behavior.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[t-hamano]

I have made two changes to this PR. It is ready for re-review.

• dc0aea5: Resolve conflicts.
• d218c56: Remove the wp_dashboard_on_this_day_setup function. This is because it is now merely a wrapper for wp_add_dashboard_widget and is deemed to have no further purpose.

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

Comments suppressed due to low confidence (2)

tests/phpunit/tests/admin/wpDashboardOnThisDay.php:103

• The PR changes how the widget is registered (now directly in wp_dashboard_setup()) and removes the postbox class filter, but there is no test exercising the updated registration path. Adding a small integration-style test that calls wp_dashboard_setup() would cover the regression reported in #65647 (widget always registered/visible via Screen Options, and no hidden postbox filter).

	/**
	 * @ticket 65116
	 *
	 * @covers ::_wp_dashboard_on_this_day_date_query_clause
	 */
	public function test_get_date_query_clause_includes_february_29_on_february_28_in_non_leap_year() {

src/wp-admin/includes/dashboard-on-this-day.php:17

• Removing wp_dashboard_on_this_day_setup() entirely is a backward-compatibility break for any code that might have called it since it was introduced in 7.1.0. Consider keeping it as a thin wrapper that only registers the widget (without adding any hidden class behavior), so existing callers don’t fatally error while still achieving the “always show” behavior.

/**
 * Renders the On This Day dashboard widget.
 *
 * Outputs the matching posts grouped by publication year, newest year first.
 *
 * @since 7.1.0
 */
function wp_dashboard_on_this_day() {

[t-hamano]

I've been thinking about this, and I'm leaning towards supporting this PR that always displays the On This Day widget.

@m suggested hiding the On This Day widget entirely when there's no content to display. However, implementing this presents some tricky challenges. A significant issue is that the widget might be visually absent, yet its checkbox in the Screen Options would still appear.

While we can hide the "On This Day" checkbox within Screen Options, it requires a somewhat convoluted approach.

Furthermore, the current behavior might be perceived as a bug. Please refer to this livestream by Ryan. https://www.twitch.tv/videos/2821389287?t=42m35s

@annezazu @joedolson, I plan to move forward with this PR, what are your thoughts?

[annezazu]

Thanks for surfacing this. I agree in having it always on, both to avoid technical concerns and to prevent confusion around the checkbox problem. I can see how that would be confusing. Since this means the empty state will be more readily visible, perhaps we can spruce it up from this:

For example, here's what site health shows:

Maybe something like this, where we link to "Add post"?

@WordPress/gutenberg-design for any empty state thoughts here :)

[joedolson]

I agree with this. Ultimately, hiding it creates a lot of technical problems that are largely unnecessary, and creates a user experience that's potentially confusing.

I feel like the text should be more invitational; something like "You haven't published a post on this day before. Write one now, and be reminded about it next year!"

But I think getting some copy work on this would be good; and we need to nail that down by RC, for translators sakes.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[joedolson]

Barring polish on the text, I think that this is ready to go. I think it would be fine to commit with the text suggested by @annezazu, and continue to discuss; but if anybody has suggestions on the text that we can land on before RC 1, that would be great.

[annezazu]

I like your text more than mine (and don’t feel strongly). Another option: “No posts were published on this day in previous years. Write one today, and be reminded about it next year.”

[i-am-chitti]

I like the prompt by @joedolson - "Write one today, and be reminded about it next year". But ideally, if published on the day, it will be shown next year on same date. So, I guess it should be "Publish one today, and be reminded about it next year".

Let me know once copy is finalized. I will do the final copy update quickly.

[paaljoachim]

I see the dashboard as an area that is meant to focus on the customers site to where they can gain useful information. On keeping On This Day dashboard widget....not sure I see the use in that...sorry. I do see it kind of like a history widget though. Like a curiosity...

[jasmussen]

Things moving fast here, good work all around. I'll try and respond primarily to the ping on the empty-state.

Which is to say, in the current context and widget implementation, it largely works to prompt and explain. It's a pity we can't hide it when it's empty: I endorse moving forward without that feature in the name of iteration, but nevertheless I want to acknowledge the instinct: when it's populated it's a moment of delight. When it's empty, it's a question: why is this here? Not blocking, but encouraging future iteration in this space.

And it's extra context for tweaking the help text, because for me it suggests that the text should be as minimal as possible, so that it serves as the lightest write-prompt+explanation we can muster, but otherwise reduce its footprint so it doesn't annoy. In that sense, we could go one of these directions:

• Nothing here yet. [Write today's post].
• No posts on this day yet. [Start one now] for next year.
• This day is empty. [Write something] worth revisiting.

I can understand an argument to want to stay verbose afterall: on a big screen two lines of text might not feel like a lot. But the problem is: on many blogs, and certainly many static sites that aren't used as blogs, you'll see this text a lot, which is why I'm leaning towards less text. (Also a question: can we/is the widget already hidden if a site has no posts at all?)

Nevertheless if you want the more verbose text, you could go in one of these directions:

• Anne's option: No posts were published on this day in previous years. [Write one today], and be reminded about it next year.
• Today's archive is empty for now. [Write something today] to start filling it in.
• Nothing was written on this day before. [Start today] to change that.

[t-hamano]

I tried the suggested text. I would love to hear your feedback.

No posts were published on this day in previous years. (Current text)

Nothing here yet. [Write today's post].

No posts on this day yet. [Start one now] for next year.

This day is empty. [Write something] worth revisiting.

No posts were published on this day in previous years. [Write one today], and be reminded about it next year.

Today's archive is empty for now. [Write something today] to start filling it in.

Nothing was written on this day before. [Start today] to change that.

[joedolson]

Many widgets are only useful to some users - the majority of users will never attend a WordPress event and are unconcerned with WordPress news. I don't think we need to concern ourselves too much with whether or not all users will benefit from it. Users who use the dashboard at all will customize it to their needs - other users won't use it, and it will make little difference to them what's there.

I don't particularly like using 'empty'; it doesn't feel very friendly to me. I'm also not thrilled with "Write something worth revisiting", as it puts unnecessary pressure by setting a value judgement on publishing.

My preference from above would be "Nothing here yet. [Write today's post]." Short and to the point.

[t-hamano]

My preference from above would be "Nothing here yet. [Write today's post]." Short and to the point.

I tried this.

[annezazu]

I don't think that really connects what the widget does though and we need to assume folks need that connection. I'd prefer we go with this:

No posts were published on this day in previous years. [Write one today], and be reminded about it next year.

I think it matches a friendliness in our interface that we shouldn't be afraid to have (think "hello dolly" vibes), especially when looking at the approach for the events widget that asks people to consider organizing an event.

[t-hamano]

No posts were published on this day in previous years. [Write one today], and be reminded about it next year.

I have changed the wording. I don't have a strong opinion on the phrasing, but in any case, it might be best to commit this PR towards RC1 and gather user feedback.

[mukeshpanchal27]

It might be best to commit this PR towards RC1 and gather user feedback.

Go for it @t-hamano

[joedolson]

The tests didn't merge cleanly, and will need some re-working after https://core.trac.wordpress.org/changeset/62968

I'm out of time for today, so I'm moving this out of commit for the moment.

[t-hamano]

The unit test failures should be resolved now.

[github-actions]

A commit was made that fixes the Trac ticket referenced in the description of this pull request.

SVN changeset: 62977
GitHub commit: 6693ea1

This PR will be closed, but please confirm the accuracy of this and reopen if there is more work to be done.