Opened 2 years ago
Last modified 2 years ago
#56694 new defect (bug)
Uncached database read for logged in users when Privacy Policy Page is deleted
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | Awaiting Review | Priority: | normal |
Severity: | normal | Version: | 5.7 |
Component: | Privacy | Keywords: | needs-patch needs-unit-tests |
Focuses: | administration, performance | Cc: |
Description
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.
Attachments (2)
Change History (4)
#1
@
2 years ago
Recommend a two-part fix for this:
- 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 to0
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.
- Add a similar hook (likely to
wp_trash_post
andbefore_delete_post
) with a helper function to update thewp_page_for_privacy_policy
option to0
. 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, inoptions-privacy.php
– may be more).
Query Monitor showing call stack to uncacheable database read