[wp-trac] [WordPress Trac] #34689: update_option should not trigger the option_{option name} filter
WordPress Trac
noreply at wordpress.org
Mon Nov 16 19:44:14 UTC 2015
#34689: update_option should not trigger the option_{option name} filter
--------------------------+----------------------
Reporter: mark-k | Owner:
Type: defect (bug) | Status: closed
Priority: normal | Milestone:
Component: General | Version:
Severity: normal | Resolution: wontfix
Keywords: | Focuses:
--------------------------+----------------------
Comment (by mark-k):
maybe it is a minefield, but basically you say that the option_{option
name} filter should never be used.
The "existing value" checked against should be the value in the DB as the
whole point of the check is to save a DB write. You can't say that the
validation should be against get_option because the code is written that
way as it is a pointless circular logic.
I have stepped over it as I was writing unit tests and produced some
execution path that is unlikely to happen in real life, but "unlikely !=
will never".
> I'd suggest that conditional filters on 'option_' point toward
architectural problems in what you're building. You really should be
filtering something further up the stack. If WP is missing an appropriate
filter for your purpose, please feel free to request it :)
Sure, I agree that filtering at the appropriate functional level is
preferred over filtering low level but
1. There is no higher level to 'comment_registration'.
2. the bug is still there for other people to stumble on it.
IMO getting the "get the raw value" functionality to a common function
which will be used by both get_option and update_option should be very low
risk thing. It is higher risk to keep this bug which at best case will
waste people's time and in worst will produce un debugable WTF moments.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/34689#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list