WordPress 7.1 Beta 1 adds an On This Day dashboard widget that resurfaces posts published on the same date in earlier years. A useful privacy test checks more than published posts because private, draft, scheduled, deleted, author-restricted, and multisite content may carry sensitive titles or editorial context.
Use this on membership sites, newsrooms, schools, agencies, intranets, multisite networks, or any WordPress install where dashboard users have different access to posts and authors.
Quick answer
WordPress 7.1 On This Day Widget Private Content Visibility Test should be handled with a narrow evidence-first workflow: create status fixtures, test date boundaries, test every role, then verify the result before making broader changes.
What to check first
- Create fixtures for published, private, password-protected, draft, pending, scheduled, trashed, and deleted posts across several authors.
- Set publication times around midnight, daylight-saving changes, and the site timezone boundary for the test date.
- Log in as administrator, editor, author, contributor, subscriber, and a custom role, then record widget titles, links, excerpts, and counts.
- Repeat on multisite with site-only users, network users, switched blogs, and content from an archived or private site.
- Open every visible item and confirm the destination enforces the same capability decision as the widget.
Diagnostic table
Use this table to keep the work practical. It connects the symptom to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Create status fixtures | Create fixtures for published, private, password-protected, draft, pending, scheduled, trashed, and deleted posts across several authors. | Each role sees only posts it is allowed to discover and open. |
| Test date boundaries | Set publication times around midnight, daylight-saving changes, and the site timezone boundary for the test date. | Private titles, excerpts, author names, and counts do not leak to lower-privilege users. |
| Test every role | Log in as administrator, editor, author, contributor, subscriber, and a custom role, then record widget titles, links, excerpts, and counts. | The site timezone determines the expected anniversary without duplicate or missing rows. |
| Test multisite | Repeat on multisite with site-only users, network users, switched blogs, and content from an archived or private site. | Multisite results stay within the current site and membership boundary. |
Why this usually happens
- Dashboard queries can accidentally filter by date before applying post status, author, and capability rules.
- A title or excerpt can expose private context even when the linked edit screen later denies access.
- UTC storage and site-local dates can move a post into or out of the anniversary window.
- Multisite user membership and network capabilities differ from normal single-site role assumptions.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
wp post list --post_status=publish,private,draft,pending,future,trash \
--fields=ID,post_title,post_status,post_author,post_date,post_date_gmt
wp option get timezone_string
wp user list --fields=ID,user_login,roles
Safe fix order
Do the work in a sequence that makes each result easy to prove. Stop if a step produces new evidence that changes the incident scope.
- Create status fixtures
- Test date boundaries
- Test every role
- Test multisite
- Verify destinations
What to tell the client or owner
Provide the role, site ID, post status, author relationship, stored and local dates, visible widget data, destination result, and expected capability.
Production verification checklist
- Each role sees only posts it is allowed to discover and open.
- Private titles, excerpts, author names, and counts do not leak to lower-privilege users.
- The site timezone determines the expected anniversary without duplicate or missing rows.
- Multisite results stay within the current site and membership boundary.
Mistakes to avoid
- Do not judge the fix by one browser or the homepage only.
- Do not delete evidence before recording usernames, file paths, timestamps, and response headers.
- Do not add a cache, security, or tracking plugin while the original problem is still unclear.
- Do not leave test users, temporary debug logs, or broad API keys active after verification.
When HandL WP should help
Bring in help when this affects leads, checkout, search visibility, malware risk, paid media reporting, or a client production site. HandL WP can trace the issue through WordPress, hosting, cache, tracking, and Search Console, then verify the workflow after the technical fix.
If this is active on a production site, audit WordPress dashboard privacy.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references