[wp-trac] [WordPress Trac] #21989: update_option() calls sanitize_option() twice when option does not exist

[WordPress Trac]

#21989: update_option() calls sanitize_option() twice when option does not exist
-------------------------------------------------+-------------------------
 Reporter:  MikeSchinkel                         |       Owner:  pbearne
     Type:  defect (bug)                         |      Status:  accepted
 Priority:  normal                               |   Milestone:  Future
                                                 |  Release
Component:  Options, Meta APIs                   |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  dev-feedback has-patch needs-        |     Focuses:
  testing                                        |  performance
-------------------------------------------------+-------------------------

Comment (by lev0):

 @pbearne did you look at & test my [https://github.com/WordPress
 /wordpress-develop/pull/6156 PR]? Most proposed solutions – including
 yours – pose a hazard because of [https://www.hyrumslaw.com/ Hyrum's Law].
 WordPress certainly meets its "sufficient number of users" requirement.

 The minimum amount of double processing you can get with your suggested
 earlier diversion is avoiding the `is_scalar()` and `empty()` (to ensure
 an option name). This would be sufficient to stop the double sanitise,
 ''except'' it would also bypass the `pre_update_option*` and (within the
 `$old_value = get_option( $option );`) the extra
 `default_option_{$option}` and `pre_option*` filters that occur prior to
 the current diversion.

 The sequence in `add_option()` is not compatible, and Hyrum tells us we
 should expect devs to rely on those filters. In order for your suggestion
 to work ''and'' maintain bc, the lost filtering would have to be
 duplicated in `add_option()` but made to only run conditionally so that it
 would not change explicit `add_option()` calls. I'm not sure it's even
 feasible to get the same order of operations trying to do it that way.

 I understand there may be objections to the creation of another private
 use function in the PR, but I can't see another way to fix this without
 either duplicate code or a bc break. I'm happy to be proven wrong.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/21989#comment:43>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform