Opened 8 years ago
Closed 8 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 |
---|---|---|---|
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)
Change History (11)
#2
@
8 years 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.
8 years ago
#4
in reply to:
↑ 1
@
8 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.
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.