[wp-trac] [WordPress Trac] #22192: update_option() strict checks can cause false negatives
WordPress Trac
noreply at wordpress.org
Fri Oct 6 10:16:52 UTC 2023
#22192: update_option() strict checks can cause false negatives
--------------------------------------+--------------------------
Reporter: nacin | Owner: mukesh27
Type: defect (bug) | Status: closed
Priority: normal | Milestone: 6.4
Component: Options, Meta APIs | Version:
Severity: normal | Resolution: fixed
Keywords: has-patch has-unit-tests | Focuses: performance
--------------------------------------+--------------------------
Comment (by snicco):
Replying to [comment:55 flixos90]:
> @Mamaduka @mukesh27 As far as I can tell, I can think of two potential
solutions to the problem:
> * Either we temporarily remove any `pre_option_{$option}` filters before
getting the option from the database within `update_option()`, in order to
get the ''actual'' option. The value won't be otherwise used, so I think
that could be fine.
> * Or we make an actual database query to see whether the value exists in
the database. That sounds like a more reliable solution to the underlying
problem (checking a default isn't ever going to be fully reliable),
however it could introduce other unintended side effects.
>
> I'm personally leaning towards the first so far since it would be a
simpler change.
Removing the `pre_option_{$option}` filter is a BC break for any
functionality that relies on **consistently** short-circuiting the value
returned by `get_option`.
This breaks everything we do in [Vaults&Pillars](https://snicco.io/blog
/introducing-fortress-vaults-and-pillars)
In <= 6.3
if you call update_option('foo', 'B') it returns false and the DB value is
not updated.
because get_option correctly filtered the runtime value to `A` again.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/22192#comment:79>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list