id,summary,reporter,owner,description,type,status,priority,milestone,component,version,severity,resolution,keywords,cc,focuses
18478,*_site_option() should use get_site_option for caching and filtering,duck_,duck_,"Currently add_site_option() and update_site_option() perform direct SQL queries instead of using the API. This means that we lose out on caching and the ability to filter the results.
However, I'm not sure on the caching part as it was specifically stopped in MU [http://mu.trac.wordpress.org/changeset/465/trunk/wp-inst/wp-includes/wpmu-functions.php during the merging in of get_site_option] with the $use_cache argument from WP. Does anyone know why this was? The call to get_site_option() was then switched to a direct query to [http://mu.trac.wordpress.org/changeset/1059/trunk/wp-includes/wpmu-functions.php stop infinite loops] though this should no longer be a problem due to the use of get_row() in get_site_option(). I believe that missing out on filtering of DB results is enough to get this patch in anyway.
update_site_option() on already calls get_site_option() before the direct query. The attached patch moves this code block above the `!is_multisite()` check, so this means that on singlesite there is a change to the filters applied. Calling update_site_option() on a non-existant option will apply `pre_add_site_option_$option` instead of `pre_update_option_$option`. I can easily move the code back down if this is undesirable.
Patch attached also adds the standard `if ( $result ) {` code to add_site_option() so that filters are only run on success.
Related: #18422, #15497",defect (bug),closed,normal,3.3,General,3.0,normal,fixed,has-patch needs-testing,,