Uncached database read for logged in users when Privacy Policy Page is deleted

[johnjamesjacoby]

As a logged in WordPress user navigating around WordPress Admin, a hook fires on every admin page that attempts to notify you whether or not the suggested Privacy Policy text (in WordPress) has changed, sourced from the "Privacy Policy Guide" settings page.

The Privacy Policy itself is a Page, and the numeric ID of that page is saved as a Setting.

If the WordPress Page (that matches the ID that is set as the Privacy Policy Page setting) is permanently deleted, WordPress still attempts to query the database to look for this Page.

This results in a single database read query that will never find what it is looking for, and is not cached because it does not exist, causing it to happen again on every subsequent page that any logged in user navigates to inside of WordPress Admin.

• This user would normally never know this database chatter is happening because it isn't anything they are intentionally looking for
• I discovered this misbehavior while using the Query Monitor plugin on a dev site, and noticed that there was always 1 uncached database read

Screenshot of the query & call stack will be attached below.

[johnjamesjacoby]

Query Monitor showing call stack to uncacheable database read

[johnjamesjacoby]

Recommend a two-part fix for this:

1. Add a method to the WP_Privacy_Policy_Content class to check if the Page exists with the ID that the Setting (wp_page_for_privacy_policy) is set to. If it does not exist, update the setting value to 0 and halt any additional stuff related to it. This will self-heal the problem for existing sites without any kind of upgrade routine, and also just seems smart to do here.

2. Add a similar hook (likely to wp_trash_post and before_delete_post) with a helper function to update the wp_page_for_privacy_policy option to 0. This matches what the Front Page options also do. See: _reset_front_page_settings_for_post() – this requires auditing WordPress for any existing places where the Privacy Policy Page being in the Trash is accounted for and removing them (I found 1, in options-privacy.php – may be more).

[johnjamesjacoby]

Out of scope idea: deprecate _reset_front_page_settings_for_post() and replace it with something more robust that plugins can also easily use to "disconnect" their own Page settings 💗

[johnjamesjacoby]

Default themes call the_privacy_policy_link() in footer.php, triggering 2 uncachable database reads

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

## Use of AI Tools

AI assistance: Yes
Tool(s): Claude
Model(s): Sonnet 4.6
Used for: Code review and manual test suggestions to test extensively; final implementation were reviewed and fully tested by me.

[masteradhoc]

Hey @johnjamesjacoby
i just prepared a PullRequest over at ​https://github.com/WordPress/wordpress-develop/pull/11443
Could you give it a test as well? i followed your suggested pattern.

These are the tests i performed locally:
Test A — Trash resets the option
Set a page as the Privacy Policy page, trashed it via the Pages list, then ran wp option get wp_page_for_privacy_policy. Result: 0. ✅

Test B — Permanent delete resets the option
Same setup, then permanently deleted the page from Trash. Result: 0. ✅

Test C — Self-healing in notice()
Manually set the option to a non-existent ID (wp option update wp_page_for_privacy_policy 99999), visited a page edit screen (/wp-admin/post.php?post=1&action=edit), then checked the option. Result: 0. ✅

Test D — Trash notice removed from Settings → Privacy
With the option set to a non-existent ID, visited Settings → Privacy. Confirmed the old "page is in the Trash / restore" message no longer appears. The "page does not exist" fallback still shows correctly. ✅

Could you give it a test as well? Appreciate your feedback.

Your feedback has been added, thanks @mukeshpanchal27 !

This will need unit tests as well.

Thanks to @nimesh-xecurify for his work on the Tests at ​https://github.com/WordPress/wordpress-develop/pull/11520