[wp-trac] [WordPress Trac] #59360: update_network_option() strict checks can cause false negatives

[WordPress Trac]

#59360: update_network_option() strict checks can cause false negatives
-------------------------------------------------+-------------------------
 Reporter:  mukesh27                             |       Owner:  joemcgill
     Type:  defect (bug)                         |      Status:  assigned
 Priority:  normal                               |   Milestone:  6.4
Component:  Options, Meta APIs                   |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  has-unit-tests has-patch commit      |     Focuses:
  dev-feedback                                   |  performance
-------------------------------------------------+-------------------------

Comment (by hellofromTonya):

 Hello all,

 >This component is so crucial for plugins, and despite having a possible
 fix for the latest issue, we've now identified a few breaks during this
 work and it's getting late in the cycle. I'm not yet confident that we
 have a stable enough patch for release.

 @costdev concerns give me pause due to "identified a few breaks" and his
 "not yet confident".

 Noting @jrf:
 >The underlying code which the failures are related to is the
 https://github.com/Yoast/wordpress-seo/blob/trunk/inc/options/class-wpseo-
 option.php class which ensures that for select options, the values are
 stable, i.e. the values are arrays and the class makes sure that if any of
 the expected array keys are missing from the option, they get added with a
 default value to make sure that all code in the plugin which relies on the
 option can always count on all keys being available and set.

 Quoting @joemcgill
 >I'd like to see if we can remove the pre_filter juggling in both
 functions and add tests that validate that the previous behavior is
 protected when pre_filters are in place.

 If removing the pre_filter juggling has very high confidence in resolving
 the issue and there's very high confidence that "identified a few breaks"
 will not have impacts on the release, then the fix could go in. Otherwise,
 I'd advise leaning into caution by reverting and continuing the work
 during the early phases of 6.5 Alpha.

 While yes, these changes can be reverted during the RC cycle, IMO that
 should not be the target. Rather, (again IMO) the release should go into
 the RC cycle with high confidence the changes are ready to ship without
 impact.

 Timing: A revert or fix decision can happen before RC1, though I'd advice
 making that decision and doing the revert / commit the day before (at
 latest) in case another unscheduled beta is needed.

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