[wp-trac] [WordPress Trac] #39259: 'custom_css_post_id' theme mod of `-1` doesn't prevent queries

[WordPress Trac]

#39259: 'custom_css_post_id' theme mod of `-1` doesn't prevent queries
--------------------------+-----------------------------
 Reporter:  dlh           |      Owner:
     Type:  defect (bug)  |     Status:  new
 Priority:  normal        |  Milestone:  Awaiting Review
Component:  Customize     |    Version:  4.7
 Severity:  normal        |   Keywords:
  Focuses:                |
--------------------------+-----------------------------
 `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()`.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/39259>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform