[wp-trac] [WordPress Trac] #20712: Wrong data type returned from get_option for "page_on_front" after update_option
WordPress Trac
wp-trac at lists.automattic.com
Sun May 20 12:36:54 UTC 2012
#20712: Wrong data type returned from get_option for "page_on_front" after
update_option
--------------------------+------------------------------
Reporter: tszming | Owner:
Type: defect (bug) | Status: new
Priority: normal | Milestone: Awaiting Review
Component: General | Version: 3.3.2
Severity: normal | Resolution:
Keywords: has-patch |
--------------------------+------------------------------
Changes (by SergeyBiryukov):
* keywords: => has-patch
Comment:
Replying to [comment:2 tszming]:
> Need to be careful as the following lines of code does not work
Confirmed. In `update_option()`, `$newvalue` is passed through
`sanitize_option`: [[BR]]
http://core.trac.wordpress.org/browser/trunk/wp-
includes/option.php?rev=20784#L227
When comparing `$newvalue` with `$oldvalue`, we apparently assume that
`$oldvalue` was also sanitized previously, but that doesn't work for
numeric values, so we end up comparing a number with a string in line 232.
> The funniest thing is when you replace page_on_front with another option
such as blog_public then it would be okay. (both return strings in my code
above)
`blog_public` doesn't get sanitized by `sanitize_option()` (which may be a
separate bug), so the check is passed in that case.
Replying to [comment:3 dd32]:
> As a result, === shouldn't be used for comparison of core numeric ID's
Perhaps we should also check for sanitized `$oldvalue`
([attachment:20712.patch])? This doesn't seem to break any of our current
unit tests.
--
Ticket URL: <http://core.trac.wordpress.org/ticket/20712#comment:4>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software
More information about the wp-trac
mailing list