Make WordPress Core

Opened 10 years ago

Closed 10 years ago

#39259 closed defect (bug) (fixed)

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

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

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 10 years ago.
39259.2.diff (3.4 KB ) - added by dlh 10 years ago.
39259.3.diff (3.7 KB ) - added by westonruter 10 years ago.

Download all attachments as: .zip

Change History (11)

@dlh
10 years ago

@dlh
10 years ago

#1 follow-up: @dlh
10 years 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
10 years ago

  • Keywords has-patch added
  • Milestone Awaiting Review4.7.1
  • Owner set to westonruter
  • Status newaccepted

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


10 years ago

@westonruter
10 years ago

#4 in reply to: ↑ 1 @westonruter
10 years 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.


10 years ago

#6 @westonruter
10 years ago

  • Resolutionfixed
  • Status acceptedclosed

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
10 years ago

  • Focuses performance added
  • Keywords commit fixed-major added
  • Resolution fixed
  • Status closedreopened

Re-opening for 4.7.1

#8 @dd32
10 years ago

  • Resolutionfixed
  • Status reopenedclosed

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.