[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