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

WordPress Trac noreply at wordpress.org
Tue Oct 10 10:40:55 UTC 2023


#22192: update_option() strict checks can cause false negatives
--------------------------------------+--------------------------
 Reporter:  nacin                     |       Owner:  mukesh27
     Type:  defect (bug)              |      Status:  reopened
 Priority:  normal                    |   Milestone:  6.4
Component:  Options, Meta APIs        |     Version:
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:  performance
--------------------------------------+--------------------------

Comment (by snicco):

 Replying to [comment:80 flixos90]:
 > Replying to [comment:79 snicco]:
 > > This breaks everything we do in
 [Vaults&Pillars](https://snicco.io/blog/introducing-fortress-vaults-and-
 pillars)
 >
 > Can you provide a bit more detail? What do you expect get_option() to
 do? And how does it not do that anymore since this change? If you can also
 provide an example, that would be really helpful.

 We extensively use the pre_get_option filter to insert an encryption layer
 between the WordPress database, where options are stored, and between the
 runtime values passed to PHP.

 This behavior is expected to be consistent from the outside.

 Different calls to get_option() must not return different values.

 That's manipulating the internal "state" from get_option from the outside
 and is no different than manipulating private properties with reflection.

 I'm only sharing https://snicco.io/blog/introducing-fortress-vaults-and-
 pillars as one obvious example, but who knows in what other ways this
 might break other dependents.

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


More information about the wp-trac mailing list