Opened 4 years ago
Closed 3 years ago
#41039 closed defect (bug) (fixed)
`_delete_option_fresh_site()` continually queries the database
Reported by: |
|
Owned by: |
|
---|---|---|---|
Milestone: | 4.9 | Priority: | normal |
Severity: | normal | Version: | 4.7 |
Component: | Customize | Keywords: | has-patch |
Focuses: | Cc: |
Description
_delete_option_fresh_site()
passes the integer 0
to update_option()
, but 0
will later be fetched from the database as the string '0'
.
Each time _delete_option_fresh_site()
is called, then, when update_option()
checks whether the new value is the same as the current value, it will see the two values as different and attempt to perform the database update.
The attached patch would instead pass the string '0'
to update_option()
.
Attachments (3)
Change History (7)
#1
@
3 years ago
- Component changed from Upgrade/Install to Customize
- Keywords has-patch added
- Milestone changed from Awaiting Review to 4.9
- Owner set to westonruter
- Status changed from new to accepted
#2
@
3 years ago
- Keywords reporter-feedback added
- Owner changed from westonruter to dlh
- Status changed from accepted to assigned
@dlh I was trying to add a unit test for this in 41039.1.diff but in doing so, I couldn't actually reproduce the issue when your patch was applied or not.
#3
@
3 years ago
- Keywords reporter-feedback removed
@westonruter I think the second assertion passes when the patch isn't applied because the integer 0
is still cached after do_action( 'customize_save_after' )
was called for the first assertion.
When update_option()
runs as part of the second do_action( 'customize_save_after' )
, get_option()
retrieves the cached integer, and the ===
test in update_option()
passes.
41039.2.diff updates the test to regenerate the alloptions
cache between assertions, which causes the second assertion to fail without the change to _delete_option_fresh_site()
.
This makes sense to me. It's ironic that for the abundance of loose type checking
==
equality in WordPress, an instance where strict===
equality does exist here inupdate_option()
and it causes a slight performance problem when thepublish_post
,publish_page
,wp_ajax_save-widget
,wp_ajax_widgets-order
, orcustomize_save_after
actions are done.