WordPress.org

Make WordPress Core

#39259 closed defect (bug) (fixed)

'custom_css_post_id' theme mod of `-1` doesn't prevent queries

Reported by: dlh Owned by: westonruter
Milestone: 4.7.1 Priority: normal
Severity: normal Version: 4.7
Component: Customize Keywords: has-patch commit fixed-major
Focuses: performance Cc:

Description

wp_get_custom_css_post() sets the custom_css_post_id theme mod to -1 to cache that no Custom CSS post exists and prevent future queries for it.

However, wp_get_custom_css_post() itself doesn't check whether the theme mod value is -1 before running its query, so when the value is -1, each frontend request still generates the query.

The attached patch attempts to alter the logic so that a theme mod of -1 blocks future queries. But doing so breaks some tests and suggests that a related bug might exist in wp_update_custom_css_post().

I think the broken tests stem from the fact that inserting a custom_css post doesn't also update the theme mod. Because wp_get_custom_css_post() currently ignores the cached value of -1, it would fetch the newly inserted post the next time anyway. The attached patch clears the theme mod manually in these cases.

Lastly, wp_update_custom_css_post() will insert a post if one doesn't exist, but it also doesn't update the theme mod to match.

After the change to wp_get_custom_css_post() from the patch is applied, if calling wp_update_custom_css_post() doesn't update the theme mod from -1, then that value would still block a query for the Custom CSS post. So, the patch would add set_theme_mod() to wp_update_custom_css_post().

Attachments (3)

39259.diff (3.4 KB) - added by dlh 12 months ago.
39259.2.diff (3.4 KB) - added by dlh 12 months ago.
39259.3.diff (3.7 KB) - added by westonruter 12 months ago.

Download all attachments as: .zip

Change History (11)

@dlh
12 months ago

@dlh
12 months ago

#1 follow-up: @dlh
12 months ago

39259.2.diff revises the change to wp_update_custom_css_post() so that the theme mod is set only when updating the Custom CSS for the current stylesheet. But now I'm not quite sure how updates to other stylesheets would have to work with respect to the theme mod.

#2 @westonruter
12 months ago

  • Keywords has-patch added
  • Milestone changed from Awaiting Review to 4.7.1
  • Owner set to westonruter
  • Status changed from new to accepted

This ticket was mentioned in Slack in #core by jeffpaul. View the logs.


12 months ago

#4 in reply to: ↑ 1 @westonruter
12 months ago

Replying to dlh:

39259.2.diff revises the change to wp_update_custom_css_post() so that the theme mod is set only when updating the Custom CSS for the current stylesheet. But now I'm not quite sure how updates to other stylesheets would have to work with respect to the theme mod.

Yeah, that's a limitation with Custom CSS in general right now, and more fundamentally with the theme mod API. I don't think there's a case in core where custom_css is updated when the target stylesheet is not currently active, and I don't think the changes in the patch here introduce anything new in that regard.

PR: https://github.com/xwp/wordpress-develop/pull/212

This ticket was mentioned in Slack in #core by jeffpaul. View the logs.


12 months ago

#6 @westonruter
12 months ago

  • Resolution set to fixed
  • Status changed from accepted to closed

In 39688:

Customize: Ensure theme_mod-cache of custom_css lookup of -1 short-circuits a WP_Query from being made.

Props dlh.
See #35395.
Fixes #39259.

#7 @westonruter
12 months ago

  • Focuses performance added
  • Keywords commit fixed-major added
  • Resolution fixed deleted
  • Status changed from closed to reopened

Re-opening for 4.7.1

#8 @dd32
12 months ago

  • Resolution set to fixed
  • Status changed from reopened to closed

In 39694:

Customize: Ensure theme_mod-cache of custom_css lookup of -1 short-circuits a WP_Query from being made.

Props dlh, westonruter.
See #35395.
Merges [39688] to the 4.7 branch.
Fixes #39259.

Note: See TracTickets for help on using tickets.